Re: Change of status code for ClientAbortExceptions - bug?

[Konstantin Kolinko]

2017-06-07 0:10 GMT+03:00 Mark Thomas :
> On 06/06/17 15:08, Thomas Eliassen wrote:
>>
>> Is there some way to avoid having it logged as a 500 in the access log then?
>
> At the moment, no. And my preference is to avoid creating new
> configuration options unless we have to.
>
>> ClientAbortExceptions are so frequent that it really pollutes the access 
>> logs, drowns out 500s actually caused by the server side application, and 
>> makes monitoring and debugging based on the access logging a lot harder.
>
> Fair point.
>
>> I'll also note that e.g. Jetty logs a 200 on ClientAbortExceptions.
>
> I've been looking at RFC 7231 in more detail.
>
> None of the status codes are ideal. Of course, they are intended for the
> client which in this case is never going to see the status code anyway
> but still...
>
> The general description of 2xx codes looks to be appropriate:
> "... the client's request was successfully received, understood, and
> accepted."
>
> 200 doesn't seem right since:
> "...  the request has succeeded."
>
> 202 could be better since:
> "... the request has been accepted for processing, but the processing
> has not been completed."
> but the intention behind 202 is very different so using it in this case
> seems wrong.
>
> None of the other 2xx codes seem to be a match at all.
>
> The 4xx codes are another possibility:
> "... 4xx (Client Error) class of status code indicates that the client
> seems to have erred."
>
> Of those only 400 is a possible match.
> "... the server cannot or will not process the request due to something
> that is perceived to be a client error."
>
> The 5xx codes are also possible:
> "... the server is aware that it has erred or is incapable of performing
> the requested method"
>
> With 500 being the best match in that case:
> "... the server encountered an unexpected condition that prevented it
> from fulfilling the request."
>
> You have already explained why using 500 is a problem. 400 suffers from
> a similar issue. Which brings us back to 200 which doesn't seem right
> either.
>
> I think we are going to have to choose a "least bad" option here. Given
> that Tomcat has used 200 in the past and that there is the option to add
> %{javax.servlet.error.exception}r to the access log I think reverting
> the change to the status code is the best (well, least bad) option here.
>
> I'll get that done shortly.

I think that it makes sense to log the status code that was actually
sent on the first line of the response.

If "200" was sent to browser, it is better to log "200", not "500".


As an idea:

In Apache HTTPD there is an option in their access log format to log
connection status: "%X"

http://httpd.apache.org/docs/2.4/mod/mod_log_config.html#formats

"%X":
Connection status when response is completed:
X = Connection aborted before the response completed.
+ = Connection may be kept alive after the response is sent.
- = Connection will be closed after the response is sent.


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5.x/Openssl with custom keystore

[Dave Neuman]

Actually, it looks like the error I pasted above was actually my embedded
tomcat not being able to find tc-native.
Sorry for the noise, I will respond if/when I run into a different/"real"
problem.
--Dave

On Tue, Jun 6, 2017 at 2:41 PM, Dave Neuman  wrote:

> Hey all,
> I was wondering if anyone has had any luck or could provide some guidance
> on using a custom keystore with tomcat 8.5.x and openssl?
>
> I am in the process of upgrading from tomcat 6.0.x using JSSE to tomcat
> 8.5.x using Openssl. As part of the upgrade process, I need to re-implement
> our custom keystore. The keystore was implemented in 6.0.x by extending
> JSSEImplementation and JSSESocketFactory which has since been removed from
> the code. I was able to work through that and I had my custom keystore
> working use JSSE, but when I attempt to switch to using OpenSSL and start
> my application, I get an error like:
>
> Exception in thread "Thread-3" java.lang.UnsatisfiedLinkError:
> org.apache.tomcat.jni.Pool.create(J)J at 
> org.apache.tomcat.jni.Pool.create(Native
> Method) at 
> org.apache.tomcat.util.net.openssl.OpenSSLEngine.(OpenSSLEngine.java:72)
> at com.comcast.cdn.traffic_control.traffic_router.protocol.RouterSslUtil.
> getImplementedProtocols(RouterSslUtil.java:65) at
> org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:53) at
> com.comcast.cdn.traffic_control.traffic_router.
> protocol.RouterSslUtil.(RouterSslUtil.java:54) at
> com.comcast.cdn.traffic_control.traffic_router.protocol.
> RouterSslImplementation.getSSLUtil(RouterSslImplementation.java:34) at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:102)
> at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:225) at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:970)
> at 
> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:244)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:613) at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(
> AbstractHttp11Protocol.java:66) at com.comcast.cdn.traffic_
> control.traffic_router.protocol.LanguidNioProtocol.
> init(LanguidNioProtocol.java:63) at com.comcast.cdn.traffic_
> control.traffic_router.protocol.LanguidPoller.run(LanguidPoller.java:58)
>
> It seems that this is because I don’t have a keystore configured in my
> server.xml, so tomcat tries to use the default ~/.keystore which causes
> issues at about the time it tries to get the IMPLEMENTED_PROTOCOLS_SET in
> OpenSSLUtil. Like I said earlier if I switch to JSSEUtil, things work as
> expected.
>
> Any thoughts?
>
> Thanks,
> Dave
> ​
>

Re: Change of status code for ClientAbortExceptions - bug?

[Mark Thomas]

On 06/06/17 15:08, Thomas Eliassen wrote:
> 
> Is there some way to avoid having it logged as a 500 in the access log then?

At the moment, no. And my preference is to avoid creating new
configuration options unless we have to.

> ClientAbortExceptions are so frequent that it really pollutes the access 
> logs, drowns out 500s actually caused by the server side application, and 
> makes monitoring and debugging based on the access logging a lot harder.

Fair point.

> I'll also note that e.g. Jetty logs a 200 on ClientAbortExceptions.

I've been looking at RFC 7231 in more detail.

None of the status codes are ideal. Of course, they are intended for the
client which in this case is never going to see the status code anyway
but still...

The general description of 2xx codes looks to be appropriate:
"... the client's request was successfully received, understood, and
accepted."

200 doesn't seem right since:
"...  the request has succeeded."

