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�nlj�n��Ǣy�ܮH�ڱ�N���r�z6��z�~X�
|�)v�r���zk�|�H�ڱ�
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
���r��z6�ˬz�'�+-Š�x � �d�{.n�+���n�,�ǫ����p��"�h��(���nW��:'Š�x � �
