Java Mailing List Archive

http://www.junlu.com/

Home » users-digest.tomcat »

users Digest 20 Mar 2013 13:59:10 -0000 Issue 11304

users-digest-help

2013-03-20


Author LoginPost Reply

users Digest 20 Mar 2013 13:59:10 -0000 Issue 11304

Topics (messages 240551 through 240572)

Tomcat Behavior on Multiple HTTP requests from same browser
 240551 by: Saurabh Agrawal
 240552 by: Caldarale, Charles R
 240553 by: Nick Williams
 240554 by: Saurabh Agrawal
 240555 by: Saurabh Agrawal
 240556 by: Nick Williams
 240558 by: Saurabh Agrawal
 240559 by: Mark Thomas
 240563 by: André Warnier
 240569 by: Christopher Schultz
 240570 by: Christopher Schultz
 240571 by: Saurabh Agrawal
 240572 by: Christopher Schultz

Re: OCSP with TOMCAT 7
 240557 by: Amit A
 240564 by: André Warnier

Re: SSL Best Practices
 240560 by: Ognjen Blagojevic

[tomcat] preventing to use it at startup
 240561 by: Stadelmann Josef
 240568 by: Harris, Jeffrey E.

Re: Manager App not working with Windows authentication enabled
 240562 by: André Warnier

Re: Tomcat jdbc-pool not closing statements
 240565 by: Felix Schumacher

Re: Upgrading Tomcat in the customer base
 240566 by: Pid
 240567 by: André Warnier

Administrivia:

---------------------------------------------------------------------
To post to the list, e-mail: users@(protected)
To unsubscribe, e-mail: users-digest-unsubscribe@(protected)
For additional commands, e-mail: users-digest-help@(protected)

----------------------------------------------------------------------


Attachment: users_240551.eml (zipped)
Hi,

I have tried to find the simplest of answer from so many tomcat forums but have not got concrete answer to my query. The query I have is around management of multiple HTTP requests triggering from same browser one after other and being served by Tomcat container.

Let me take an example. Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL, tomcat will assign one of the worker threads (say Thread 1) from the pool to the HTTP request which will be processed and then response will be sent to the client. Now if I hit a link on homepage which is for login, a separate HTTP request will be initiated from the same browser.

What I want to understand is if the Tomcat will keep Thread 1 as persistent thread to server the second request (for login) from the same browser or will it assign a separate thread from the pool ?

If I look at my server logs for both the requests from client, the thread id remains the same which gives me a feeling the state of HTTP is persistent and till the time browser is not closed, the thread won't be returned to the pool.

Please can someone clarify the above behavior.

Note: I need to configure the maxThreads setting of Tomcat to support 20,000 concurrent users in the system. The above clarification will help me pick the appropriate setting for maxThreads.

Saurabh Agrawal
Manager Technology | Sapient

Aachvis Softech Private Limited SEZ,
"Oxygen", (Tower C), Ground - 3rd Floor,
Plot No. 7, Sector 144 Expressway,
Noida 201 301
Uttar Pradesh, India

Tel: +91 (120) 479 5000
Mobile: +91 981 866 4383
Fax: +91 (120) 479 5001
Email: sagrawal@sapient.com<mailto:sagrawal@(protected)>

sapient.com

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any (your) computer.

***Please consider the environment before printing this email.***


Attachment: users_240552.eml (zipped)
> From: Saurabh Agrawal [mailto:sagrawal@(protected)]
> Subject: Tomcat Behavior on Multiple HTTP requests from same browser

> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL,
> tomcat will assign one of the worker threads (say Thread 1) from the pool
> to the HTTP request which will be processed and then response will be sent
> to the client. Now if I hit a link on homepage which is for login, a separate
> HTTP request will be initiated from the same browser.

> What I want to understand is if the Tomcat will keep Thread 1 as persistent
> thread to server the second request (for login) from the same browser or will
> it assign a separate thread from the pool ?

Normally, the first available thread from the pool is used for each request. However, if you are using the BIO <Connector> with keep-alives enable *and* the browser is using keep-alives, the same thread as long as the HTTP connection is active.

See the HTTP <Connector> doc, especially the Connector Comparison at the end.

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.



Attachment: users_240553.eml (zipped)

On Mar 19, 2013, at 8:37 PM, Caldarale, Charles R wrote:

>> From: Saurabh Agrawal [mailto:sagrawal@(protected)]
>> Subject: Tomcat Behavior on Multiple HTTP requests from same browser
>
>> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL,
>> tomcat will assign one of the worker threads (say Thread 1) from the pool
>> to the HTTP request which will be processed and then response will be sent
>> to the client. Now if I hit a link on homepage which is for login, a separate
>> HTTP request will be initiated from the same browser.
>
>> What I want to understand is if the Tomcat will keep Thread 1 as persistent
>> thread to server the second request (for login) from the same browser or will
>> it assign a separate thread from the pool ?
>
> Normally, the first available thread from the pool is used for each request. However, if you are using the BIO <Connector> with keep-alives enable *and* the browser is using keep-alives, the same thread as long as the HTTP connection is active.
>
> See the HTTP <Connector> doc, especially the Connector Comparison at the end.
>
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>
> - Chuck

