Re: [jetty-discuss] Jetty 4 vs. Jetty 3

[Chris H. <ch...@ha...>]

Ah!  Now you've re-presented the issues I can see possibly two different issues!

Are your SSL Image problems when using MSIE 5?

There is a well-known problem with MSIE5 (and possibly 6) when using persistent HTTP connections under SSL (which is what it uses
when there is a sequence of images to get): it breaks the SSL protocol - which is why you are seeing SSL-layer error messages being
logged by Jetty.

I posted a patched SSL Listener here a few  weeks ago, and a productionized version of the work-around is in the latest Jetty
releases:
Jetty-5.0.beta0 - 22 November 2003
and
Jetty-4.2.15rc0 - 22 November 2003


Now for the tuning issue.  There's a third control  which controls the socket backlog. This dictates the length of the queue used by
the operating system when there are no available Jetty listener threads.  Requests in this queue get serviced eventually. Requests
which arrive while this queue is full are silently discarded by the Operating System - it can do nothing else! Changing its value
from the shipped default is (in my opinion) of use only for passing artificial tests, not giving any significantly-different
behaviour in the 'real world'.

AFAIK Jetty does not send any kind of 'server busy' response. You either get a response or you don't!

The true test of a server under 'denial of service' levels of input request (e.g. during stress testing) is that it, itself says up
and retains its internal integrity. By definition, it cannot respond to all clients under these conditions.

If you are not up at these levels of demand, there may be something else wrong.

I, myself, would try putting the max idle time down to 1000 mS or less and see if that makes a difference. (If a client is not
prepared to use a persistent connection promptly it can jolly well go away and open another connection later - the thread it is
holding on to is the server's most precious commodity).  If this makes a difference it would again indicate something wrong /
unusual with either your clients or your network.

HTH

Chris



 "Tony Thompson" added:

> Sorry, I meant to mention the operating systems:
>
> RedHat 9
> SuSE
> Win 2000
> Win XP (not a server platform and does rather poorly under a load, lots
> of "connection refused" errors)
> NetWare (supposed to be a server platform but does about as bad as XP)
>
> I have been using the Sun JVM on all platforms except NetWare.  Most of
> the testing that I have done in house has been with Win2k.
>
> To me, this doesn't make one bit of sense but I will throw it out there
> to see if anyone else might have an idea why.  As I mentioned before,
> when I turn SSL on, things start to get really bad.  If I pull images
> from the server, they seem to cause things to slow down and fail.  The
> images I am pulling are small (<12K).  I even tried making them smaller
> to see if that made things any better; no change.  If I turn SSL off,
> images don't seem to make a difference.  I have, on occasion, seen Jetty
> display socket exception warnings on images.  I don't understand why
> images are really any different than any other content.
>
> Tony
>
> >>> je...@i3... 12/08/03 10:39PM >>>
> You didn't say what operating system you have.  On a un*x system make
> sure
> you don't run out of file descriptors.  E.g. on Solaris, try
> "ulimit -n 1024" in ksh before you start your Jetty process.
>
> Jeff
>
> On Mon, 8 Dec 2003, Tony Thompson wrote:
> > I know Jetty 4 has been around for a while but, we just recently
> were
> > able upgrade from Jetty 3 to Jetty 4.  One thing that we have noticed
> is
> > when a Jetty 4 server gets busy, it seems to reject connections
> easier
> > than a Jetty 3 server would.  When a Jetty 3 server started getting
> > busy, it would slow down but wouldn't reject connections.
> >
> > As the Jetty 4 server gets busy, clients will see a 404, for
> example,
> > in their browser.  If they retry the request, it will work fine.  On
> a
> > Jetty 3 server, this request would just take a little longer instead
> of
> > the browser displaying a 404.  In the case of Jetty 4, the server
> > doesn't actually return a 404.  It just seems to ignore the request
> > which the browser interprets as a 404.
> >
> > I am guessing that this is probably a tuning issue.  We currently
> tune
> > the minimum and maximum threads on a listener.  When the 404 shows
> up,
> > we do not see any messages on the server that indicate that the
> listener
> > is low/out of resources.  We can crank these numbers down and casue
> > issues on the server and Jetty will start complaining that it is low
> or
> > out of resources.  But, even when Jetty doesn't complain, it is
> still
> > rejecting connections.
> >
> > The other two parameters we tune on a listener are:
> >
> > MaxIdleTimeMs = 30000
> > LowResourcePersistTimeMs = 5000
> >
> > When we use SSL, this situation seems to get worse as load
> increases.
> >
> > Can anyone suggest anything else that should be tuned on Jetty 4?
> > Also, what might be the differences between Jetty 3 and Jetty 4?
> >
> > Thanks.
> > Tony