202 could be better since:
"... the request has been accepted for processing, but the processing
has not been completed."
but the intention behind 202 is very different so using it in this case
seems wrong.

None of the other 2xx codes seem to be a match at all.

The 4xx codes are another possibility:
"... 4xx (Client Error) class of status code indicates that the client
seems to have erred."

Of those only 400 is a possible match.
"... the server cannot or will not process the request due to something
that is perceived to be a client error."

The 5xx codes are also possible:
"... the server is aware that it has erred or is incapable of performing
the requested method"

With 500 being the best match in that case:
"... the server encountered an unexpected condition that prevented it
from fulfilling the request."

You have already explained why using 500 is a problem. 400 suffers from
a similar issue. Which brings us back to 200 which doesn't seem right
either.

I think we are going to have to choose a "least bad" option here. Given
that Tomcat has used 200 in the past and that there is the option to add
%{javax.servlet.error.exception}r to the access log I think reverting
the change to the status code is the best (well, least bad) option here.

I'll get that done shortly.

Mark


> 
> --
> 
> Another one I failed to send to the list first time around...
> 
> On 29/05/17 08:26, Thomas Eliassen wrote:
>> Hi,
>>
>> Since https://bz.apache.org/bugzilla/show_bug.cgi?id=60718 (r1783148 in 
>> tc8.5.x), ClientAbortExceptions are logged in the access log as status 500, 
>> changed from the previous status 200.
>>
>> Is this actually the desired behaviour? It doesn't seem appropriate to log a 
>> 500 as this isn't necessarily a server error.
> 
> The server has no way of knowing for sure whether the request processing
> completed cleanly and then failed when the completed response was being
> written or if the exception caused the processing to abort half-way through.
> 
> A 200 response certainly doesn't look to be correct.
> 
> None of the 4xx codes look to be appropriate.
> 
> That does, pretty much, leave the 500 code which does not seem an
> unreasonable option.
> 
>> Also, the error isn't being logged to catalina.log using the default 
>> logging.properties, which for a 500 error seems wrong.
> 
> I suspect if you enable debug logging you'll see it. It doesn't make
> sense to log user triggered exceptions by default.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 8.5.x/Openssl with custom keystore

[Dave Neuman]

Hey all,
I was wondering if anyone has had any luck or could provide some guidance
on using a custom keystore with tomcat 8.5.x and openssl?

I am in the process of upgrading from tomcat 6.0.x using JSSE to tomcat
8.5.x using Openssl. As part of the upgrade process, I need to re-implement
our custom keystore. The keystore was implemented in 6.0.x by extending
JSSEImplementation and JSSESocketFactory which has since been removed from
the code. I was able to work through that and I had my custom keystore
working use JSSE, but when I attempt to switch to using OpenSSL and start
my application, I get an error like:

Exception in thread "Thread-3" java.lang.UnsatisfiedLinkError:
org.apache.tomcat.jni.Pool.create(J)J at
org.apache.tomcat.jni.Pool.create(Native Method) at
org.apache.tomcat.util.net.openssl.OpenSSLEngine.(OpenSSLEngine.java:72)
at
com.comcast.cdn.traffic_control.traffic_router.protocol.RouterSslUtil.getImplementedProtocols(RouterSslUtil.java:65)
at org.apache.tomcat.util.net.SSLUtilBase.(SSLUtilBase.java:53) at
com.comcast.cdn.traffic_control.traffic_router.protocol.RouterSslUtil.(RouterSslUtil.java:54)
at
com.comcast.cdn.traffic_control.traffic_router.protocol.RouterSslImplementation.getSSLUtil(RouterSslImplementation.java:34)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:102)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:85)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:225) at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:970)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:244)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:613) at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:66)
at
com.comcast.cdn.traffic_control.traffic_router.protocol.LanguidNioProtocol.init(LanguidNioProtocol.java:63)
at
com.comcast.cdn.traffic_control.traffic_router.protocol.LanguidPoller.run(LanguidPoller.java:58)

It seems that this is because I don’t have a keystore configured in my
server.xml, so tomcat tries to use the default ~/.keystore which causes
issues at about the time it tries to get the IMPLEMENTED_PROTOCOLS_SET in
OpenSSLUtil. Like I said earlier if I switch to JSSEUtil, things work as
expected.

Any thoughts?

Thanks,
Dave
​

RE: Tomcat 8/NIO performance discrepancies

[Piyush Kumar Nayak]

Just realized that the comparison matrix formatting was lost earlier, so 
sharing it again.

-
helloWorld.JSP  BIO NIO BIO w/ Exec 
NIO w/ Exec 
Throughput ART  Throughput  ART Throughput ART  Throughput ART
-
   
Tomcat 7.07738600   2   42664   257104  
   143660   2
Tomcat 8.0.44   38585   2   44752   263000  
   144341   2
Tomcat 8.0.32-- 41211  ---  
Tomcat 8.5.14  N/A  456001.67N/A
46000   1.67
-
Throughput: requests per sec.
ART: msecs

Also, forgot to add earlier, the jMeter client has keep-alive header enabled, 
and the server is left to use the default keepalive values.


-Original Message-
From: Piyush Kumar Nayak [mailto:pna...@adobe.com.INVALID] 
Sent: Tuesday, June 06, 2017 7:59 PM
To: Tomcat Users List 
Subject: RE: Tomcat 8/NIO performance discrepancies

Violeta,

The data you see in an average of 3 samples of 180 second duration each.

Missed out on mentioning it before, but the thoughput is in no. of requests per 
second, and ART is in milliseconds.



Thanks

Piyush.



-Original Message-
From: Violeta Georgieva [mailto:violet...@apache.org]
Sent: Tuesday, June 06, 2017 7:09 PM
To: Tomcat Users List 
Subject: Re: Tomcat 8/NIO performance discrepancies



Hi,



2017-06-06 11:10 GMT+03:00 Piyush Kumar Nayak 
>:

>

> Thanks, Mark.

>

> Here are some additional details.

>

> I am using Apache JMeter to inject load. I am using a simple

> hello-world

JSP.

>

> The test JMX simulates 100 concurrent user threads with a ramp-up of 5

secs and uses an HTTP Cookie Manager, that reuses cookies for each user thread.