I think the most important thing to say here is that there is NO guarantee that the browser will always keep the connection alive, therefore there is NO guarantee that every request will get the same thread. You should never rely on having access to the same thread from one request to the next. (That is what HttpSessions are for.)

If you need to support 20,000 simultaneous users, you are going to need a farm of servers. Just one server will not be enough. One simultaneous user does not equal one thread needed: when a user is between requests, a thread can be servicing some other request. You should read the Tomcat documentation thoroughly, especial the sections on connection management, session management and clustering.

Nick

Attachment: users_240554.eml (zipped)
Hi chuck,

We have not set the "keep alive" explicitly in tomcat's server.xml. Howeverm when I print the thread id for all requests from same browser, it prints the same thread it. It gives me a feeling that all HTTP requests are holding worker thread of tomcat if they originate from same browser.

My tomcat configuration is as follows:

<Server port="${tomcat.internalserver.port}" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.core.JasperListener" />
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />

  <Service name="Catalina" >

 <Executor   name="hybrisExecutor"
          namePrefix="hybrisHTTP"
          maxThreads="${tomcat.maxthreads}"
          minSpareThreads="${tomcat.minsparethreads}"
          maxIdleTime="${tomcat.maxidletime}"/>
         
          <Connector port="${tomcat.ajp.port}"
               maxHttpHeaderSize="8192"
                   maxThreads="200"
                   protocol="org.apache.coyote.ajp.AjpProtocol"
                   executor="hybrisExecutor"
                   enableLookups="false"
                   acceptCount="100"
                   connectionTimeout="20000"
                   URIEncoding="UTF-8"
               disableUploadTimeout="true" />

  <Connector port="${tomcat.http.port}"
         maxHttpHeaderSize="8192"
         maxThreads="${tomcat.maxthreads}"
         protocol="org.apache.coyote.http11.Http11Protocol"
         executor="hybrisExecutor"
         enableLookups="false"
         acceptCount="100"
         connectionTimeout="20000"
         URIEncoding="UTF-8"
         disableUploadTimeout="true" />

  <Engine name="Catalina" defaultHost="localhost" jvmRoute="${tomcat.ajp.worker}">
 
     <Valve  className="org.apache.catalina.valves.FastCommonAccessLogValve"
           directory="${HYBRIS_LOG_DIR}/tomcat"
           prefix="access."
           suffix=".log"
           pattern="%{X-Forwarded-For}i %l %u %t %T %r %s %b %{User-Agent}i %{Referer}i %{JSESSIONID}c"
      />    

 
   <Host  name="localhost"
         appBase="webapps"
         unpackWARs="true"
         autoDeploy="false"  
         xmlValidation="false"
         xmlNamespaceAware="false">

   ${tomcat.webapps.60}
   </Host>
  </Engine>
</Service>
</Server>

Regards,
Saurabh Agrawal
Manager Technology | Sapient


-----Original Message-----
From: Caldarale, Charles R [mailto:Chuck.Caldarale@(protected)]
Sent: Wednesday, March 20, 2013 1:37 AM
To: Tomcat Users List
Subject: RE: Tomcat Behavior on Multiple HTTP requests from same browser

> From: Saurabh Agrawal [mailto:sagrawal@(protected)]
> Subject: Tomcat Behavior on Multiple HTTP requests from same browser

> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL,
> tomcat will assign one of the worker threads (say Thread 1) from the pool
> to the HTTP request which will be processed and then response will be sent
> to the client. Now if I hit a link on homepage which is for login, a separate
> HTTP request will be initiated from the same browser.

> What I want to understand is if the Tomcat will keep Thread 1 as persistent
> thread to server the second request (for login) from the same browser or will
> it assign a separate thread from the pool ?

Normally, the first available thread from the pool is used for each request. However, if you are using the BIO <Connector> with keep-alives enable *and* the browser is using keep-alives, the same thread as long as the HTTP connection is active.

See the HTTP <Connector> doc, especially the Connector Comparison at the end.

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)



Attachment: users_240555.eml (zipped)
Hi Nick,

We currently have 8 tomcat nodes with each node configured to have 1000 maxThreads. We did a round of performance test for 8000 concurrent users and the observation was that the number of active executor threads were far less.

My understanding was if 8000 concurrent users hit the site at the same time, 8000 executor threads are required to suffice the requirement of all the requests. However, I see far less executor threads in action when we put a load of 8000 concurrent users.

Regards,
Saurabh Agrawal
Manager Technology | Sapient
-----Original Message-----
From: Nick Williams [mailto:nicholas@(protected)]
Sent: Wednesday, March 20, 2013 1:44 AM
To: Tomcat Users List
Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser


On Mar 19, 2013, at 8:37 PM, Caldarale, Charles R wrote:

>> From: Saurabh Agrawal [mailto:sagrawal@(protected)]
>> Subject: Tomcat Behavior on Multiple HTTP requests from same browser
>
>> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL,
>> tomcat will assign one of the worker threads (say Thread 1) from the pool
>> to the HTTP request which will be processed and then response will be sent
>> to the client. Now if I hit a link on homepage which is for login, a separate
>> HTTP request will be initiated from the same browser.
>
>> What I want to understand is if the Tomcat will keep Thread 1 as persistent
>> thread to server the second request (for login) from the same browser or will
>> it assign a separate thread from the pool ?
>
> Normally, the first available thread from the pool is used for each request. However, if you are using the BIO <Connector> with keep-alives enable *and* the browser is using keep-alives, the same thread as long as the HTTP connection is active.
>
> See the HTTP <Connector> doc, especially the Connector Comparison at the end.
>
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>
> - Chuck

