You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Colquhoun, Adrian" <Ad...@uk.experian.com> on 2003/01/23 11:59:47 UTC
Using SingleThreadModel under tomcat
Hi
I have a stateless servlet application in which I am considering
implementing SingleThreadModel. I note from the archives a number of posts
which suggest that implementing SingleThreadModel will impose a performance
overhead when running under tomcat. Could anyone provide me with a
explanation of how this performance impact comes about and (in relative
terms) the magnitude of this impact versus the potential impact of using
synchronisation blocks to ensure thread safe code ?
Thanks
Adrian
=======================================================================
Information in this email and any attachments are confidential, and may
not be copied or used by anyone other than the addressee, nor disclosed
to any third party without our permission. There is no intention to
create any legally binding contract or other commitment through the use
of this email.
Experian Limited (registration number 653331).
Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Using SingleThreadModel under tomcat
Posted by Erik Price <ep...@ptc.com>.
Colquhoun, Adrian wrote:
>
> Hi
>
> I have a stateless servlet application in which I am considering
> implementing SingleThreadModel. I note from the archives a number of posts
> which suggest that implementing SingleThreadModel will impose a performance
> overhead when running under tomcat. Could anyone provide me with a
> explanation of how this performance impact comes about and (in relative
> terms) the magnitude of this impact versus the potential impact of using
> synchronisation blocks to ensure thread safe code ?
There is another perspective as to why implementing SingleThreadModel is
a waste of time on this page -- scroll down to near the bottom where
there is an <h3> that says "Don't Use SingleThreadModel" (or search for
that text on the page).
http://www.onjava.com/pub/a/onjava/excerpt/jebp_3/index1.html?page=4
Erik
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Using SingleThreadModel under tomcat
Posted by Daniel Brown <gm...@blueyonder.co.uk>.
2. Tomcat maintains a pool of up to 20 (by default) instances of each
servlet that implements the SingleThreadModel.
If no instance is available when a new request comes in, the request waits
on an instance freeing up, so will be serviced when the queue empties, or
when the request gets lucky, and is randomly chosen by the scheduler as the
one to be notified.
> -----Original Message-----
> From: Felipe Schnack [mailto:felipes@ritterdosreis.br]
> Sent: 23 January 2003 11:48
> To: dan@27d.org; Tomcat Users List
> Subject: RE: Using SingleThreadModel under tomcat
>
>
> And tomcat implements option 1 or 2?
>
> On Thu, 2003-01-23 at 09:36, Daniel Brown wrote:
> > If, however, the servlet implements SingleThreadModel, then the
> container
> > has two choices:
> >
> > 1. serialise all requests through the single instance
> > 2. create a pool of servlet instances, and share out requests
> amongst the
> > pool, as each pool member becomes free
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Using SingleThreadModel under tomcat
Posted by Felipe Schnack <fe...@ritterdosreis.br>.
And tomcat implements option 1 or 2?
On Thu, 2003-01-23 at 09:36, Daniel Brown wrote:
> Adrian,
>
> Here's a starter:
>
> Normally, the servlet container maintains only one instance of each servlet,
> (one instance per servlet per JVM is required by the servlet spec. in a
> non-distributed environment) and passes all requests received concurrently
> through the service method of that instance.
>
> If, however, the servlet implements SingleThreadModel, then the container
> has two choices:
>
> 1. serialise all requests through the single instance
> 2. create a pool of servlet instances, and share out requests amongst the
> pool, as each pool member becomes free
>
> Option 1 has an obvious performance penalty, if your application ever has
> more than one concurrent request.
>
> Option 2 requires more server resources for the extra objects created, more
> processing to manage the pool, and, as the number of concurrent requests
> increase, will end up either in poor performance, if the container limits
> the pool to a certain size, and forms a queue of new requests; or poor
> performance and then lack of service as the container runs out of memory.
>
> Note also that SingleThreadModel doesn't buy you very much - although you no
> longer need to worry about synchronising access to instance variables, you
> still need to handle synchronisation of external resources, static
> variables, sessions, etc., as you can still have more than one request
> executing concurrently, just in different instances of the same servlet.
>
> HTH,
>
> Dan.
>
> > I have a stateless servlet application in which I am considering
> > implementing SingleThreadModel. I note from the archives a number of posts
> > which suggest that implementing SingleThreadModel will impose a
> > performance
> > overhead when running under tomcat. Could anyone provide me with a
> > explanation of how this performance impact comes about and (in relative
> > terms) the magnitude of this impact versus the potential impact of using
> > synchronisation blocks to ensure thread safe code ?
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893
Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Using SingleThreadModel under tomcat
Posted by Daniel Brown <gm...@blueyonder.co.uk>.
Adrian,
Here's a starter:
Normally, the servlet container maintains only one instance of each servlet,
(one instance per servlet per JVM is required by the servlet spec. in a
non-distributed environment) and passes all requests received concurrently
through the service method of that instance.
If, however, the servlet implements SingleThreadModel, then the container
has two choices:
1. serialise all requests through the single instance
2. create a pool of servlet instances, and share out requests amongst the
pool, as each pool member becomes free
Option 1 has an obvious performance penalty, if your application ever has
more than one concurrent request.
Option 2 requires more server resources for the extra objects created, more
processing to manage the pool, and, as the number of concurrent requests
increase, will end up either in poor performance, if the container limits
the pool to a certain size, and forms a queue of new requests; or poor
performance and then lack of service as the container runs out of memory.
Note also that SingleThreadModel doesn't buy you very much - although you no
longer need to worry about synchronising access to instance variables, you
still need to handle synchronisation of external resources, static
variables, sessions, etc., as you can still have more than one request
executing concurrently, just in different instances of the same servlet.
HTH,
Dan.
> I have a stateless servlet application in which I am considering
> implementing SingleThreadModel. I note from the archives a number of posts
> which suggest that implementing SingleThreadModel will impose a
> performance
> overhead when running under tomcat. Could anyone provide me with a
> explanation of how this performance impact comes about and (in relative
> terms) the magnitude of this impact versus the potential impact of using
> synchronisation blocks to ensure thread safe code ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>