Do you specify "Loop Count" for the number of iterations or you specify time 
duration?



Thanks,

Violeta



>

> I have disabled access log in tomcat. All the other server.xml

> settings

are the default.

>

>

> The BIO with Executor configuration we are using is:

>  maxThreads="150" minSpareThreads="4"/>

>

> connectionTimeout="2"

>redirectPort="8443" />

>

>

>

> It's the same for NIO. Just the protocol changes.

>

>

>

> The client(jMeter) and server (Tomcat) are on 2 separate physical

machines with the same configuration:

>

> RHEL 7.1 x64

>

> 16 core CPU;

>

> 32 GB RAM;

>

> 1Gbps NIC

>

>

>

> - JSP test

page 

>

> <%@ page language="java" contentType="text/html; charset=ISO-8859-1"

>

> pageEncoding="ISO-8859-1"%>

>

> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml4%2Floose.dtd=02%7C01%7C%7Ce541b882239d42e880f508d4ace1739f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636323531683671518=AwpErTK9ClLCwDZ23QnOqj195rlITTyAeG4JX0BFv0o%3D=0;>

>

> 

>

> 

>

> 

>

> Hello World - JSP tomcat test

>

> 

>

> 

>

> <%= "Hello World! - JSP on Tomcat 8.15" %>

>

> 

>

> 

>

> -  JSP

> test

page -

>

>

>

> Test result:

> helloWorld.JSP

>

>

>

> BIO

>

> NIO

>

> BIO w/ Exec

>

> NIO w/ Exec

>

> Throughput

>

> ART

>

> Throughput

>

> ART

>

> Throughput

>

> ART

>

> Throughput

>

> ART

>

> Tomcat 7.077

>

> 38600

>

> 2

>

> 42664

>

> 2

>

> 57104

>

> 1

>

> 43660

>

> 2

>

> Tomcat 8.0.44

>

> 38585

>

> 2

>

> 44752

>

> 2

>

> 63000

>

> 1

>

> 44341

>

> 2

>

> Tomcat 8.0.32

>

>

>

>

>

>

>

>

>

> 41211

>

>

>

>

>

>

>

> Tomcat 8.5.14

>

> N/A

>

> 45600

>

> 1.67

>

> N/A

>

> 46000

>

> 1.67

>

>

>

>

>

>

> Regards,

>

> Piyush.

>

>

>

> -Original Message-

>

> From: Mark Thomas [mailto:ma...@apache.org]

>

> Sent: Tuesday, June 06, 2017 12:50 PM

>

> To: Tomcat Users List 
> >

>

> Subject: Re: Tomcat 8/NIO performance discrepancies

>

>

>

> On 06/06/17 07:30, Piyush Kumar Nayak wrote:

>

> > We have been testing different connectors of tomcat for performance.

>

> > We have tested the 

Re: tomcat 7, null tag attributes

[Mark Thomas]

On 31/05/17 23:31, Chris Cheshire wrote:
> I am using tomcat 7 on CentOS 7 and I need to pass a null value to tag
> attributes of type Long/Integer/Float, however it is *always* coerced to
> zero.
> 
> <%@attribute name="parentId" required="true" rtexprvalue="true"
> type="java.lang.Long" %>
> 
> Changing required to false does nothing. I tried setting the system
> property org.apache.el.parser.COERCE_TO_ZERO to false in tomcat.conf
> (-Dorg.apache.el.parser.COERCE_TO_ZERO=false with my other JAVA_OPTS) but
> this does nothing.

As expected. That system property only affects evaluation of EL expressions.

> The value before it hits the tag is null and inside the
> tag is 0. If I query the System properties it shows it as set to false, but
> Tomcat is not honoring it and is still coercing nulls to zero. I understand
> the spec says to do this etc but that defeats the purpose of using an
> object vs atomic type in the first place and is horribly shortsighted>
> Upgrading to Tomcat 8 is not a solution unfortunately as there is no RPM
> for it.

I don't believe an upgrade would change the behaviour.

> How do I pass a null Long/Float/Integer as a tag attribute and have it kept
> as null and not turned into an incorrect value?

Use parentId="<%=null%>" rather than parentId=""

Ugly, but it does the job. Scriplets aren't coerced.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: TLS handshake performance

[Jeff Elsloo]

Hi Mark,

Apologies for the late reply on this, but I was the person that asked
you this performance question at ApacheCon. We reviewed this thread
and appreciate the analysis and discussion. The description below is
accurate; we have short lived non-keep-alived clients, so we're keenly
interested in the performance of the asymmetric/handshake piece of
TLS.

Obviously we could use some different architectural strategies to help
improve performance, but we appreciate the raw numbers because they
help with our design work. Of particular interest were the "better"
numbers (1,900 TPS) provided by Rémy, as that number is certainly
better than the initial example of 23 TPS. I understand that was a
quick test on Mark's laptop; relative performance is what was
interesting. Our own benchmarking lies somewhere between the two
numbers, closer to 1,000 TPS on Tomcat 6.x (yes, I know) on one of our
test servers. As noted by those here, keep-alives significantly
improve performance.

We're currently working through the process of moving to 8.5 with
OpenSSL, so hopefully we'll be able to post back with some results in
the near future.
--
Thanks,
Jeff

