RE: [Simpleweb-Support] Simple Stability...

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Niall,

Note that we're running Simple "behind" the Linux "squid" proxy,
and that process always closes the incoming connection after a
single GET/POST request.  Thus our server never keeps a Pipeline
lying around, and never sees the optimizations you made to best
handle HTTP 1.1 persistent connections.

  Luni

--- Niall Gallagher <gal...@ya...> wrote:

> With regard to the simple.util.schedule pckage, it
> seems that this is just a blocking PriorityQueue,
> which will not account for wait times. This will
> certainly seem faster to the users, as the delay
> between requests will be 0 miliseconds each time.
> 
> The current Scheduler implementation may seem a little
> over the top! However it does a very important thing.
> What the current implementation does is it allows the
> server to work on an active set of pipelines. When
> there is an extremely large number of clients
> connected to the server there will obviously be just
> as many pipelines to poll, if not more. However, not
> all of these pipelines will contain requests. Instead
> they may be open and connected for a future request
> from the client, whom may not issue another request
> for some time. So, to reduce the workload involved in
> polling the Scheduler will have these queued for a
> wait peroid, which results in a signifigantly reduced
> number of pipelines to poll. Thus the server can spend
> more time concentrating on acquiring requests from
> pipelines that are producing them. To summarize, the
> Scheduler will only be releasing the active pipelines,
> an inactive pipeline will be polled only when its wait
> peroid is over.
> 
> This relates to the visible performance, if you
> request a page, the initial request will seem instant.
> If after 4 to 5 seconds you request another page
> Simple seems to stall. This is intentional. Its not
> that it is not performing well, its that the pipeline
> is waiting as it has been inactive for 4 to 5 seconds,
> typically the maximum wait is about 1000 ms. This may
> seem usless, however I have found that when the server
> is highly loaded the performance gains can be very
> signifigant. Also, the server will keep these
> connections open for much longer resulting in less
> dropped requests.
> 
> For lightly loaded servers the visible performance can
> be improved using the PipelineHandlerFactory. This
> will allow you to cap the maximum wait time. Simply
> set the maximum wait to 200 ms and it will seem as if
> the responses are instant.
> 
> Thank you for your contribution, it will try to
> introduce some of the changes soon.
> 
> Sorry for the length!
> 
> Niall
> 
> 
> 
> 
> 
> --- Gail Rahn Frederick <ga...@sc...>
> wrote:
> 
> > Hi Niall,
> > 
> > * I uploaded our changes as a Feature Request.
> > Enjoy!
> > 
> > * We noticed the speed increase but haven't profiled
> > it enough to give you
> > numbers. I say "significant" for our purposes,
> > enough to be noticable by us
> > humans.
> > 
> > -- Gail.
> > 
> > -------------
> > Gail Rahn Frederick
> > ga...@sc...
> > 503.260.0910
> > 
> > -----Original Message-----
> > From: sim...@li...
> >
> [mailto:sim...@li...]
> > On Behalf Of Niall
> > Gallagher
> > Sent: Wednesday, August 10, 2005 2:08 AM
> > To: sim...@li...
> > Subject: Re: [Simpleweb-Support] Simple Stability...
> > 
> > 
> > Hi Gail,
> > 
> > I would really like to see your implementation using
> > the java.util.concurrent package. If you like you
> > can 
> > put it up on sourceforge "Feature Requests" page for
> > Simple. You can locate it at the following URL:
> > 
> >
>
http://sourceforge.net/tracker/?atid=500356&group_id=62369&func=browse
> > 
> > Also, how much faster is the implementation with the
> > java.util.concurrent
> > package.
> > 
> > Niall
> > 
> > --- Gail Rahn Frederick <ga...@sc...>
> > wrote:
> > 
> > > Hi Niall and everyone,
> > > 
> > > As you know, I have been testing Simple for the
> > past
> > > few weeks, trying to
> > > track down a TCP error that was causing my
> > instance
> > > to eventually hang all
> > > worker threads, even under light loads.
> > > 
> > > I previously suggested a tweak to the Socket
> > > configuration (setting a
> > > SO_LINGER timeout).
> > > 
> > > In the end, we found spotty documentation about a
> > > Linux 2.4.x kernel bug
> > > that can cause sockets closed properly by the
> > > application to linger
> > > indefinitely in CLOSE_WAIT. Updating our Red Hat
> > > distribution via Red Hat
> > > Network (we paid for this service) resulted in the
> > > problem completely going
> > > away.
> > > 
> > > I was more than surprised to find an OS bug to be
> > at
> > > fault!
> > > 
> > > Along the way, I replaced Niall's synchronization
> > > and thread-pooling code
> > > with the new JDK 5 constructs from the new and
> > > wonderful package
> > > java.util.concurrent. I proved that Niall's
> > software
> > > was correct (because we
> > > saw the same deadlocks with the JDK 5 constructs,
> > > which have already been
> > > proven correct). But, the migration to
> > > java.util.concurrent seems to make a
> > > faster Simple.
> > > 
> > > I'm happy to contribute back the port to
> > java.util.concurrent, it 
> > > simplifies the code...
> > > 
> > > -- Gail.
> > > 
> > > -------------
> > > Gail Rahn Frederick
> > > ga...@sc...
> > > 503.260.0910
> > > 
> > > 
> > > 
> > > 
> > >
> >
> -------------------------------------------------------
> > > SF.Net email is Sponsored by the Better Software
> > > Conference & EXPO
> > > September 19-22, 2005 * San Francisco, CA *
> > > Development Lifecycle Practices
> > > Agile & Plan-Driven Development * Managing
> > Projects
> > > & Teams * Testing & QA
> > > Security * Process Improvement & Measurement * 
> > > http://www.sqe.com/bsce5sf 
> > > _______________________________________________
> > > Simpleweb-Support mailing list
> > Sim...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/simpleweb-support
> > > 
> > 
> > 
> > Niall Gallagher
> > 
> > 
> > 		
> > ____________________________________________________
> > Start your day with Yahoo! - make it your home page 
> > http://www.yahoo.com/r/hs 
> >  
> > 
> > 
> >
> -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software
> > Conference & EXPO September
> > 19-22, 2005 * San Francisco, CA * Development
> > Lifecycle Practices Agile &
> > Plan-Driven Development * Managing Projects & Teams
> > * Testing & QA Security
> > * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Simpleweb-Support mailing list
> > Sim...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/simpleweb-support
> > 
> > 
> > 
> > 
> >
> -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software
> > Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA *
> > Development Lifecycle Practices
> > Agile & Plan-Driven Development * Managing Projects
> > & Teams * Testing & QA
> > Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Simpleweb-Support mailing list
> > Sim...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/simpleweb-support
> > 
> 
> 
> Niall Gallagher
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection
> around 
> http://mail.yahoo.com 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference &
> EXPO
> September 19-22, 2005 * San Francisco, CA * Development
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *
> Testing & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Simpleweb-Support mailing list
> Sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simpleweb-support
> 