Thanks Christopher, it makes more sense now.
On Fri, Apr 17, 2015 at 8:51 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Satish,
>
> On 4/17/15 7:20 AM, satish jupalli wrote:
> > I would like to support a bust in traffic we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Satish,
On 4/17/15 7:20 AM, satish jupalli wrote:
> I would like to support a bust in traffic we are planning to
> increase the umber of threads by adding executor pool with
> misSpareThread to 100 and accept count to 5. However, I'm
> trying t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Anil,
On 7/23/13 4:35 AM, Anil Goyal -X (anigoyal - ARICENT TECHNOLOGIES
MAURIITIUS LIMITED at Cisco) wrote:
That logic needs to happen in another layer, in a load-balancer.
Tomcat cannot do this on its own.
- -chris
-BEGIN PGP SIGNATURE-
2011/4/29 André Warnier :
> Server version: Apache Tomcat/5.5
> Server built: Oct 15 2008 12:57:44
> Server number: 5.5.26.0
>
> Intuitively, I would expect that after some time, the number of live threads
> would be decreasing back to the minSpareThreads value, but that does not
> seem to be ha
Thanks Folks.
On Wed, Mar 3, 2010 at 1:03 PM, Peter Crowther
wrote:
> On 3 March 2010 18:24, Bharath Vasudevan wrote:
>
> > Hmmm...
> >
> > "No, the server will allocate maxThreads request handlers; the other
> > requests would sit in the TCP stack's queue (not in the JVM), up to the
> > configu
On 3 March 2010 18:24, Bharath Vasudevan wrote:
> Hmmm...
>
> "No, the server will allocate maxThreads request handlers; the other
> requests would sit in the TCP stack's queue (not in the JVM), up to the
> configured acceptCount value - which you can set as high as your OS
> allows."
>
> I was a
e:
> > From: Bharath Vasudevan [mailto:bharath....@gmail.com]
> > Subject: Re: Tomcat threads
> >
> > When tomcat gets a request, it does a socket send to some
> > other process to handle the request and then respond.
>
> Tomcat doesn't do that - your webapp does.
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bharath,
On 3/3/2010 12:21 PM, Bharath Vasudevan wrote:
> Let me explain the scenario. When tomcat gets a request, it does a socket
> send to some other process to handle the request and then respond. This
> would happen fast. But assuming 20k client
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bharath,
On 3/2/2010 7:42 PM, Bharath Vasudevan wrote:
> Why is it illlogical? Fast is a relative term. If the number of requests
> increases, the number of threads that can be handled by the system goes down
> . The context switches and the pain to h
> From: Bharath Vasudevan [mailto:bharath@gmail.com]
> Subject: Re: Tomcat threads
>
> Looks like comet can asynchronously push data to the user.
You do understand that there really is no such thing as "push" (at least in
HTTP)? The client has to have a receive up, s
> From: Bharath Vasudevan [mailto:bharath@gmail.com]
> Subject: Re: Tomcat threads
>
> When tomcat gets a request, it does a socket send to some
> other process to handle the request and then respond.
Tomcat doesn't do that - your webapp does.
You have now int
That would be the last go. Trying to figure out if there is techniques to
handle such scenarios. Looks like comet can asynchronously push data to the
user. If this is going to be seamless to the client, it might as well look
like a response for their request.
On Wed, Mar 3, 2010 at 9:25 AM, Mark T
arath Vasudevan [mailto:bharath....@gmail.com]
>>> Subject: Re: Tomcat threads
>>>
>>> If we get a request on a thread, let some other thread do
>>> the work for it and store the response info. The thread
>>> which does the work writes the response on that request.
On 03/03/2010 17:21, Bharath Vasudevan wrote:
> Hi Charles,
>
> Let me explain the scenario. When tomcat gets a request, it does a socket
> send to some other process to handle the request and then respond. This
> would happen fast. But assuming 20k client requests come in at the same
> time, the
<
chuck.caldar...@unisys.com> wrote:
> > From: Bharath Vasudevan [mailto:bharath@gmail.com]
> > Subject: Re: Tomcat threads
> >
> > Why is it illlogical?
>
> 40+ years of system architecture experience.
>
> > If the number of requests increases, the
to:bharath@gmail.com]
Sent: Tuesday, March 02, 2010 6:43 PM
To: Tomcat Users List
Subject: Re: Tomcat threads
Why is it illlogical? Fast is a relative term. If the number of requests
increases, the number of threads that can be handled by the system goes
down
. The context switches and the pain to
> From: Bill Barker [mailto:billwbar...@verizon.net]
> Subject: Re: Tomcat threads
>
> The examples in Tomcat 7 are mostly server-push (e.g. fake stock
> ticker, chat). These are done by not completing the connection,
> and just pumping more data to a chunked response (so you
"Caldarale, Charles R" wrote in message
news:99c8b2929b39c24493377ac7a121e21f96cb817...@usea-exch8.na.uis.unisys.com...
From: Bill Barker [mailto:billwbar...@verizon.net]
Subject: Re: Tomcat threads
basically the request is handed off to another thread and the
original one retu
> From: Bill Barker [mailto:billwbar...@verizon.net]
> Subject: Re: Tomcat threads
>
> basically the request is handed off to another thread and the
> original one returns to the pool. This also allows for two-way
> communication instead of relying on polling.
What's req
> From: Bharath Vasudevan [mailto:bharath@gmail.com]
> Subject: Re: Tomcat threads
>
> Why is it illlogical?
40+ years of system architecture experience.
> If the number of requests increases, the number of threads
> that can be handled by the system goes down.
You'
"Caldarale, Charles R" wrote in message
news:99c8b2929b39c24493377ac7a121e21f96cb817...@usea-exch8.na.uis.unisys.com...
From: Bharath Vasudevan [mailto:bharath@gmail.com]
Subject: Re: Tomcat threads
If we get a request on a thread, let some other thread do
the work for it and
at 4:34 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:
> > From: Bharath Vasudevan [mailto:bharath@gmail.com]
> > Subject: Re: Tomcat threads
> >
> > If we get a request on a thread, let some other thread do
> > the work for it and store the
> From: Bharath Vasudevan [mailto:bharath@gmail.com]
> Subject: Re: Tomcat threads
>
> If we get a request on a thread, let some other thread do
> the work for it and store the response info. The thread
> which does the work writes the response on that request.
If the
Thanks Chuck.
One thing I am not able to get is why would the user care if the response
was done from a different thread? Is it not going to be opaque to the user
as long as its fast?
If we get a request on a thread, let some other thread do the work for it
and store the response info. The thread
> From: Bharath Vasudevan [mailto:bharath@gmail.com]
> Subject: Tomcat threads
>
> Are they user level threads or kernel threads?
Depends on the particular JVM being used, not on Tomcat. Pretty much all
modern JVMs use a kernel thread for each java.lang.Thread instance on which
start() has
> From: André Warnier [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads, II
>
> What I would like to know now, is how I interpret these numbers.
Will take a look at the actual numbers in a bit.
> Is there somewhere a tutorial giving some pointers as to what I am
> looki
Hi.
To implement a recommendation from someone on this list, I took a few
snapshots using "jmap -heap " while Tomcat was starting up and also
starting up a webapp.
I just ran the jmap command several times at about 5 second intervals,
and redirected the output to a file.
Below if the file con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
> When I started in this business, 64 Kb was a nice quantity of memory to
> program in, and quite expensive too. I created and ran a payroll
> application for a 1,000 people company in there. This Java app looks a
> lot cu
André Warnier schrieb am 13.11.2008 um 00:08:05 (+0100):
> [...] on the same machine I have a text search and retrieval
> application that can sift through a full-text index of 100,000
> documents (1 Gb of text) and retrieve the ones I want in couple of
> seconds. It has a 10 Mb memory footprint.
Chris, Chuck and others,
many thanks for taking the time to educate me (on both "Tomcat threads"
threads).
I got lots of information and tips, which will be useful now or later.
I'll now go sift through them again. At least now I have an idea where
to start.
About the fact that my hardware s
André
André Warnier wrote:
(and what is PermGen ?)
No one else seemed to answer this. PermGen is the chunk of memory which
is allocated to the JVM in which to hold the 'prototypes' of the class
files used. For a large web app with lots of classes (NOT object) it is
common to have to radic
Christopher Schultz schrieb am 12.11.2008 um 16:42:06 (-0500):
> André Warnier wrote:
> > In other words, while this application is being loaded, our Tomcat
> > and the whole system are totally unresponsive for about 5 minutes.
> 1. DNS settings. Especially when parsing XML (which often requires
André Warnier wrote:
> Now that I have (with your help) established some basic facts, I have a
> practical case for analysis.
>
> We have an old clunker PC (Pentium II, 512 Mb Ram, average ATA disks),
> which we use to test some applications (not only Java/Tomcat).
...
> Now, if I stop and restart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
Christopher Schultz wrote:
> A few parting thoughts:
I knew I was forgetting something:
3. During your 5-minute startup freeze, try taking a few thread dumps
(send a QUIT signal to your JVM) and seeing what the app is doing. Maybe
it's just t
> From: André Warnier [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads
>
> Since apparently this conversation clears some matters up, even for
> gurus, would one of you care to back-up a couple of messages, and
> re-state the final consensus in English for us mere m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
At the risk of repeating things said by others...
André Warnier wrote:
> We have an old clunker PC (Pentium II, 512 Mb Ram, average ATA disks),
> which we use to test some applications (not only Java/Tomcat).
Based upon this hardware configur
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat threads
PermGen seems like an odd item to share... though I
guess all those java.lang.Package, java.lang.Class,
java.lang.Method, etc. objects can really beat a
system down.
The sharing is not
> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads
>
> PermGen seems like an odd item to share... though I
> guess all those java.lang.Package, java.lang.Class,
> java.lang.Method, etc. objects can really beat a
> system down.
The sharin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
>> Subject: Re: Tomcat threads
>>
>> recent JVMs use shared memory to share common class data
>> (like JITed object code from
> From: André Warnier [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads, II
>
> I have turned it off now, and restarted Tomcat, but it
> did not have any noticeable impact on the startup time.
Wouldn't expect it to, since you're spending nearly all the time parsin
Caldarale, Charles R wrote:
From: André Warnier [mailto:[EMAIL PROTECTED]
Subject: Tomcat threads, II
>> -Djava.security.manager
>
> Enabling the security manager slows things down; do you really need it?
>
Not as far as I know. It was only the default setting on that system,
from the (non-of
> From: André Warnier [mailto:[EMAIL PROTECTED]
> Subject: Tomcat threads, II
>
> -classpath :/usr/lib/jvm/java-1.5.0-sun/jre//lib/jcert.jar:
> /usr/lib/jvm/java-1.5.0-sun/jre//lib/jnet.jar:
> /usr/lib/jvm/java-1.5.0-sun/jre//lib/jsse.jar:
> /usr/share/tomcat5.5/bin/bootstrap.jar:
> /usr/share/tomc
> From: André Warnier [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads, II
>
> We have already tried - because that is one thing we can do - to split
> the XML data into smaller chunks, but that does not seem to have any
> significant impact.
Nor would I expect it to. T
> From: André Warnier [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads
>
> - they would actually share (in memory) the compiled classes that are
> part of the standard Java library (java.* etc..)
No - see my previous post. You can use JConsole to see which memory pools ar
> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads
>
> recent JVMs use shared memory to share common class data
> (like JITed object code from java.* packages)
Careful - JITed code is *not* shared - only some of the PermGen is, and that
only o
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
- The memory usage one sees with "top" under some versions of Linux for
each one of these threads is not really cumulative, because most of it
is actually shared between the threads. The total
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
> - The memory usage one sees with "top" under some versions of Linux for
> each one of these threads is not really cumulative, because most of it
> is actually shared between the threads. The total really used is only
> s
David kerber wrote:
Pid wrote:
...
Having said that, parsing XML can be a memory intensive operation as
well, so your old box could be experiencing problems there - check the
garbage collection log.
p
I try to avoid XML for this exact reason. We found that our application
could handle bet
Pid wrote:
...
Having said that, parsing XML can be a memory intensive operation as
well, so your old box could be experiencing problems there - check the
garbage collection log.
p
I try to avoid XML for this exact reason. We found that our application
could handle between 6 and 10 times m
André Warnier wrote:
> Hi again.
>
> Now that I have (with your help) established some basic facts, I have a
> practical case for analysis.
>
> Before I get into details (because this is quite long), I'd like to
> explain the reason why I'm asking this.
> We have been testing a Tomcat application
Op woensdag, 12 november 2008 om 9:56 uur schreef Tomcat Users List
:
Subject: Re: Tomcat threads
Date: Wed Nov 12 09:56:01 CET 2008
From: André Warnier <[EMAIL PROTECTED]>
Filip Hanik .. and many others - Dev Lists wrote:
[...]
Thanks for all the answers, very enlightening.
In summar
Filip Hanik .. and many others - Dev Lists wrote:
[...]
Thanks for all the answers, very enlightening.
In summary thus :
- Tomcat (or rather I suppose the Connector) will create new threads as
needed to service simultaneous requests, up to the number given in the
Connector's maxThreads attribute
> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads
>
> you wont see that today any more, the executor has been fine tuned.
Good to know; thanks.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is
Caldarale, Charles R wrote:
From: Christopher Schultz [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat threads
If you really want tight control over the thread management,
you should probably use an "executor"
The last I heard from Remy M was that the performance was
disappo
> From: Christopher Schultz [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat threads
>
> If you really want tight control over the thread management,
> you should probably use an "executor"
The last I heard from Remy M was that the performance was
disappointing and they
For tomcat 6, when setting
if it reaches 50, it will not shrink.
but if you do
then it will shrink down to 25 if the threads are idle
Filip
|
André Warnier wrote:
Hi.
Only for my own intellectual advancement in matters Tomcat :
On this page : http://tomcat.apache.org/tomcat-6.0-doc/confi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
André Warnier wrote:
> On this page : http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
> , referring to the third paragraph of the Introduction.
If you really want tight control over the thread management, you should
probably use an "e
> From: André Warnier [mailto:[EMAIL PROTECTED]
> Subject: Tomcat threads
>
> http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
> , referring to the third paragraph of the Introduction.
Note that the 6.0 doc is missing some very important attributes for the
element. Apparently, the inten
> From: Andrew Hole [mailto:[EMAIL PROTECTED]
> Subject: Tomcat threads
>
> What's the value of Initial Number of Threads created on
> Tomcat startup?
Whatever you configured on your elements:
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
http://tomcat.apache.org/tomcat-6.0-doc/conf
>
> Have you tried running your profiler against a tomcat not doing ANY
> requests?
>
> I agree with Jim on this one - These are threads WAITING on a
> connection...
> and not doing anything.
>
> Have a look in tomcat manager, and then you can see how many 'free'
> connections
> you have.
>
>
We
It doesn't answer your question in general, but I increased mine from
300 to 900 threads on a dual-processor, dual-core machine, and saw
significantly increased throughput with short, simple requests. I
didn't try any in-between settings, though, so I don't know if there
might be a sweet spot
On 08/11/2007, at 4:51 PM, Jim Cox wrote:
On Nov 8, 2007 10:41 AM, <[EMAIL PROTECTED]> wrote:
In resolving our current bottleneck i used JProfiler to see what the
tomcat applications were doing and when under high load there are a
lot of
threads which are blocked on this:
org.apache.tomcat
On Nov 8, 2007 10:41 AM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We have an architecture where we have many tomcat app servers load
> balanced by apache at the front.
>
> In resolving our current bottleneck i used JProfiler to see what the
> tomcat applications were doing and when under high load the
ve to solve my problem
another way (MDB comes into my mind).
Thanks again,
Mirek
On 7/2/07, Johnny Kewl <[EMAIL PROTECTED]> wrote:
- Original Message -
From: "Rainer Jung" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Monday, July 02, 2007 8:24 PM
Subj
- Original Message -
From: "Rainer Jung" <[EMAIL PROTECTED]>
To: "Tomcat Users List"
Sent: Monday, July 02, 2007 8:24 PM
Subject: Re: Tomcat Threads handling user Requests problem
Johnny Kewl wrote:
Can you believe that, IE only allows 2 files downloaded a
Johnny Kewl wrote:
Can you believe that, IE only allows 2 files downloaded at the same
time, and then you have to dig into the registry get OPERA ;)
The 2 connections are a recommendation for well-behaved http clients
coming from the http spec in order to keep server load related to one
c
t;Tomcat Users List"
Sent: Monday, July 02, 2007 7:34 PM
Subject: Re: Tomcat Threads handling user Requests problem
Can you believe that, IE only allows 2 files downloaded at the same time,
and then you have to dig into the registry get OPERA ;)
Now that I advertised my favorite browse
Can you believe that, IE only allows 2 files downloaded at the same time,
and then you have to dig into the registry get OPERA ;)
Now that I advertised my favorite browser
I think its working and I have yet another theory ;)
Modern browsers dont drop the connection, because establishing a
> From: Mirek Kopriva [mailto:[EMAIL PROTECTED]
> Subject: Re: Tomcat Threads handling user Requests problem
>
> Now the problem. I can see only 2 Tomcat Threads, handling
> all of these request, which as you can imagine can take a while.
This is the result of the browser com
En l'instant précis du 02/07/07 15:55, Mirek Kopriva s'exprimait en ces
termes:
>
> There can be as many as 100 separate requests (not usual but possible)
> per a
> page load via Ajax. Some of those
> requests can take a while because of waiting for another application, I'm
> trying to integrate wi
70 matches
Mail list logo