On 2017-05-18 07:47 (-0600), Mark Thomas  wrote:
> This time to the right list...>
>
> On 18/05/2017 06:04, Christopher Schultz wrote:>
> > -BEGIN PGP SIGNED MESSAGE->
> > Hash: SHA256>
> > >
> > Mark,>
> > >
> > On 5/17/17 5:31 PM, Mark Thomas wrote:>
> >> I got asked in the corridor at TomcatCon earlier today what the>
> >> relative performance of the TLS handshake was with 8.5.x, the NIO>
> >> connector and JSSE vs OpenSSL TLS implementation.>
> > I'm curious about what exactly "TLS handshake" was intended to mean>
> > (by the person who asked the question) in this context.>
>
> They are using Tomcat in a scenario where clients are making single >
> requests (so keep alve doesn't help). Given that the handshake uses >
> asymmetric encryption which is more expensive that symmetric encryption >
> (which is why the handshake is used to establish a shared secret so >
> symmetric encryption can used for the actual data) they wanted a sense >
> of the performance benefit - if any - of NIO and 8.5.x with OpenSSL vs >
> NIO and 8.5.x with JSSE.>
>
> > The handshake itself does not perform any bulk transfer of encrypted>
> > data, so the negotiated cipher suite does not matter. However...>
> > >
> >> Tested with: ab -n 1000 -c 2 -f TLS1.2 -Z>
> >> ECDHE-RSA-AES128-GCM-SHA256 https://localhost:8443/test.txt>
> > >
> > Here the cipher suite matters very much, since the client is not only>
> > performing the TLS handshake but also transferring the client's>
> > request to the server and the server's response back to the client. >>
> > Support for a particular algorithm may dominate the benchmark, here.>
>
> Agreed. But it is the handshake that dominates the timings (if you add >
> -k to use keep-alive the req/sec are an order of magnitude higher).>
>
> The cipher suite was the default one chosen by by one of the configs (I >
> forget which).>
>
> The cipher suite will affect the results since it also impacts the >
> enctrpyion used during the handshake but for any 'reaosnably' secure >
> cipher suite, I'd expect similar results in terms of the relative >
> performance.>
>
> > What happens if you negotiate a NULL cipher for instance? Or, perform>
> > the TLS handshake but never make an HTTP request after connecting? I>
> > don't know of a tool that can do that out of the box (e.g. ab makes>
> > HTTP requests, not just TLS connections) but one could be written in>
> > Java fairly easily.>
> > >
> >> test.txt is a 3 byte text file.>
> >>>
> >> The results were: JSSE:17 reqs/sec OpenSSL: 23 reqs/sec>
> >>>
> >> So around a 35% increase.>
> > >
> > I'd like to see a NULL or very low-overhead cipher under the same>
> > circumstances.>
>
> The test was with Tomcat trunk and the test keystore from the Tomcat PMC >
> private repo so you should be able to set up those tests pretty quickly. >
> (I did it in around 30 mins which incuded building tc-native).>
>
> Mark>
>
> > >
> >> YMMV with different versions of TLS and associated ciphers, JREs,>
> >> OpenSSl versions etc. >>
> > Noted. ;)>
> > >
> > - -chris>
> > -BEGIN PGP SIGNATURE->
> > Comment: GPGTools - http://gpgtools.org>
> > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/>
> > >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkdK1IACgkQHPApP6U8>
> > pFhfQw/+NGm1CNQcFZ2qVzlCZ36W+TXhaKaBcWeiSCKw60jf/utEFycONRldm5Q3>
> > cRM7Nbrfx1GcPwAs8ufedOtHgsAfzp6JkpzqwVFqZjUX1GODbJhz1vaNgQgB3mL8>
> > YlGBoLqQIRKvQNOcTYJx5bP+tbnqARu96uINH16rMT+GQUF9nIzk+ua7ec0Goe+e>
> > 6yO6euDrkV75uOMPArBWDDToSrQVZ9QKiliqlcYpnG2IPDMu1CGWDHZtwO1pxaLG>
> > aMbtqea9gAj42rw3NpFjUNxqYdN4EJHhCFjIIdVCAbiqs5BZQQAjcWjaRPniq45M>
> > ySsuBLNFqPj2sltlhZrdg7CEklvDbVvVgVIWZA21pw0wyfIofZnsiy+KsLo8q/wD>
> > gHcOF/TkQ4pAYGVoP+wh5AnQHwze2SFTJq0RE7kE0s6cohtfXeNSH/Ga6lzbJW5d>
> > 

RE: Tomcat 8/NIO performance discrepancies

[Piyush Kumar Nayak]

Violeta,

The data you see in an average of 3 samples of 180 second duration each.

Missed out on mentioning it before, but the thoughput is in no. of requests per 
second, and ART is in milliseconds.



Thanks

Piyush.



-Original Message-
From: Violeta Georgieva [mailto:violet...@apache.org]
Sent: Tuesday, June 06, 2017 7:09 PM
To: Tomcat Users List 
Subject: Re: Tomcat 8/NIO performance discrepancies



Hi,



2017-06-06 11:10 GMT+03:00 Piyush Kumar Nayak 
>:

>

> Thanks, Mark.

>

> Here are some additional details.

>

> I am using Apache JMeter to inject load. I am using a simple

> hello-world

JSP.

>

> The test JMX simulates 100 concurrent user threads with a ramp-up of 5

secs and uses an HTTP Cookie Manager, that reuses cookies for each user thread.



Do you specify "Loop Count" for the number of iterations or you specify time 
duration?



Thanks,

Violeta



>

> I have disabled access log in tomcat. All the other server.xml

> settings

are the default.

>

>

> The BIO with Executor configuration we are using is:

>  maxThreads="150" minSpareThreads="4"/>

>

> connectionTimeout="2"

>redirectPort="8443" />

>

>

>

> It's the same for NIO. Just the protocol changes.

>

>

>

> The client(jMeter) and server (Tomcat) are on 2 separate physical

machines with the same configuration:

>

> RHEL 7.1 x64

>

> 16 core CPU;

>

> 32 GB RAM;

>

> 1Gbps NIC

>

>

>

> - JSP test

page 

>

> <%@ page language="java" contentType="text/html; charset=ISO-8859-1"

>

> pageEncoding="ISO-8859-1"%>

>

> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml4%2Floose.dtd=02%7C01%7C%7Ce541b882239d42e880f508d4ace1739f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636323531683671518=AwpErTK9ClLCwDZ23QnOqj195rlITTyAeG4JX0BFv0o%3D=0;>

>

> 

>

> 

>

> 

>

> Hello World - JSP tomcat test

>

> 

>

> 

>

> <%= "Hello World! - JSP on Tomcat 8.15" %>

>

> 

>

> 

>

> -  JSP

> test

page -

>

>

>

> Test result:

> helloWorld.JSP

>

>

>

> BIO

>

> NIO

>

> BIO w/ Exec

>

> NIO w/ Exec

>

> Throughput

>

> ART

>

> Throughput

>

> ART

>

> Throughput

>

> ART

>

> Throughput

>

> ART

>

> Tomcat 7.077