I think the most important thing to say here is that there is NO guarantee that the browser will always keep the connection alive, therefore there is NO guarantee that every request will get the same thread. You should never rely on having access to the same thread from one request to the next. (That is what HttpSessions are for.)

If you need to support 20,000 simultaneous users, you are going to need a farm of servers. Just one server will not be enough. One simultaneous user does not equal one thread needed: when a user is between requests, a thread can be servicing some other request. You should read the Tomcat documentation thoroughly, especial the sections on connection management, session management and clustering.

Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)



Attachment: users_240556.eml (zipped)

On Mar 19, 2013, at 8:49 PM, Saurabh Agrawal wrote:

> Hi Nick,
>
> We currently have 8 tomcat nodes with each node configured to have 1000 maxThreads. We did a round of performance test for 8000 concurrent users and the observation was that the number of active executor threads were far less.
>
> My understanding was if 8000 concurrent users hit the site at the same time, 8000 executor threads are required to suffice the requirement of all the requests. However, I see far less executor threads in action when we put a load of 8000 concurrent users.
>

Yes, this is to be expected. Tomcat / the JVM will try to be as efficient as possible. A thread will only be in use during an active request. Just because you have 8,000 simultaneous users does not mean you have 8,000 simultaneous requests. Remember that "real" users will have some time between each request, ranging from a few seconds to several minutes depending on the page and the user. A good load testing tool like JMeter, The Grinder, or NeoLoad (just examples) will mimic this behavior by putting varying pauses between requests. It sounds like whatever tool you are using is doing this--that's good! So, 8,000 simultaneous users might result in only 400-500 simultaneous requests (just a guess; depends on your application and its user base). In this case, you'd only see 400-500 threads used across the cluster.

In your small-scale test, where each request from your browser got the same thread, that could just be pure luck. If you're the only person using the server, it's likely that the Thread pool is extremely small, thus the odds are high that the same thread would get picked over and over again. However, in a high-load environment, this will not be the case, and the number of threads will nearly always be less than the number of simultaneous users.

I'm glad to see that you have a working cluster of some sorts and that you are performing load tests to evaluate its performance. This means you are on the right track, making some good decisions, and have obviously done a little reading. I suspect a little more reading of the Connector documentation will help you understand exactly how all of this works.

Nick

P.S. Please remember to bottom post. Don't top post.

> -----Original Message-----
> From: Nick Williams [mailto:nicholas@(protected)]
> Sent: Wednesday, March 20, 2013 1:44 AM
> To: Tomcat Users List
> Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser
>
>
> On Mar 19, 2013, at 8:37 PM, Caldarale, Charles R wrote:
>
>>> From: Saurabh Agrawal [mailto:sagrawal@(protected)]
>>> Subject: Tomcat Behavior on Multiple HTTP requests from same browser
>>
>>> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL,
>>> tomcat will assign one of the worker threads (say Thread 1) from the pool
>>> to the HTTP request which will be processed and then response will be sent
>>> to the client. Now if I hit a link on homepage which is for login, a separate
>>> HTTP request will be initiated from the same browser.
>>
>>> What I want to understand is if the Tomcat will keep Thread 1 as persistent
>>> thread to server the second request (for login) from the same browser or will
>>> it assign a separate thread from the pool ?
>>
>> Normally, the first available thread from the pool is used for each request. However, if you are using the BIO <Connector> with keep-alives enable *and* the browser is using keep-alives, the same thread as long as the HTTP connection is active.
>>
>> See the HTTP <Connector> doc, especially the Connector Comparison at the end.
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>>
>> - Chuck
>
> I think the most important thing to say here is that there is NO guarantee that the browser will always keep the connection alive, therefore there is NO guarantee that every request will get the same thread. You should never rely on having access to the same thread from one request to the next. (That is what HttpSessions are for.)
>
> If you need to support 20,000 simultaneous users, you are going to need a farm of servers. Just one server will not be enough. One simultaneous user does not equal one thread needed: when a user is between requests, a thread can be servicing some other request. You should read the Tomcat documentation thoroughly, especial the sections on connection management, session management and clustering.
>
> Nick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>



Attachment: users_240558.eml (zipped)
Hi Nick,
Thanks for your valuable feedback.

The point I was trying to make when I mentioned that all requests from the same browser results in same thread is not a mere coincidence. The reason why it may not be sheer luck is because we have seen this on production which is accessed by more than 1000 simultaneous users on the site. Currently we trace the user journey by the thread id in the logs and my observation is all 1000 users (across the globe) gets the same thread id from the pool when they access subsequent URLS from the browser.
It makes me feel as if the thread is not returned to the pool till the session times out or the user has closed the browser. Although the behavior is weird because tomcat won't should not have a persistent connection as it would mean improper use of the resources (thread).

