|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...
let's debug his setting.
I *really* don't like leaving statements like "seems JBoss only serves 7
req/sec" hanging :)))
specifically when we measure a throughput of 2500 req/sec up to 2000 clients
on a low PC with win2k :)))
marc
|
|
|
|
|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]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