>

> 38600

>

> 2

>

> 42664

>

> 2

>

> 57104

>

> 1

>

> 43660

>

> 2

>

> Tomcat 8.0.44

>

> 38585

>

> 2

>

> 44752

>

> 2

>

> 63000

>

> 1

>

> 44341

>

> 2

>

> Tomcat 8.0.32

>

>

>

>

>

>

>

>

>

> 41211

>

>

>

>

>

>

>

> Tomcat 8.5.14

>

> N/A

>

> 45600

>

> 1.67

>

> N/A

>

> 46000

>

> 1.67

>

>

>

>

>

>

> Regards,

>

> Piyush.

>

>

>

> -Original Message-

>

> From: Mark Thomas [mailto:ma...@apache.org]

>

> Sent: Tuesday, June 06, 2017 12:50 PM

>

> To: Tomcat Users List 
> >

>

> Subject: Re: Tomcat 8/NIO performance discrepancies

>

>

>

> On 06/06/17 07:30, Piyush Kumar Nayak wrote:

>

> > We have been testing different connectors of tomcat for performance.

>

> > We have tested the following server versions:

>

> >

>

> > -  Tomcat 7.077

>

> >

>

> > -  Tomcat 8.0.44

>

> >

>

> > -  Tomcat 8.0.32

>

> >

>

> > -  Tomcat 8.5.14

>

> >

>

> > with the following HTTP connectors:

>

> >

>

> > -  BIO

>

> >

>

> > -  BIO with Executor

>

> >

>

> > -  NIO

>

> >

>

> > -  NIO with Executor

>

> >

>

> > Our observation is that NIO is up to 15% faster than BIO. But BIO

> > with

Executor is up to 65% faster than BIO. Using a shared executor thread pool with 
NIO does not improve the performance. We have tried some variations of 
connector attribute with Tomcat 8 (maxThreads, acceptorThreadCount), but 
nothing brings us close to the performance that we can get with BIO with 
Executor.

>

> >

>

> > We have upgraded to Tomcat 8.5, and can't seem to get it to perform

> > as

well as Tomcat 7 using BIO with Executor, which is what we were using earlier.

>

> >

>

> > I would appreciate any help with the following:

>

> >

>

> > -  Why is the executor not boosting the performance for NIO, as

it is for BIO?

>

>

>

> Without knowing the details of your tests - no idea. The numbers are a

long way from what I'd expect.

>

>

>

> >

>

> > -  BIO is not available as an option with Tomcat 8.5. Why has

it been removed? Is there any way to get it back ?

>

>

>

> Because it can't support the non-blocking requirements of the

> WebSocket

API or the Servlet API and while you can fake non-blocking support, the result 
is liable to enter a deadlock.

>

>

>

> > 

Re: Change of status code for ClientAbortExceptions - bug?

[Thomas Eliassen]

Is there some way to avoid having it logged as a 500 in the access log then?

ClientAbortExceptions are so frequent that it really pollutes the access logs, 
drowns out 500s actually caused by the server side application, and makes 
monitoring and debugging based on the access logging a lot harder.

I'll also note that e.g. Jetty logs a 200 on ClientAbortExceptions.

--

Another one I failed to send to the list first time around...

On 29/05/17 08:26, Thomas Eliassen wrote:
> Hi,
>
> Since https://bz.apache.org/bugzilla/show_bug.cgi?id=60718 (r1783148 in 
> tc8.5.x), ClientAbortExceptions are logged in the access log as status 500, 
> changed from the previous status 200.
>
> Is this actually the desired behaviour? It doesn't seem appropriate to log a 
> 500 as this isn't necessarily a server error.

The server has no way of knowing for sure whether the request processing
completed cleanly and then failed when the completed response was being
written or if the exception caused the processing to abort half-way through.

A 200 response certainly doesn't look to be correct.

None of the 4xx codes look to be appropriate.

That does, pretty much, leave the 500 code which does not seem an
unreasonable option.

> Also, the error isn't being logged to catalina.log using the default 
> logging.properties, which for a 500 error seems wrong.

I suspect if you enable debug logging you'll see it. It doesn't make
sense to log user triggered exceptions by default.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Error while starting Tomcat 8.5.14

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Neha,

On 6/5/17 6:14 PM, Neha Munjal wrote:
> We could finally mange through this. Somehow, the SSLEngine
> attribute was set as "off" in the AprLifecycleListener which did
> not allow OpenSSL implementation to work.
> 
> This is resolved now.

Would you please log this as a bug in BZ?
https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%209

If the SSL engine is off, it shouldn't crash the JVM. :)

- -chris

> On Mon, Jun 5, 2017 at 1:27 PM, Neha Munjal
>  wrote:
> 
>> Hi,
>> 
>> We tried the following configuration, but it still fails with the
>> same error:
>> 
>> > protocol="org.apache.coyote.http11.Http11NioProtocol" 
>> SSLEnabled="true" maxThreads="150" keyAlias="interact7-priv" 
>> scheme="https" secure="true" clientAuth="false" 
>> sslProtocol="TLS">  > certificateKeyAlias=xxx certificateKeystoreFile= 
>> certificateKeystorePassword=x />  
>> 
>> 
>> Thanks Neha
>> 
>> On Mon, Jun 5, 2017 at 11:53 AM, Hassan Khan
>>  wrote:
>> 
>>> Hi,
>>> 
>>> we had a different problem with Nio : >> protocol="org.apache.coyote.ht tp11.Http11NioProtocol" >
>>> Non-blocking connector maxThreads="200" SSLEnabled="true"
>>> compression="on" minSpareThreads="25" maxSpareThreads="75" 
>>> enableLookups="false"connectionTimeout="-1" scheme="https"
>>> secure="true">
>>> 
>>>  >> certificateKeystoreFile="XXX" 
>>> certificateKeystorePassword="XXX" 
>>> certificateKeyAlias="localhost" type="RSA" />  
>>> 
>>> 
>>> so we changed to APR as below and everything worked great : 
>>> >> protocol="org.apache.coyote.http11.Http11AprProtocol" 
>>> port="443" clientAuth="false" sslProtocol="TLS" 
>>> SSLEnabled="true" maxThreads="150" scheme="https"
>>> secure="true" SSLCertificateFile="ABC.crt" 
>>> SSLCertificateKeyFile="TRE.key" SSLEngine="on"
>>> SSLVerifyDepth="2" />
>>> 
>>> But your may be different issue...
>>> 
>>> Thanks Hassan
>>> 
>>> On Mon, Jun 5, 2017 at 1:30 PM, Neha Munjal
>>>  wrote:
>>> 
 Hi Chris,
 
 Please find below our Connector information:
 
 >>> 
 address=xx
 
 protocol="org.apache.coyote.http11.Http11NioProtocol"
 
 SSLEnabled="true"
 
 maxThreads="150"
 
 keyAlias=x
 
 keystoreFile=xx keystorePass=x
 
 scheme="https"
 
 secure="true"
 
 clientAuth="false"
 
 sslProtocol="TLS" />
 
 
 Also found this link that talks about different SSL
 implementations