I read the connector documentation and my gathering is threads are allocated per request and they are returned to the pool once the HTTP response in sent back to the client. However, if that's the case my thread ids should be different when the user accesses multiple pages on the site from same browser. Also printing the thread id may not be the right way to trace user journey then.

Also I understand there may be difference in milli seconds or seconds between 10000 concurrent user requests and it may not be exactly 10000 users in system at one go but I can also simulate 10,000 concurrent request at same time even in milli seconds. Google analytics does show 10,000 concurrent users. In that case I assume it will leverage 10,000 concurrent threads.

Let me know your thoughts around it.

Regards,
Saurabh Agrawal
Manager Technology | Sapient

-----Original Message-----
From: Nick Williams [mailto:nicholas@(protected)]
Sent: Wednesday, March 20, 2013 2:31 AM
To: Tomcat Users List
Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser


On Mar 19, 2013, at 8:49 PM, Saurabh Agrawal wrote:

> Hi Nick,
>
> We currently have 8 tomcat nodes with each node configured to have 1000 maxThreads. We did a round of performance test for 8000 concurrent users and the observation was that the number of active executor threads were far less.
>
> My understanding was if 8000 concurrent users hit the site at the same time, 8000 executor threads are required to suffice the requirement of all the requests. However, I see far less executor threads in action when we put a load of 8000 concurrent users.
>

Yes, this is to be expected. Tomcat / the JVM will try to be as efficient as possible. A thread will only be in use during an active request. Just because you have 8,000 simultaneous users does not mean you have 8,000 simultaneous requests. Remember that "real" users will have some time between each request, ranging from a few seconds to several minutes depending on the page and the user. A good load testing tool like JMeter, The Grinder, or NeoLoad (just examples) will mimic this behavior by putting varying pauses between requests. It sounds like whatever tool you are using is doing this--that's good! So, 8,000 simultaneous users might result in only 400-500 simultaneous requests (just a guess; depends on your application and its user base). In this case, you'd only see 400-500 threads used across the cluster.

In your small-scale test, where each request from your browser got the same thread, that could just be pure luck. If you're the only person using the server, it's likely that the Thread pool is extremely small, thus the odds are high that the same thread would get picked over and over again. However, in a high-load environment, this will not be the case, and the number of threads will nearly always be less than the number of simultaneous users.

I'm glad to see that you have a working cluster of some sorts and that you are performing load tests to evaluate its performance. This means you are on the right track, making some good decisions, and have obviously done a little reading. I suspect a little more reading of the Connector documentation will help you understand exactly how all of this works.

Nick

P.S. Please remember to bottom post. Don't top post.

> -----Original Message-----
> From: Nick Williams [mailto:nicholas@(protected)]
> Sent: Wednesday, March 20, 2013 1:44 AM
> To: Tomcat Users List
> Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser
>
>
> On Mar 19, 2013, at 8:37 PM, Caldarale, Charles R wrote:
>
>>> From: Saurabh Agrawal [mailto:sagrawal@(protected)]
>>> Subject: Tomcat Behavior on Multiple HTTP requests from same browser
>>
>>> Let's say I hit http://localhost:9001/homepage.html. Upon hitting the URL,
>>> tomcat will assign one of the worker threads (say Thread 1) from the pool
>>> to the HTTP request which will be processed and then response will be sent
>>> to the client. Now if I hit a link on homepage which is for login, a separate
>>> HTTP request will be initiated from the same browser.
>>
>>> What I want to understand is if the Tomcat will keep Thread 1 as persistent
>>> thread to server the second request (for login) from the same browser or will
>>> it assign a separate thread from the pool ?
>>
>> Normally, the first available thread from the pool is used for each request. However, if you are using the BIO <Connector> with keep-alives enable *and* the browser is using keep-alives, the same thread as long as the HTTP connection is active.
>>
>> See the HTTP <Connector> doc, especially the Connector Comparison at the end.
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>>
>> - Chuck
>
> I think the most important thing to say here is that there is NO guarantee that the browser will always keep the connection alive, therefore there is NO guarantee that every request will get the same thread. You should never rely on having access to the same thread from one request to the next. (That is what HttpSessions are for.)
>
> If you need to support 20,000 simultaneous users, you are going to need a farm of servers. Just one server will not be enough. One simultaneous user does not equal one thread needed: when a user is between requests, a thread can be servicing some other request. You should read the Tomcat documentation thoroughly, especial the sections on connection management, session management and clustering.
>
> Nick
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)



Attachment: users_240559.eml (zipped)
Nick Williams <nicholas@(protected):

>On Mar 19, 2013, at 8:49 PM, Saurabh Agrawal wrote:
>
>> Hi Nick,
>>
>> We currently have 8 tomcat nodes with each node configured to have
>1000 maxThreads. We did a round of performance test for 8000 concurrent
>users and the observation was that the number of active executor
>threads were far less.
>>
>> My understanding was if 8000 concurrent users hit the site at the
>same time, 8000 executor threads are required to suffice the
>requirement of all the requests. However, I see far less executor
>threads in action when we put a load of 8000 concurrent users.
>>
>
>Yes, this is to be expected. Tomcat / the JVM will try to be as
>efficient as possible. A thread will only be in use during an active
>request.

