-
1. Re: undertow from wildfly-8.0.0.beta1 performance
smarlow Oct 10, 2013 9:43 PM (in response to ivagulin)What is the performance if you remove the JPA part?
-
2. Re: undertow from wildfly-8.0.0.beta1 performance
ivagulin Oct 11, 2013 4:21 AM (in response to ivagulin)Without JPA a bit faster, but whole picture stays the same.
[igor@ivagulin-pc ~]$ weighttp -c1 -t1 -n100000 -k http://127.0.0.1:8080/j2ee-domains/rest/domains/2/
finished in 16 sec, 544 millisec and 122 microsec, 6044 req/s, 1434 kbyte/s
I'am quite sure problem is 2 read calls on undertow vs 1 read call on jboss-web. Context switches count (in first post) confirm this.
undertow:
[igor@ivagulin-pc ~]$ strace -fe read weighttp -c1 -t1 -n1 -k http://127.0.0.1:8080/j2ee-domains/rest/domains/2/
...
[pid 1804] read(6, "HTTP/1.1 200 OK\r\nConnection: kee"..., 32767) = 236
[pid 1804] read(6, "\r\n0\r\n\r\n", 32767) = 7...
jboss-web:
[igor@ivagulin-pc ~]$ strace -fe read weighttp -c1 -t1 -n1 -k http://127.0.0.1:8080/j2ee-domains/rest/domains/2/
...
[pid 2475] read(6, "HTTP/1.1 200 OK\r\nServer: Apache-"..., 32767) = 297
...
Sometimes on jboss-web I also see 2 read calls but it mostly 1
-
3. Re: undertow from wildfly-8.0.0.beta1 performance
swd847 Oct 11, 2013 5:19 AM (in response to ivagulin)Are you using CDI? If not remove the weld subsystem and see if that improves matters. CDI is active by default now, and there are some perf problems with the weld listener that we are still working on.
The 2 read calls issue looks like a bug in our chunking implementation, I will fix it up for the next Undertow release.
-
4. Re: undertow from wildfly-8.0.0.beta1 performance
swd847 Oct 11, 2013 5:51 AM (in response to ivagulin)Can you give some more details about your test? In particular:
- How much data are you writing out?
- Are you calling flush() before you call close() ?
-
5. Re: undertow from wildfly-8.0.0.beta1 performance
ivagulin Oct 12, 2013 7:46 AM (in response to ivagulin)> How much data are you writing out?
129 bytes. Full working sources here https://github.com/ivagulin/j2ee-domains
[igor@ivagulin-pc ~]$ curl http://localhost:8080/j2ee-domains/rest/domains/2/ 2>/dev/null | wc -c
129
[igor@ivagulin-pc ~]$ curl http://localhost:8080/j2ee-domains/rest/domains/2/
{"id":1,"domainName":"example.com","email":"igor.vagulin@gmail.com","ttl":"ttl","expire":3,"refresh":3600,"retry":3,"serial":114}> Are you calling flush() before you call close() ?
I believe you mean in http client. No close or flush. http-keepalive used so all queries go in one tcp connection. If http keepalive not used it is hard to get full performance from webserver, as half of time spent on socket creation, connections and such.
I use weighttp, opensource http testing tool. It is slightly patched because original didn't work well with undertow chunks. Here is soruces, can be easily build on linux box https://github.com/ivagulin/weighttp
-
6. Re: undertow from wildfly-8.0.0.beta1 performance
swd847 Oct 31, 2013 6:53 AM (in response to ivagulin)So it looks like the underlying cause was not the issue that I originally thought, but rather it is causes by Jackson calling flush() on the Servlet output stream. JBoss web has a secondary buffer that the data gets flushed to (so it effect the flush() call does not actually flush the data to the client), while undertow just flushes directly.
I am thinking maybe I should add an option to ignore a flush (well semi-ignore, the response would still be treated as commited), as in 99% of cases flush is unnecessary and a performance killer.