>>> that we
 can configure:
 
 
 https://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html
 
 
 Our installation uses APR and we have openssl102 installed. I
 think the connector configuration requires changes.
 
 
 Thanks
 
 Neha
 
 
 
 On Mon, Jun 5, 2017 at 7:58 AM, Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
> 
> 
> Neha,
> 
> On 6/2/17 5:36 PM, Neha Munjal wrote:
>>> We have been trying to start Apache Tomcat 8.5.14 (JDK
>>> version
> 8.0_121-b13)
>>> and land into the following error:
>>> 
>>> #
>>> 
>>> # A fatal error has been detected by the Java Runtime
>>> Environment: # #  SIGSEGV (0xb) at
>>> pc=0x7fafaa9ad123, pid=590,
> tid=0x7fb095cdc700
>>> # # JRE version: Java(TM) SE Runtime Environment
>>> (8.0_121-b13) (build 1.8.0_121-b13)
>>> 
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM
>>> (25.121-b13 mixed mode linux-amd64 compressed oops)
>>> 
>>> # Problematic frame:
>>> 
>>> # C  [libapr-1.so.0+0x25123]
>>> apr_threadkey_private_set+0x3
> 
> 
> Hmm... I've not seen this one before.
> 
> Can you please post your  configuration (with any
> secrets removed)?
> 
> -chris
> 
> 
> --
- ---
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
> 
> 
 
>>> 
>>> 
>>> 
>>> -- Hassan Khan
>>> 
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZNrXJAAoJEBzwKT+lPKRYIlsQALFAQbZ90SSMKnPAzQPlZTnF
oS+c6FNWEn66+QZ015+r58UI7ouEVkihtHP1DuoV+jvifRO2bmdTRC3rsaumYej+
yDwRZB/2bGpP1HdJKbV2P1RMuz56r0HP2X+Myct1mElTVDO68A9ryU8lASXLv15q
prhx7ESCjJ7d5ycpQhgPg7gdxGt+4cvMYJUYnh3G6Sx02Hj63IYXmjhwC5RwLoj8
2dJCVPxlKt5tfdjbtI+8Fwrb27cg5c+OmOkg1j1siRZB+kNAiXSWKipeK+UcTR6z
wG6y/vdcMcW0ZYHxhE7AiAGYuBfwl9GNrI6aB31DKHsQAeSgokpLPmxmznVRfnas
783QSSZPQDbWI/Rr5bFuhVCawZtG6QHa56VfLpuR4CI5dIXi4cuq1e5r5/VfBIgd
Ju0s1IKnR5wqhFdGn9QsGRcz7Qa42ZzHgRynmII38kPuG+l2L16GhC4KISVmiOes
yT/W1NFvZKG1qZDzGXu1So2zJlYF+TFCzpqpuPbKezXY8DanbwXDDc3uJHZpTWGx
IhjH/BPF2uvmAAhhnk4JtqR8PMQ4NG4uZzqIa1+7aAGZXMj5gXv+eEvjBV5MSuK7

Re: Tomcat 8/NIO performance discrepancies

[Violeta Georgieva]

Hi,

2017-06-06 11:10 GMT+03:00 Piyush Kumar Nayak :
>
> Thanks, Mark.
>
> Here are some additional details.
>
> I am using Apache JMeter to inject load. I am using a simple hello-world
JSP.
>
> The test JMX simulates 100 concurrent user threads with a ramp-up of 5
secs and uses an HTTP Cookie Manager, that reuses cookies for each user
thread.

Do you specify "Loop Count" for the number of iterations or you specify
time duration?

Thanks,
Violeta