The correctness of that statement is highly dependent on the connector used and how it is configured.

> Just because you have 8,000 simultaneous users does not mean
>you have 8,000 simultaneous requests.

+1

>> If you need to support 20,000 simultaneous users, you are going to
>need a farm of servers. Just one server will not be enough.

How many servers you need will depend on the app and how those users use it. It is perfectly possible for one server to serve 20,000 simultaneous users. 20,000 simultaneous requests is more likely to require multiple servers but again - it depends.

Mark



Attachment: users_240563.eml (zipped)
Mark Thomas wrote:
> Nick Williams <nicholas@(protected):
>
>> On Mar 19, 2013, at 8:49 PM, Saurabh Agrawal wrote:
>>
>>> Hi Nick,
>>>
>>> We currently have 8 tomcat nodes with each node configured to have
>> 1000 maxThreads. We did a round of performance test for 8000 concurrent
>> users and the observation was that the number of active executor
>> threads were far less.
>>> My understanding was if 8000 concurrent users hit the site at the
>> same time, 8000 executor threads are required to suffice the
>> requirement of all the requests. However, I see far less executor
>> threads in action when we put a load of 8000 concurrent users.
>> Yes, this is to be expected. Tomcat / the JVM will try to be as
>> efficient as possible. A thread will only be in use during an active
>> request.
>
> The correctness of that statement is highly dependent on the connector used and how it is configured.
>
>> Just because you have 8,000 simultaneous users does not mean
>> you have 8,000 simultaneous requests.
>
> +1
>
>>> If you need to support 20,000 simultaneous users, you are going to
>> need a farm of servers. Just one server will not be enough.
>
> How many servers you need will depend on the app and how those users use it. It is perfectly possible for one server to serve 20,000 simultaneous users. 20,000 simultaneous requests is more likely to require multiple servers but again - it depends.
>

If I may add something : at some point, on each Tomcat server, there is only 1 "listening
socket" for one port (the point being : you could have several, but you won't have 8000).
So even if your clients really send 8000 TCP requests to the server at the same moment,
they will be serialized at some point, and from the server's point of view, they come in
one by one. /Then/ the server (provided it's TCP stack and all the rest is fast enough)
can start distributing them over a pool of Threads.
I know that this is an absurd example, but just to provide one extreme point of view :
unless you have 8000 independent clients each firing one request at the sam time over 8000
cables connecting to 8000 ports, each one being served by one CPU core running its own TCP
stack and its own Tomcat, you will never really have 8000 requests being processed really
simultaneously.
So the "simultaneousness" is a question of degree, not an absolute value.
And the "degree of simultaneousness" depends on many factors, among which are (but none of
them to be considered alone) : the network, the front-end, the client keepalive setting,
the server keepalive setting, the number of connections that the client opens
simultaneously, the choice of Connector(s), the usage or not of an Executor, the degree to
which the requests (and responses) are really similar, the number of configured threads,
the time needed to process each request, the CPU speed, the amount of memory etc. etc.
And finally, the number of Threads that are started or are "running" simultaneously
depends on all these factors, and the only one who has access to all these factors is you.

If you fire 8000 "simultaneous" requests from clients, and you see only 200 Threads
running to process them, then obviously there is a bottleneck somewhere. But it is not
necessarily Tomcat which is not allocating all the Threads that it could be allocating.
It could just be that Tomcat does not get more requests to allocate a Thread for, because
they get slowed down (or discarded) somewhere else along the line.
Or it could be that Tomcat just is not getting enough CPU cycles to be able to allocate
more Threads and running them.

I some configurations, and with some kinds of client requests patterns, a longer keepalive
setting can make it so that one Tomcat thread stays allocated to one client connection,
waiting for futher requests on that connection (which may never come). In some kinds of
use cases, that is efficient, in others it is very inefficient. Like everything else, it
depends..


Attachment: users_240569.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Saurabh,

On 3/19/13 8:55 PM, Saurabh Agrawal wrote:
> What I want to understand is if the Tomcat will keep Thread 1 as
> persistent thread to server the second request (for login) from
> the same browser or will it assign a separate thread from the pool
> ?

Tomcat will assign an arbitrary (i.e. random) thread from the pool.

> If I look at my server logs for both the requests from client, the
> thread id remains the same which gives me a feeling the state of
> HTTP is persistent and till the time browser is not closed, the
> thread won't be returned to the pool.
>
> Please can someone clarify the above behavior.

What you are probably observing is a server under very low load (maybe
just your two example requests) that just happens to process the two
requests with the same thread.

Don't worry: the threads go back into the pool right away (after the
keepalive timeout, if you are using the BIO connector which is
currently the default).

> Note: I need to configure the maxThreads setting of Tomcat to
> support 20,000 concurrent users in the system. The above
> clarification will help me pick the appropriate setting for
> maxThreads.

20,000 concurrent users is no problem. How often do they all make
requests?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFJvhAACgkQ9CaO5/Lv0PAkXwCfS5GE/d1yk+w1gN6xNvQ9LLfA
y7sAoJjfeun+2Njsu47uBMrWhDl1xzIv
=en0N
-----END PGP SIGNATURE-----


Attachment: users_240570.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Nick,

