Re: Jmeter throughput with tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Raviraj, On 9/13/17 1:38 PM, RAVIRAJ SHAH wrote: > Dear all I have checked performance of my tomcat server 9. 0.26 > with jmeter with 1000 threads which gives me 142 throughput/sec > Whereas same test i done with jboss wildfly and it gives 450 > throughput/sec > > What could be reason for the same it jboss wildfly is better than > tomcat in context to performance Configuration, please? What is the workload? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZuZsIAAoJEBzwKT+lPKRY8tcP/0jxmpqeRdTakGhmC7DOLpAe I7mpxl41toxCm2d2It/6edvYujRvTzDKrj7ut3oSsMRvmvdZ/QYzgoL9nHFniv9r yu7nhAFgDCdUw9er67LgtDZ+4Dsb2G2ENKWUFLQoSBQNk1SKxWVWLPSalBzEOlys G7A1KUvZfaBpbvWLkdGQnKCtyUPAv+NkYJv2QFg0wJaOBixCLeAxO4BQnDQO0udb TrvfkpWg3ckvGfWV+vlQesb0dCWKfwit/rs3ATEONVmcqP/wAsj04JJCtouNsNyM FScr5xV2xB6ltvVGZGcJvDgnTYh5TK2zK4woBU+jjnooWbwNVgUfbs9tB8V8T258 2M/7/q90ViyLgtCg7V9CWiCyuTOTunjvvqH3mAuAWo62qFR5tG6gF5jcJxul1ZjA pvZ/i62WEXW37PyBLi9bPEF2c3VeC3kIh95Wdt2eVQUKFv5jDllIE7ggraD/Kx5x 3aITsxd9nqJwdCoe0KXAquU63YgCVpUY0uvUKgnOveQyQUMVfhyIspt+2mPHltbi oPeJY+ufLchRb0BYoe7L1EzYpCw0G3Q6d9fU7Ta72fkiOy+knp7utrY7g6tHxb99 pRWRCES9PJpSGoEJez58EgxmF+sfuTS5VmK5XimtgiYPrbxow3PTWSg+kAzUg8nd euwLjrUhdYg8MdGjLKyC =BMqO -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat misuse of Servlet 3.0's asynchronous support
On 9/13/2017 9:49 PM, Mark Thomas wrote:
> On 05/09/2017 19:56, Yasser Zamani wrote:
>> Thanks a lot Mark!
>>
>> Yes I knew these and before tested that a tomcat with 400 max threads
>> "scalabilitaly is equal" to a tomcat with 200 max threads but with
>> servlet 3's async API including application's thread pool with size 200.
>>
>> However so far I thought Oracle's docs are like standards and tomcat
>> have to satisfy them :)
>
> Tomcat implements the Servlet, JSP, UEL, EL and JASPIC specifications.
>
> The document you refer to is not part of those specs and, as I said, it
> is misleading at best.
>
>>> That does increase scalability
>>> because rather than having a bunch of threads waiting for these
>>> non-blocking operations to complete, those threads can do useful work.
>>
>> But tomcat blocks another thread from container's thread pool for
>> waiting or locking on that non-blocking operation's response!
>
> As I said, if the async API is used to move a blocking operation from
> one thread to another, that won't improve scalability.
>
> You are only going to improve scalability if you move non-blocking
> operations from the Servlet.service() method (which has to block waiting
> for the non-blocking operation to complete) to the async API.
> Essentially, if you leave it in the service() method you have one thread
> allocated to each non-blocking operation.
>
> If the Servlet async API is used, the non-blocking operation is started
> and the container thread continues to complete the service method. The
> container thread is now free to do other useful work and the
> non-blocking operation isn't using any thread at all - and won't until
> the operation completes at which point it will require a thread to
> perform the dispatch back to the container and then to process that
> dispatch.
>
:S I apologize as I know that I fails to understand some points again.
Please excuse me bothering you.
The non-blocking operation isn't using any thread at all ?! So which
thread executes my Runnable passed to startAsync? At my first initial
mail, I see Tomcat passes that to it's thread pool. If I define my
non-blocking operation (that Runnable) as
System.out.println(Thread.getCurrentThread.getName()), I'll see
"http-nio-exec-XX which means Tomcat's thread pool has been allocated a
thread for my Runnable non-blocking operation. However, maybe you mean a
real IO wait as non-blocking operation.
Let forget scalablity. Could you please define an example business
operational and functional scenario which using Servlet's async API
improves or resolve it in such way that could not being improved or
resolved with NIO and increasing maxThreads and maxConnections?
> In this case a container thread is only required up to the point where
> there non-blocking operation starts and form the point where it
> completes. While the non-blocking operation is in progress, the
> container thread is free to do other useful work.
>
> Mark
>
>
>> so I do
>> not agree that "because those threads can do useful work" then "does
>> increase scalability". I think Servlet 3's async API here may increase
>> scalability if and only if the released thread also releases some
>> resources which other threads may are blocked on them. and if and only
>> if the new thread does not lock more resources than the original one.
>> **Actually as I understand, using Servlet 3's async API compared with
>> tomcat's nio with greater max threads, does not have any gain except
>> what I wrote above and also preventing deadlocks. wdyt?**
>>
>> On 9/5/2017 11:57 AM, Mark Thomas wrote:
>>> On 03/09/17 09:01, Yasser Zamani wrote:
Hi there,
At [1] we read:
> Web containers in application servers normally use a server thread
> per client request. Under heavy load conditions, containers need a
> large amount of threads to serve all the client requests.
> Scalability limitations include running out of memory or
> *exhausting the pool of container threads*. To create scalable web
> applications, you must ensure that no threads associated with a
> request are sitting idle, so *the container can use them to
> process new requests*. Asynchronous processing refers to
> *assigning these blocking operations to a new thread and returning
> the thread associated with the request immediately to the container*.
>
I could not achieve this scalability in tomcat via calling
`javax.servlet.AsyncContext.start(Runnable)`! I investigated the cause
and found it at [2]:
public synchronized void asyncRun(Runnable runnable) {
...
processor.execute(runnable);
I mean `processor.execute(runnable)` uses same thread pool which it's
also it's duty to process new requests! Such usage made things worse!
i.e. not only does not make thread pool more free to process new
request
Jmeter throughput with tomcat
Dear all I have checked performance of my tomcat server 9. 0.26 with jmeter with 1000 threads which gives me 142 throughput/sec Whereas same test i done with jboss wildfly and it gives 450 throughput/sec What could be reason for the same it jboss wildfly is better than tomcat in context to performance Kindly guide Thanks
Re: Tomcat misuse of Servlet 3.0's asynchronous support
On 05/09/2017 19:56, Yasser Zamani wrote:
> Thanks a lot Mark!
>
> Yes I knew these and before tested that a tomcat with 400 max threads
> "scalabilitaly is equal" to a tomcat with 200 max threads but with
> servlet 3's async API including application's thread pool with size 200.
>
> However so far I thought Oracle's docs are like standards and tomcat
> have to satisfy them :)
Tomcat implements the Servlet, JSP, UEL, EL and JASPIC specifications.
The document you refer to is not part of those specs and, as I said, it
is misleading at best.
>> That does increase scalability
>> because rather than having a bunch of threads waiting for these
>> non-blocking operations to complete, those threads can do useful work.
>
> But tomcat blocks another thread from container's thread pool for
> waiting or locking on that non-blocking operation's response!
As I said, if the async API is used to move a blocking operation from
one thread to another, that won't improve scalability.
You are only going to improve scalability if you move non-blocking
operations from the Servlet.service() method (which has to block waiting
for the non-blocking operation to complete) to the async API.
Essentially, if you leave it in the service() method you have one thread
allocated to each non-blocking operation.
If the Servlet async API is used, the non-blocking operation is started
and the container thread continues to complete the service method. The
container thread is now free to do other useful work and the
non-blocking operation isn't using any thread at all - and won't until
the operation completes at which point it will require a thread to
perform the dispatch back to the container and then to process that
dispatch.
In this case a container thread is only required up to the point where
there non-blocking operation starts and form the point where it
completes. While the non-blocking operation is in progress, the
container thread is free to do other useful work.
Mark
> so I do
> not agree that "because those threads can do useful work" then "does
> increase scalability". I think Servlet 3's async API here may increase
> scalability if and only if the released thread also releases some
> resources which other threads may are blocked on them. and if and only
> if the new thread does not lock more resources than the original one.
> **Actually as I understand, using Servlet 3's async API compared with
> tomcat's nio with greater max threads, does not have any gain except
> what I wrote above and also preventing deadlocks. wdyt?**
>
> On 9/5/2017 11:57 AM, Mark Thomas wrote:
>> On 03/09/17 09:01, Yasser Zamani wrote:
>>> Hi there,
>>>
>>> At [1] we read:
>>>
Web containers in application servers normally use a server thread
per client request. Under heavy load conditions, containers need a
large amount of threads to serve all the client requests.
Scalability limitations include running out of memory or
*exhausting the pool of container threads*. To create scalable web
applications, you must ensure that no threads associated with a
request are sitting idle, so *the container can use them to
process new requests*. Asynchronous processing refers to
*assigning these blocking operations to a new thread and returning
the thread associated with the request immediately to the container*.
>>> I could not achieve this scalability in tomcat via calling
>>> `javax.servlet.AsyncContext.start(Runnable)`! I investigated the cause
>>> and found it at [2]:
>>>
>>> public synchronized void asyncRun(Runnable runnable) {
>>> ...
>>> processor.execute(runnable);
>>>
>>> I mean `processor.execute(runnable)` uses same thread pool which it's
>>> also it's duty to process new requests! Such usage made things worse!
>>> i.e. not only does not make thread pool more free to process new
>>> requests, but also has an overhead via thread switching!
>>>
>>> I think Tomcat must use another thread pool for such blocking operations
>>> and keep current thread pool free for new requests; It's the philosophy
>>> of Servlet 3.0's asynchronous support according to Oracle's
>>> documentation. wdyt?
>>
>> I think this is a good question that highlights a lot of
>> misunderstanding in this area. The quote above is misleading at best.
>>
>> There is no way that moving a blocking operation from the container
>> thread pool to some other thread will increase scalability any more then
>> simply increasing the size of the container thread pool.
>>
>> Consider the following:
>>
>> - If the system is not at capacity then scalability can be increased by
>> increasing the size of the container thread pool
>>
>> - If the system as at capacity, the container thread pool will need to
>> be reduced to create capacity for these 'other' blocking threads.
>>
>> - If too many resources are allocated to these 'other' blocking threads
>> then
Re: Tomcat misuse of Servlet 3.0's asynchronous support
On 9/5/2017 11:26 PM, Yasser Zamani wrote:
> Thanks a lot Mark!
>
> Yes I knew these and before tested that a tomcat with 400 max threads
> "scalabilitaly is equal" to a tomcat with 200 max threads but with
> servlet 3's async API including application's thread pool with size 200.
>
> However so far I thought Oracle's docs are like standards and tomcat
> have to satisfy them :)
>
>> That does increase scalability
>> because rather than having a bunch of threads waiting for these
>> non-blocking operations to complete, those threads can do useful work.
>
> But tomcat blocks another thread from container's thread pool for
> waiting or locking on that non-blocking operation's response! so I do
> not agree that "because those threads can do useful work" then "does
> increase scalability". I think Servlet 3's async API here may increase
> scalability if and only if the released thread also releases some
> resources which other threads may are blocked on them. and if and only
> if the new thread does not lock more resources than the original one.
> **Actually as I understand, using Servlet 3's async API compared with
> tomcat's nio with greater max threads, does not have any gain except
> what I wrote above and also preventing deadlocks. wdyt?**
>
Have you seen this please? Until now, I concluded that with Tomcat's
configurable maxThreads,maxConnections and NIO, we don't need Servlet
3's async API anymore as we can instead simply increase them. right?
> On 9/5/2017 11:57 AM, Mark Thomas wrote:
>> On 03/09/17 09:01, Yasser Zamani wrote:
>>> Hi there,
>>>
>>> At [1] we read:
>>>
Web containers in application servers normally use a server thread
per client request. Under heavy load conditions, containers need a
large amount of threads to serve all the client requests.
Scalability limitations include running out of memory or
*exhausting the pool of container threads*. To create scalable web
applications, you must ensure that no threads associated with a
request are sitting idle, so *the container can use them to
process new requests*. Asynchronous processing refers to
*assigning these blocking operations to a new thread and returning
the thread associated with the request immediately to the
container*.
>>> I could not achieve this scalability in tomcat via calling
>>> `javax.servlet.AsyncContext.start(Runnable)`! I investigated the cause
>>> and found it at [2]:
>>>
>>> public synchronized void asyncRun(Runnable runnable) {
>>> ...
>>> processor.execute(runnable);
>>>
>>> I mean `processor.execute(runnable)` uses same thread pool which it's
>>> also it's duty to process new requests! Such usage made things worse!
>>> i.e. not only does not make thread pool more free to process new
>>> requests, but also has an overhead via thread switching!
>>>
>>> I think Tomcat must use another thread pool for such blocking operations
>>> and keep current thread pool free for new requests; It's the philosophy
>>> of Servlet 3.0's asynchronous support according to Oracle's
>>> documentation. wdyt?
>>
>> I think this is a good question that highlights a lot of
>> misunderstanding in this area. The quote above is misleading at best.
>>
>> There is no way that moving a blocking operation from the container
>> thread pool to some other thread will increase scalability any more then
>> simply increasing the size of the container thread pool.
>>
>> Consider the following:
>>
>> - If the system is not at capacity then scalability can be increased by
>> increasing the size of the container thread pool
>>
>> - If the system as at capacity, the container thread pool will need to
>> be reduced to create capacity for these 'other' blocking threads.
>>
>> - If too many resources are allocated to these 'other' blocking threads
>> then scalability will be reduced because there will be idle 'other'
>> blocking threads that could be doing useful work elsewhere such as
>> processing incoming requests.
>>
>> - If too few resources are allocated to these 'other' blocking threads
>> then scalability will be reduced because a bottleneck will have been
>> introduced.
>>
>> - The 'right' level of resources to allocate to these 'other' blocking
>> threads will vary over time.
>>
>> - Rather than try and solve the complex problem of balancing resources
>> across multiple thread pools, it is far simpler to use a single thread
>> pool, as Tomcat does.
>>
>>
>> Servlet 3 async can only increase scalability where the Servlet needs to
>> perform a genuinely non-blocking operation. Prior to the availability of
>> the async API, the Servlet thread would have to block until the
>> non-blocking operation completed. That is inefficient. That does limit
>> scalability. The async API allows this the thread to be released while
>> this non-blocking operation completes. That does increase scalab
Re: Need to upgrade Tomcat version from 4.1.3 to 7 version on OS400(AS400).
On 13.09.2017 17:44, Vinay A S wrote: Hello, We have installed Apache Tomcat version 4.1.30 on our iSeries server(AS400). As it very old version, we are thinking to upgrade it to version 7. Please share detailed steps to upgrade it. Have you not already posted the same request before, and have not already received an answer to that ? http://tomcat.apache.org/migration.html "Il n'y a pire sourd, que celui qui ne veut entendre". - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Need to upgrade Tomcat version from 4.1.3 to 7 version on OS400(AS400).
Hello, We have installed Apache Tomcat version 4.1.30 on our iSeries server(AS400). As it very old version, we are thinking to upgrade it to version 7. Please share detailed steps to upgrade it. Regards, Vinay A S
Re: Apache Tomcat 4.1.30 - not working with OS400 after upgrading the OS to V7R3 which uses Java 7/Java 8
Hello, When we run java -version in QSH, we got the below results. java -version java version "1.7.0" Java(TM) SE Runtime Environment (build pap6470sr10fp5-20170421_01(SR10 FP5)) IBM J9 VM (build 2.6, JRE 1.7.0 OS/400 ppc64-64 Compressed References jvmap6470sr10fp5-20170421_01_cr (JIT enabled, AOT enabled) J9VM - R26_Java726_SR10_20170407_0035_B343227 JIT - r11_20170407_343227 GC - R26_Java726_SR10_20170407_0035_B343227_CMPRSS J9CL - 20170407_343227) JCL - 20170420_01 based on Oracle jdk7u141-b11 $ And JAVA_HOME is pointing to '/QOpenSys/QIBM/ProdData/JavaVM/jdk70/64bit' I hope it is pointing to right data. On Fri, Sep 8, 2017 at 8:31 PM, Greg Huber wrote: > Do you know where the JAVA_HOME points to? Maybe it has switched to a > later java version in the upgrade. > > From memory (it's been a while) > > If you do wrkenvvar (F4) and select *SYS and scroll for the JAVA_HOME. > > > or STRQSH and run java -version will also display the version. > > > > > On 8 September 2017 at 14:25, Vinay A S wrote: > > > Hi, > > > > Below error messages are recorded in the log txt files. Please find the > > details. > > > > Aug 23, 2017 9:36:32 AM org.apache.coyote.http11.Http11Protocol > > init > > INFO: Initializing Coyote HTTP/1.1 on port > > 8180 > > Starting service > > Tomcat-Standalone > > > > Apache > > Tomcat/4.1.30 > > > > Aug 23, 2017 9:36:33 AM org.apache.commons.digester.Digester > > error > > SEVERE: Parse Error at line 21 column 19: Document root element > "web-app", > > must match DOCTYPE root "null". > > org.xml.sax.SAXParseException: Document root element "web-app", must > match > > DOCTYPE root "null". > > at > > org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException( > Unknown > > Source) > > at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown > > Source) > > at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown > > Source) > > at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown > > Source) > > at org.apache.xerces.impl.dtd.XMLDTDValidator. > > rootElementSpecified(Unknown > > Source) > > at org.apache.xerces.impl.dtd.XMLDTDValidator. > handleStartElement(Unknown > > Source) > > at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown > > Source) > > at > > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl > > .scanStartElement(Unknown > > Source) > > at > > org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher. > > scanRootElementHook(Unknown > > Source) > > at > > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl > > $FragmentContentDispatcher.dispatch(Unknown > > Source) > > at > > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl > .scanDocument(Unknown > > Source) > > at > > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl > .scanDocument(Unknown > > Source) > > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown > > Source) > > at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown > > Source) > > at org.apache.xerces.parsers.XMLParser.parse(Unknown > > Source) > > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown > > Source) > > at > > org.apache.commons.digester.Digester.parse(Digester.java:1548) > > > > at > > org.apache.catalina.startup.ContextConfig.applicationConfig( > > ContextConfig.java:282) > > > > at > > org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639) > > > > at > > org.apache.catalina.startup.ContextConfig.lifecycleEvent( > > ContextConfig.java:243) > > > > at > > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent( > > LifecycleSupport.java:166) > > > > Aug 23, 2017 9:36:33 AM org.apache.commons.digester.Digester > > error > > SEVERE: Parse Error at line 21 column 19: Document is invalid: no grammar > > found. > > org.xml.sax.SAXParseException: Document is invalid: no grammar > > found. > > > > Aug 23, 2017 9:36:41 AM org.apache.commons.digester.Digester > > error > > SEVERE: Parse Error at line 190 column 11: The content of element type > > "web-app" must match > > "(icon?,display-name?,description?,distributable?, > > context-param*,filter*,filter-mapping*,listener*,servlet*, > > servlet-mapping*,session-config?,mime-mapping*,welcome- > > file-list?,error-page*,taglib*,resource-env-ref*,resource- > > ref*,security-constraint*,login-config?,security-role*, > > env-entry*,ejb-ref*,ejb-local-ref*)". > > org.xml.sax.SAXParseException: The content of element type "web-app" must > > match > > "(icon?,display-name?,description?,distributable?, > > context-param*,filter*,filter-mapping*,listener*,servlet*, > > servlet-mapping*,session-config?,mime-mapping*,welcome- > > file-list?,error-pagge*,taglib*,resource-env-ref*, > resource-ref*,security- > > constraint*,login-config?,security-role*,env-entry*,ejb- > > ref*,ejb-local-ref*)". > > at > > org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException( > Unknown > > Source) > > at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown > > Source) > > at org.apache.xerc