>
> I have disabled access log in tomcat. All the other server.xml settings
are the default.
>
>
> The BIO with Executor configuration we are using is:
>  maxThreads="150" minSpareThreads="4"/>
>
> connectionTimeout="2"
>redirectPort="8443" />
>
>
>
> It's the same for NIO. Just the protocol changes.
>
>
>
> The client(jMeter) and server (Tomcat) are on 2 separate physical
machines with the same configuration:
>
> RHEL 7.1 x64
>
> 16 core CPU;
>
> 32 GB RAM;
>
> 1Gbps NIC
>
>
>
> - JSP test
page 
>
> <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
>
> pageEncoding="ISO-8859-1"%>
>
> http://www.w3.org/TR/html4/loose.dtd;>
>
> 
>
> 
>
> 
>
> Hello World - JSP tomcat test
>
> 
>
> 
>
> <%= "Hello World! - JSP on Tomcat 8.15" %>
>
> 
>
> 
>
> -  JSP test
page -
>
>
>
> Test result:
> helloWorld.JSP
>
>
>
> BIO
>
> NIO
>
> BIO w/ Exec
>
> NIO w/ Exec
>
> Throughput
>
> ART
>
> Throughput
>
> ART
>
> Throughput
>
> ART
>
> Throughput
>
> ART
>
> Tomcat 7.077
>
> 38600
>
> 2
>
> 42664
>
> 2
>
> 57104
>
> 1
>
> 43660
>
> 2
>
> Tomcat 8.0.44
>
> 38585
>
> 2
>
> 44752
>
> 2
>
> 63000
>
> 1
>
> 44341
>
> 2
>
> Tomcat 8.0.32
>
>
>
>
>
>
>
>
>
> 41211
>
>
>
>
>
>
>
> Tomcat 8.5.14
>
> N/A
>
> 45600
>
> 1.67
>
> N/A
>
> 46000
>
> 1.67
>
>
>
>
>
>
> Regards,
>
> Piyush.
>
>
>
> -Original Message-
>
> From: Mark Thomas [mailto:ma...@apache.org]
>
> Sent: Tuesday, June 06, 2017 12:50 PM
>
> To: Tomcat Users List 
>
> Subject: Re: Tomcat 8/NIO performance discrepancies
>
>
>
> On 06/06/17 07:30, Piyush Kumar Nayak wrote:
>
> > We have been testing different connectors of tomcat for performance.
>
> > We have tested the following server versions:
>
> >
>
> > -  Tomcat 7.077
>
> >
>
> > -  Tomcat 8.0.44
>
> >
>
> > -  Tomcat 8.0.32
>
> >
>
> > -  Tomcat 8.5.14
>
> >
>
> > with the following HTTP connectors:
>
> >
>
> > -  BIO
>
> >
>
> > -  BIO with Executor
>
> >
>
> > -  NIO
>
> >
>
> > -  NIO with Executor
>
> >
>
> > Our observation is that NIO is up to 15% faster than BIO. But BIO with
Executor is up to 65% faster than BIO. Using a shared executor thread pool
with NIO does not improve the performance. We have tried some variations of
connector attribute with Tomcat 8 (maxThreads, acceptorThreadCount), but
nothing brings us close to the performance that we can get with BIO with
Executor.
>
> >
>
> > We have upgraded to Tomcat 8.5, and can't seem to get it to perform as
well as Tomcat 7 using BIO with Executor, which is what we were using
earlier.
>
> >
>
> > I would appreciate any help with the following:
>
> >
>
> > -  Why is the executor not boosting the performance for NIO, as
it is for BIO?
>
>
>
> Without knowing the details of your tests - no idea. The numbers are a
long way from what I'd expect.
>
>
>
> >
>
> > -  BIO is not available as an option with Tomcat 8.5. Why has
it been removed? Is there any way to get it back ?
>
>
>
> Because it can't support the non-blocking requirements of the WebSocket
API or the Servlet API and while you can fake non-blocking support, the
result is liable to enter a deadlock.
>
>
>
> > I'd be happy to share any other details from my testing for any
clarification.
>
>
>
> You'll need to explain your testing methodology - in detail - before
anyone can provide any useful input.
>
>
>
> Mark
>
>
>
> -
>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: trimSpaces removing whitespace from html

[Mark Thomas]