On 3/19/13 10:31 PM, Nick Williams wrote:
> I'm glad to see that you have a working cluster of some sorts and
> that you are performing load tests to evaluate its performance.
> This means you are on the right track, making some good decisions,
> and have obviously done a little reading.

+1000

It's refreshing to see someone actually performing load-tests against
their configuration while tweaking their settings rather than just
saying "I need to support a million users", setting
maxThreads="1000000", setting PermGen to 3GiB, changing the thread
stack size, and micro-managing the garbage collector.

Well done.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFJvvcACgkQ9CaO5/Lv0PDthgCaA+XQogABsObUGwSUYCeOXadA
BAEAnA7+BHlzmZkgKgAKwXZ0v+9pGrga
=yQdQ
-----END PGP SIGNATURE-----


Attachment: users_240571.eml (zipped)
There will be a load of 20,000 users for a special festival for around 4-5 hours ONLY.

Regards,
Saurabh Agrawal
Manager Technology | Sapient


-----Original Message-----
From: Christopher Schultz [mailto:chris@(protected)]
Sent: Wednesday, March 20, 2013 1:48 PM
To: Tomcat Users List
Subject: Re: Tomcat Behavior on Multiple HTTP requests from same browser

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Saurabh,

On 3/19/13 8:55 PM, Saurabh Agrawal wrote:
> What I want to understand is if the Tomcat will keep Thread 1 as
> persistent thread to server the second request (for login) from
> the same browser or will it assign a separate thread from the pool
> ?

Tomcat will assign an arbitrary (i.e. random) thread from the pool.

> If I look at my server logs for both the requests from client, the
> thread id remains the same which gives me a feeling the state of
> HTTP is persistent and till the time browser is not closed, the
> thread won't be returned to the pool.
>
> Please can someone clarify the above behavior.

What you are probably observing is a server under very low load (maybe
just your two example requests) that just happens to process the two
requests with the same thread.

Don't worry: the threads go back into the pool right away (after the
keepalive timeout, if you are using the BIO connector which is
currently the default).

> Note: I need to configure the maxThreads setting of Tomcat to
> support 20,000 concurrent users in the system. The above
> clarification will help me pick the appropriate setting for
> maxThreads.

20,000 concurrent users is no problem. How often do they all make
requests?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFJvhAACgkQ9CaO5/Lv0PAkXwCfS5GE/d1yk+w1gN6xNvQ9LLfA
y7sAoJjfeun+2Njsu47uBMrWhDl1xzIv
=en0N
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)


Attachment: users_240572.eml (zipped)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Saurabh,

On 3/20/13 3:27 AM, Saurabh Agrawal wrote:
> The point I was trying to make when I mentioned that all requests
> from the same browser results in same thread is not a mere
> coincidence. The reason why it may not be sheer luck is because we
> have seen this on production which is accessed by more than 1000
> simultaneous users on the site. Currently we trace the user
> journey by the thread id in the logs and my observation is all 1000
> users (across the globe) gets the same thread id from the pool when
> they access subsequent URLS from the browser.

Is the reverse true? Do you ever see thread A used by more than one
client? Or is it a one-to-one mapping?

> It makes me feel as if the thread is not returned to the pool till
> the session times out or the user has closed the browser. Although
> the behavior is weird because tomcat won't should not have a
> persistent connection as it would mean improper use of the
> resources (thread).

Tomcat is doing its job just fine, otherwise half the Java servers in
the world would lock-up and stop working.

What may be happening is that your browser is maintaining a keep-alive
connection long enough (maybe 10 seconds?) that the "next" request can
be sent over the same connection, and will get the same thread. So, if
you have fairly quick-responding clients, you may see that each one is
kind of monopolizing a thread for a while. Honestly, if that's the
case, it's a *good* case as long as you aren't running out of threads.

It would be interesting to see how you have your <Connector>
configured, and how you have your load-balancer configured, too.

> Also I understand there may be difference in milli seconds or
> seconds between 10000 concurrent user requests and it may not be
> exactly 10000 users in system at one go but I can also simulate
> 10,000 concurrent request at same time even in milli seconds.
> Google analytics does show 10,000 concurrent users. In that case I
> assume it will leverage 10,000 concurrent threads.

Users != requests. 10,000 concurrent users might generate 1000
simultaneous requests (that is, requests in-progress at a particular
instant), unless they are really pounding on your cluster. What do
your thread-pool usage metrics look like? Are you collecting that data
(hint: do it)? Are you graphing them (hint: do that, too)?

Doing time-based graphing can help you visualize your user load
(measured in requests-per-second versus total average concurrent
users, which is a nearly useless metric unless you have 100MiB
sessions or something and you have to use that as part of your
capacity plan) and you can even see things like "hey, every day at
11:00 PDT we hit our maxThreads for 5 minutes". That lets you know
that you need to give yourself a little more breathing room and then
watch for another couple of days.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEAREIAAYFAlFJwI8ACgkQ9CaO5/Lv0PD8QACdHdYnkzzZbcbmq4dmayaguTp/
eDcAn2dGIn63MJRtbllnJcaicIClmJDp
=AfQh
-----END PGP SIGNATURE-----


