Just to pre-empt Stefans final results....
I have been talking with stefan about his test setup - he is not
using persistent connections as you can see :
Socket Connects == Hit Counts
He has indicated to me that using persistent connections, he is getting
well over 100 requests per second.
But I'll say no more until his final results are out - I just don't
like leaving statements like "If Jetty only serves 20 Req/sec" hanging...
Stefan R�per wrote:
>
> Marc Fleury wrote:
> >Just answer me one question: Did you use the j2ee deployer???? (yes/no)
>
> Marc,
> i used the hot deployment feature of jboss, so creating a .ear file, copying to
>$JBOSS_HOME/deploy and sitting back waiting for the mesagge "deployed".
>
> Is this the j2ee deployer ?
> If not, what did i have to do to use it (or where did i find info about this topic) ?
>
> >THE ONLY THING IS CAN THINK OF that would be different is the "integration
> >of engines" and that means that you get "serialization" between tomcat and
> >JBoss. This would account for the difference in time from a JBoss
> >perspective.
>
> This is what i think also, i am just talking with Greg Wilkins about jetty
>standalone performance.
> It looks like standalone Jetty has a 4 times higher performance for servlets then
>jetty started as a service of jboss.
>
> BTW: If Jetty only serves 20 Req/sec, i will never get more out from jboss because i
>use a servlet to access my beans.
>
> At least one question: Where did your numbers come from ? Is your test part of the
>testing suite of jBoss ?
>
> Greetings,
>
> Stefan R�per
>
> SoftWork EDV GmbH
> Robert-Bosch-Str.12, 30989 Gehrden
> Tel: +49 5108 / 6402 -11 Fax: -29 Mobil: +49 177 / 277 48 71
> http://www.softwork-edv.de
> mailto:[EMAIL PROTECTED]
>
> -----Urspr�ngliche Nachricht-----
> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]Im Auftrag von marc fleury
> Gesendet: Mittwoch, 29. November 2000 17:49
> An: jBoss
> Betreff: RE: [jBoss-User] jBoss Performance - Benchmark
>
> |1 - the time needed to transfer the GET request to the server (Network)
> |2 - the time to process the request in the web server (figuring
> |out it is a servlet call)
> |3 - the time to pass the request to the servlet
> |4 - the time the servlet needs to fullfill the request
> |5 - the time to call the session bean
>
> This is optimized in jboss-tomcat/jboss-jetty.
>
> If not optimized then you *serialize* and you can run 10ms if optimized it
> is immediate (pointer invocation).
>
> |6 - the time to find all entities (one database select query,
> |which also uses network)
>
> This is the DB query speed mostly (1-20ms) and some container object
> creation (0.4ms)
> |7 - the time to return the result from session bean to servlet
>
> Then you have *serialization* back if you are not optimized
> we run from 1byte to 1kbyte, the difference is 0.2 ms to 200 ms for the RMI
> response.
> (so 300byte... 60ms which is roughly 17invocations/second for a payload like
> that in RMI (doesn't count overhead just payload))
>
> JVM SERIALIZATION IS ****SLOW**** IF YOU ARE NOT OPTIMIZED THIS COUNTS ALOT
>
> |8 - the time to return the result to the client (again Network)
>
> no not network, *serialization*.
>
> |Because the data returned to the client is only 365 Bytes, which
> |will fit in one network package, and there are only a few calls
> |/sec, Network speed doesn't count much.
>
> irrelevant, again not network, serialization. Serializing 5000 request means
> 1.5MB of total serialization from the VM which *would more than account for
> differences between any applciation*
>
> serialization is a slow horse, I am sure you are missing "optimization".
> Just answer me one question: Did you use the j2ee deployer???? (yes/no)
>
> If no you don't have optimization.
>
> |To see what i mean, look on this excerpt of the results for the
> |orion server test:
> |Socket Statistics
> |-------------------------------------------------------------------
> |-------------
> |Socket Connects: 9262
> |Total Bytes Sent (in KB): 2125.56
> |Bytes Sent Rate (in KB/s): 17.69
> |Total Bytes Recv (in KB): 4757.63
> |Bytes Recv Rate (in KB/s): 39.59
>
> Right! the EJB-servlet layer is probably optimized out so the RMI layer you
> don't see.
>
> |The database is also very unlikely a performance bottleneck, only
> |very few data will be requested.
>
> hmmm that is incorrect.
>
> The database access is most of what you do in the container.
>
> |So, Web Server Speed, Servlet Engine Speed, Application Server
> |Speed and integration of this three is what counts.
>
> No, (and a yes)
>
> what counts is JVM serialization speed and database. (look at our number
> there are THREE orders of magnitude depending on the bean) OUR EJB
> container for stateless/stateful/entity runs around 0.2ms/0.6ms, ***no
> matter how big or small the bean*** (it is all pointer manipulation) AND UP
> TO 1000 clients on a "cheap PC" the rest is in byte writing to socket and DB
> queries. I can't speak for the other engines, but again the logic in the
> container is "nothing", it is socket writing and serialization that is
> tough.
>
> THE ONLY THING IS CAN THINK OF that would be different is the "integration
> of engines" and that means that you get "serialization" between tomcat and
> JBoss. This would account for the difference in time from a JBoss
> perspective.
>
> Did you use the deployer (J2EE deployer) to deploy your application? can you
> describe your deployment? At some point we would need to see the code, this
> "I saw this" discussion is kind of silly. But before anything, did you use
> the deployer if not you are serializing.
>
> marc
>
> |
> |
> |Explanation of TTFB - Time to first byte
> |To get a better understanding look one these Page results (again
> |from orion server test):
> |
> |Page Results
> |===================================================================
> |=============
> |URI: GET /telephone/servlet/TelephoneServlet
> |Hit Count: 9262
> |
> |Result Codes
> |Code Description Count
> |-------------------------------------------------------------------
> |-------------
> |200 OK 9262
> |
> |Time to first byte (in milliseconds)
> |-------------------------------------------------------------------
> |-------------
> |Average: 817.82
> |Min: 9.40
> |25th Percentile: 253.86
> |50th Percentile: 390.58
> |75th Percentile: 990.28
> |Max: 21739.87
> |
> |Here is TTFB, the fastest response was only 9.40 ms, while the
> |slowest was over 21 seconds!
> |At average every thread has to wait 817.82 ms to see the first
> |Byte of the result.
> |
> |
> |Time to last byte (in milliseconds)
> |-------------------------------------------------------------------
> |-------------
> |Average: 840.90
> |Min: 10.36
> |25th Percentile: 265.62
> |50th Percentile: 409.47
> |75th Percentile: 1034.60
> |Max: 21741.60
> |
> |Downloaded Content Length (in bytes)
> |-------------------------------------------------------------------
> |-------------
> |Min: 365
> |25th Percentile: 365
> |50th Percentile: 365
> |75th Percentile: 365
> |Max: 365
> |
> |As you can easily see the result is always the same byte count. So
> |all counted request are successfull.
> |
> |Sorry for this long mail, but hopefully this clarifies the test a
> |little bit.
> |
> |StefanN<n�?�n<�Ǣy�ܮH?ڱ�N<��r�z6��z�~X�
> |?)v^r?�?zk�|�H?ڱ�
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
> N<.n�+?��n<,�ǫ�yb��(�H�?� ��&N<����r�>z6�ˬz� ~X��
> +?)�v^,r??�?�zk#�|(�H�?� ��&
--
Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)2074394045
Mort Bay Consulting Australia and UK. Mbl Phone: +44-(0)7775534369
http://www.mortbay.com AU Phone: +61-(0)2 99772395
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