On 29/05/17 09:43, Mark Thomas wrote:
> On 29/05/17 09:09, David Kavanagh wrote:
>> On 26 May 2017 at 22:33, Christopher Schultz 
>> wrote:
>>
>> Mark,
>>
>> On 5/26/17 6:59 AM, Mark Thomas wrote:
> 
> 
> 
> This is a potential use case for a recently closed (as WONTFIX)
> enhancement request:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=45931
>
> Whether this use case is sufficient to justify re-opening that
> enhancement request, reviewing the patch and updating it for 9.0.x
> is TBD. How realistic is it for you to apply the fix (using ${'
> '}) described above?
>>
>> Would it be reasonable to change trimSpaces so that spaces within
>> element attributes would be normalized to a single space, and others
>> would be removed? I'm not sure how aware the parser is of the
>> surrounding document structure.
>>
>> -chris
> 
> 
> 
>> Hey guys,
>>
>> Thanks again for the help. For the Tomcat setup we currently have, the
>> first link sent my Mark is a good fix for us.
>> The other option Mark posted that would require modifying the .jsp files is
>> unfortunately not realistic because we currently use thousands of .jsps.
>> The possible fix that Christopher suggested in the last message would be
>> the perfect solution.
> 
> BZ 45931 it is then. Please re-open that enhancement request and link to
> this thread as the use case that justifies it. If you wanted to take a
> look at porting the patch as well, that would be great.

This has now been fixed for 9.0.x and will be included in 9.0.0.M22 onwards.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2017-5664 Apache Tomcat Security Constraint Bypass

[Mark Thomas]

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M1 to 9.0.0.M20
Apache Tomcat 8.5.0 to 8.5.14
Apache Tomcat 8.0.0.RC1 to 8.0.43
Apache Tomcat 7.0.0 to 7.0.77
Earlier, unsupported versions have not been analysed but are likely to
be affected

Description:
The error page mechanism of the Java Servlet Specification requires
that, when an error occurs and an error page is configured for the error
that occurred, the original request and response are forwarded to the
error page. This means that the request is presented to the error page
with the original HTTP method.

If the error page is a static file, expected behaviour is to serve
content of the file as if processing a GET request, regardless of the
actual HTTP method. Tomcat's Default Servlet did not do this. Depending
on the original request this could lead to unexpected and undesirable
results for static error pages including, if the DefaultServlet is
configured to permit writes, the replacement or removal of the custom
error page.

Notes for other user provided error pages:
 - Unless explicitly coded otherwise, JSPs ignore the the HTTP method.
   JSPs used as error pages must must ensure that they handle any error
   dispatch as a GET request, regardless of the actual method.
 - By default, the response generated by a Servlet does depend on the
   HTTP method. Custom Servlets used as error pages must ensure that
   they handle any error dispatch as a GET request, regardless of the
   actual method.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.0.M21 or later
- Upgrade to Apache Tomcat 8.5.15 or later
- Upgrade to Apache Tomcat 8.0.44 or later
- Upgrade to Apache Tomcat 7.0.78 or later

Credit:
This issue was reported responsibly to the Apache Tomcat Security Team
by Aniket Nandkishor Kulkarni from Tata Consultancy Services Ltd,
Mumbai, India as a vulnerability that allowed the restrictions on
OPTIONS and TRACE requests to be bypassed. The full implications of this
issue were then identified by the Tomcat Security Team.

History:
2017-06-06 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html
[3] http://tomcat.apache.org/security-7.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat 8/NIO performance discrepancies

[Piyush Kumar Nayak]

Thanks, Mark.

Here are some additional details.

I am using Apache JMeter to inject load. I am using a simple hello-world JSP.

The test JMX simulates 100 concurrent user threads with a ramp-up of 5 secs and 
uses an HTTP Cookie Manager, that reuses cookies for each user thread.

I have disabled access log in tomcat. All the other server.xml settings are the 
default.


The BIO with Executor configuration we are using is:






It's the same for NIO. Just the protocol changes.



The client(jMeter) and server (Tomcat) are on 2 separate physical machines with 
the same configuration:

RHEL 7.1 x64

16 core CPU;

32 GB RAM;

1Gbps NIC



- JSP test page 


<%@ page language="java" contentType="text/html; charset=ISO-8859-1"

pageEncoding="ISO-8859-1"%>

http://www.w3.org/TR/html4/loose.dtd;>







Hello World - JSP tomcat test





<%= "Hello World! - JSP on Tomcat 8.15" %>





-  JSP test page 
-



Test result:
helloWorld.JSP



BIO

NIO

BIO w/ Exec

NIO w/ Exec

Throughput

ART

Throughput

ART

Throughput

ART

Throughput

ART

Tomcat 7.077

38600

2

42664

2

57104

1

43660

2

Tomcat 8.0.44

38585

2

44752

2

63000

1

44341

2

Tomcat 8.0.32









41211







Tomcat 8.5.14

N/A

45600

1.67

N/A

46000

1.67






Regards,

Piyush.



-Original Message-

From: Mark Thomas [mailto:ma...@apache.org]

Sent: Tuesday, June 06, 2017 12:50 PM

To: Tomcat Users List 

Subject: Re: Tomcat 8/NIO performance discrepancies



On 06/06/17 07:30, Piyush Kumar Nayak wrote:

> We have been testing different connectors of tomcat for performance.

> We have tested the following server versions:

>

> -  Tomcat 7.077

>

> -  Tomcat 8.0.44

>

> -  Tomcat 8.0.32

>

> -  Tomcat 8.5.14

>

> with the following HTTP connectors:

>

> -  BIO

>

> -  BIO with Executor

>

> -  NIO

>

> -  NIO with Executor

>

> Our observation is that NIO is up to 15% faster than BIO. But BIO with 
> Executor is up to 65% faster than BIO. Using a shared executor thread pool 
> with NIO does not improve the performance. We have tried some variations of 
> connector attribute with Tomcat 8 (maxThreads, acceptorThreadCount), but 
> nothing brings us close to the performance that we can get with BIO with 
> Executor.

>

> We have upgraded to Tomcat 8.5, and can't seem to get it to perform as well 
> as Tomcat 7 using BIO with Executor, which is what we were using earlier.

>

> I would appreciate any help with the following:

>

> -  Why is the executor not boosting the performance for NIO, as it is 
> for BIO?



Without knowing the details of your tests - no idea. The numbers are a long way 
from what I'd expect.



>

> -  BIO is not available as an option with Tomcat 8.5. Why has it been 
> removed? Is there any way to get it back ?



Because it can't support the non-blocking requirements of the WebSocket API or 
the Servlet API and while you can fake non-blocking support, the result is 
liable to enter a deadlock.



> I'd be happy to share any other details from my testing for any clarification.



You'll need to explain your testing methodology - in detail - before anyone can 
provide any useful input.



Mark



-

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8/NIO performance discrepancies

[Mark Thomas]

On 06/06/17 07:30, Piyush Kumar Nayak wrote:
> We have been testing different connectors of tomcat for performance.
> We have tested the following server versions:
> 
> -  Tomcat 7.077
> 
> -  Tomcat 8.0.44
> 
> -  Tomcat 8.0.32
> 
> -  Tomcat 8.5.14
> 
> with the following HTTP connectors:
> 
> -  BIO
> 
> -  BIO with Executor
> 
> -  NIO
> 
> -  NIO with Executor
> 
> Our observation is that NIO is up to 15% faster than BIO. But BIO with 
> Executor is up to 65% faster than BIO. Using a shared executor thread pool 
> with NIO does not improve the performance. We have tried some variations of 
> connector attribute with Tomcat 8 (maxThreads, acceptorThreadCount), but 
> nothing brings us close to the performance that we can get with BIO with 
> Executor.
> 
> We have upgraded to Tomcat 8.5, and can't seem to get it to perform as well 
> as Tomcat 7 using BIO with Executor, which is what we were using earlier.
> 
> I would appreciate any help with the following:
> 
> -  Why is the executor not boosting the performance for NIO, as it is 
> for BIO?

Without knowing the details of your tests - no idea. The numbers are a
long way from what I'd expect.

> 
> -  BIO is not available as an option with Tomcat 8.5. Why has it been 
> removed? Is there any way to get it back ?

Because it can't support the non-blocking requirements of the WebSocket
API or the Servlet API and while you can fake non-blocking support, the
result is liable to enter a deadlock.

> I'd be happy to share any other details from my testing for any clarification.

You'll need to explain your testing methodology - in detail - before
anyone can provide any useful input.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 8/NIO performance discrepancies

[Piyush Kumar Nayak]

We have been testing different connectors of tomcat for performance.
We have tested the following server versions:

-  Tomcat 7.077

-  Tomcat 8.0.44

-  Tomcat 8.0.32

-  Tomcat 8.5.14

with the following HTTP connectors:

-  BIO

-  BIO with Executor

-  NIO

-  NIO with Executor

Our observation is that NIO is up to 15% faster than BIO. But BIO with Executor 
is up to 65% faster than BIO. Using a shared executor thread pool with NIO does 
not improve the performance. We have tried some variations of connector 
attribute with Tomcat 8 (maxThreads, acceptorThreadCount), but nothing brings 
us close to the performance that we can get with BIO with Executor.

We have upgraded to Tomcat 8.5, and can't seem to get it to perform as well as 
Tomcat 7 using BIO with Executor, which is what we were using earlier.

I would appreciate any help with the following:

-  Why is the executor not boosting the performance for NIO, as it is 
for BIO?

-  BIO is not available as an option with Tomcat 8.5. Why has it been 
removed? Is there any way to get it back ?

I'd be happy to share any other details from my testing for any clarification.

Regards,
Piyush.