Attachment: users_240557.eml (zipped)
I need to enable OCSP on my application which is running Tomcat 7.0.29.
Looked up the documentation but did not find quite much :
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html

1. Is OCSP with just tomcat actually possible? Do we need a external
module/software?
2. Has anyone implemented/Configured OCSP with Tomcat? I am looking for the
nitty gritties here.

>

Attachment: users_240564.eml (zipped)
Amit A wrote:
> I need to enable OCSP on my application which is running Tomcat 7.0.29.
> Looked up the documentation but did not find quite much :
> http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
>
> 1. Is OCSP with just tomcat actually possible? Do we need a external
> module/software?
> 2. Has anyone implemented/Configured OCSP with Tomcat? I am looking for the
> nitty gritties here.
>
>
Search the list archives. There was a question/response about this exact subject just a
few days ago.



Attachment: users_240560.eml (zipped)
Jeffrey,

On 19.3.2013 15:33, Jeffrey D. Fisher wrote:
> Yes, I do have a CA-issued certificate with a chain to a trusted CA. I've
> imported it to the keystore. I am close to a solution. When I attempt to
> open the default Apache web page using "https:" I get an error page that
> says that the server cannot open the page.

Your HTTPS connector probably isn't configured right, or you are trying
to access a wrong port.

Check with netstat ("netstat -anp tcp" on Windows or "netstat -tnlp" on
Linux) do you have a process listening on port 443.


> It opens with "http:" just fine.

Good, your HTTP connector seems to be working just fine.


> I have configured the normal ports i.e. "80" and "443" to redirect to
> "8443". The reason for this is that the users having to include the port
> numbers (8080 or 8443) would not be acceptable. They need only enter the
> DNS name into the browser and DNS does the rest.

How did you configured redirection? There are several ways to have your
server listen on standard ports 80 and 443 (iptables, jsvc, Apache
httpd...), each with its own peculiarities. Please provide detailed
description how did you do it.


> I am missing something in the configuration of SERVER.XML, WEB.XML or both
> to get the server to answer to an https connection. I cannot find what it
> is that I have not done or I have missed!

Well, it is hard to say, with the information you provided so far. Could
you please post your server.xml configuration with comments and
passwords removed, so we could tell you if it is configured right.

It would also help us if you post relevant parts of your log files. Here
is the sample saying that both HTTP and HTTPS connectors are started on
ports 80 and 443:

Mar 13, 2013 5:32:13 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-80"]
Mar 13, 2013 5:32:13 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-443"]
Mar 13, 2013 5:32:13 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in ... ms

Do you have something similar in your log files?


You also used the phrase "default Apache web page". Apache is ambiguous
term here. I do not understand did you mean "default Apache Tomcat web
page" or "default Apache httpd web page" or something else. Some people
prefer to use Apache Tomcat as a web server, while others use Apache
httpd as front end, and Apache Tomcat as servlet container.

-Ognjen


Attachment: users_240561.eml (zipped)
Hi

Is there an easy way to manage, to prevent, that my AS Tomcat is serving

request before it is fully up and running; while fully up means - it has
deployed
all web apps and web app axis2 (a servlet engine) is up and has deployed
all its
modules *.mar and web service archives *.aar before any requests for
this web
services are accepted.

Josef

Attachment: users_240568.eml (zipped)


> -----Original Message-----
> From: Stadelmann Josef [mailto:josef.stadelmann@(protected)]
> Sent: Wednesday, March 20, 2013 5:06 AM
> To: users@(protected)
> Subject: [tomcat] preventing to use it at startup
>
> Hi
>
> Is there an easy way to manage, to prevent, that my AS Tomcat is
> serving
>
> request before it is fully up and running; while fully up means - it
> has deployed all web apps and web app axis2 (a servlet engine) is up
> and has deployed all its modules *.mar and web service archives *.aar
> before any requests for this web services are accepted.
>
> Josef

Just as a quick thought, presuming you have a way of determining that the server is ready,
why not just block the port on the local firewall until the server is ready, and then unblock
the port? That means you would have to turn the firewall on if it is not currently
running.

You could script this into a startup task on the server.

Jeffrey Harris

This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.


Attachment: users_240562.eml (zipped)
Harris Mark R wrote:
> Sorry, guess I was not clear enough. We are using Microsoft's IIS to front-end Tomcat, not the Apache HTTP server. Apache HTTP server is not an option for our environment. We would prefer to use the Windows authenticated user passed to Tomcat by IIS, but are open to anything that works reliably.
>
It's my turn to apologise. That was clear in your original post, I just misread that.
It is the same however with IIS. If the user is authenticated by IIS, and you set
tomcatAuthentication="false", then Tomcat will take the user-id from what the IIS/AJP
module is passing on from IIS, and it will not redo the user authentication by himself
(him being Tomcat).


> As I said, our custom application is working great in this environment, but the manager app is not. We are having trouble associating the roles that the manager app is expecting with the authenticated user.  We have tried altering the tomcat-users file just about every which way we could think of.  Essentially we need any way to associate the authenticated user with the " "manager-gui" that the manager app is expecting. Would we need to implement a custom realm to make this work?
>
Yes, I think that you understand the issue correctly.
Tomcat's standard "user access control" to an application is based on the concept of
"roles". You tell Tomcat that any users who has a "role" xxx can access that application.
So Tomcat needs a way, given the present user-id, to find out if that user-id has this
"role" (isUserInRole() ?). Unfortunately, what AJP passes to Tomcat is only a user-id,
not any kind of "roles" information that this user has. I suppose that Tomcat somehow
must use a <Realm> to get that kind of information, and I do not know if this Realm is
capable of providing that information if it has not authenticated this user by itself.

Maybe there is a way to tell Tomcat, for the manager application, to just check the
user-id, and not the role ? I suppose that the right place to check would be the
applicable Servlet Specification, in the web.xml/<auth-constraints> paragraph.
How do you do it for your other application, the one that works ?


On a totally different track, if you want to use WIA anyway, you may want to have a look
at Jespa, at http://www.ioplex.com. It's a totally different authentication and security
approach. based on a servlet filter in Tomcat which authenticates the Windows user
directly at the Tomcat level, not on the base of the id that IIS determines (and AJP
passes on). Jespa is capable of "translating" the concept of Windows "users groups" into
Tomcat "roles". One advantage of that approach is that you would have the various Tomcat
"roles" managed at the same place as the other user-management functions (on the Windows
domain AD server), and not have a different set of user information for Tomcat alone.



Attachment: users_240565.eml (zipped)
Am 19.03.2013 22:20, schrieb Bertrand Guay-Paquet:
> On 19/03/2013 5:05 PM, Felix Schumacher wrote:
>> Have you looked at
>> http://grokbase.com/t/openejb/users/13135d2a0v/jdbc-connection-pool-memory-leak
>> ? It seems like your problem. Regards Felix
>
> Indeed, this is extremely similar to my issue. Thanks for sharing
> this.
>
> It does seem however like the StatementFinalizer Tomcat interceptor
> should not be necessary if an application closes its connections,
> statements and result sets properly. From what I could see by stepping
> in the code, this is the case with MyBatis. The actual source of the
> problem really seems to be that Tomcat's jdbc pool swallows calls to
> Statement.close() like I showed in my original message.
Now that I had time to look more closely, I believe you are right and
the assignment of 'closed' and 'delegate' before (or even after) the
call to super.closeInvoked() looks like a bug, too.

So I think you should go ahead and file one in bugzilla. You should
keep in mind, that afaik the StatementCache is not enabled by default in
tomcat.

Regards
Felix
>
> Regards,
> Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)


Attachment: users_240566.eml (zipped)
On 19/03/2013 19:24, Patrick Flaherty wrote:
> Hi,
>
> We deploy tomcat in our own folder (c:\rsi_tc\tomcat) on a WIndows
> machine as a service. We use the service.bat to install
> as a service. Historically to update tomcat we would remove the current
> version and install the new version. There is rub in all
> this which we have to change the service login to be an account that can
> access files from a network share. Therefore when
> we upgrade tomcat, we remove the current version and install the new
> version and then someone ( the customer :-( ) has to
> go into the service and change the service login back to the account
> that will give them access to the network share.

What is on the network share?


p


> I'm looking for a way (if possible) to avoid having the customer to have
> change the service login. I'm looking for suggestions
> to make this easier and have the following questions about whether some
> of my thoughts to make it easier are safe.
>
> 1. Can I *not* uninstall the service and just replace the folder
> structure on the file system with the new version? I have tried it
>   and it seems to work but question whether or not it is safe. I know
> if a major version changes I cannot do this as the service
>   calls tomcat6.exe vs tomcat7.exe for instance and therefore would
> have to do the complete uninstall/install.
>
> 2. If I do the above does calling the "service.bat install" again using
> the *newer* service.bat version make a difference? We are calling it
> (the newer service.bat)
>   and it seems to be harmless and thought that it might help in case
> something in the batch install changed, we would get the changes.
>
> Bottom line, has anyone faced this dilemma and found a successful way to
> upgrade a tomcat instance that uses a unique service login.
>
> Thanks for any input.
> Pat
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>


--

[key:62590808]


Attachment: users_240567.eml (zipped)
Pid wrote:
> On 19/03/2013 19:24, Patrick Flaherty wrote:
>> Hi,
>>
>> We deploy tomcat in our own folder (c:\rsi_tc\tomcat) on a WIndows
>> machine as a service. We use the service.bat to install
>> as a service. Historically to update tomcat we would remove the current
>> version and install the new version. There is rub in all
>> this which we have to change the service login to be an account that can
>> access files from a network share. Therefore when
>> we upgrade tomcat, we remove the current version and install the new
>> version and then someone ( the customer :-( ) has to
>> go into the service and change the service login back to the account
>> that will give them access to the network share.
>
> What is on the network share?
>

It seems to me that in this case, the "minimally-invasive" solution might just be some
script which changes the user-id under which the service runs, particularly if this
user-id already exists and has the correct permissions and has "the right to run a
Service". The Tomcat update already requires running as an Administrator, so this script
could run in the same context.
A small VBS script e.g.
Or just this command-line maybe :

sc config <servicename> obj= <accountname> pass= <password>

It uses the Windows built-in utility sc to change the credential of a windows service.


Source : serching Google for "vbs change service login".

©2008 junlu.com - Jax Systems, LLC, U.S.A.