Ok yes my bad, it does make sense...
the number we see is that we get 3000 calls per second and that on average
the container takes 0.4 ms to process a call no matter what the load. I had
my math reversed :))) (4M calls per second sounded strange indeed ;-)
So the good news is that the time it takes for the container to do a call is
constant regardless of the number of clients. The container throughput is
stable at 2500 clients-calls/second.
I guess the metric we should show is "throughput"
In the case of 60 clients (what the 'benchmark' was running) we should see
something of the order of 24ms delay for the first response in the container
(60 x 0.4ms =24ms) which is roughly, which means each thread does 40 calls
per seconds, stabilizing at 2500 clients calls s-1 on the container.
The rest of the time spent per thread (above 24ms) is in db and
serialization.
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|[EMAIL PROTECTED]
|Sent: Wednesday, November 29, 2000 4:39 PM
|To: jBoss
|Subject: Re: [jBoss-User] jBoss Performance - Benchmark
|
|
|marc fleury wrote:
|
|> |a) If I have 5000 clients permanently calling a read-only method on a
|> |optimized entity bean the 5001st client will probably have to wait
|> |around 1.26 ms for getting the result from the call (That would mean the
|> |container handles 1000/1.26 * 5000 = 3,968,254 calls/s, phewha !)
|>
|> each client does wait the 1.26ms with 5000 parallel guys so...
|yes. (afaik)
|>
|> unless we are doing something horribly wrong, btw the code is in
|jbosstest
|>
|> I guess you just calculated the "container throughput"... he he
|
|Hi, sorry, but the right answer is option b).
|
|The container throughput is about 1000 calls/second, and the good news
|is that this stays kind of stable until 2000 clients. But the 2001th
|client does see a response time of 2000*1ms=2s.
|
|Anyway this is just "for the record", since jboss will usually be used
|with something in the front end (eg apache) to prevent such a load.
|
|Sebastien
|
|
|>
|> marc
|>
|> |
|> |or
|> |
|> |b) If I start 5000 clients at the same time (same call as above) with
|> |just one request per client the result for the "last" client will be
|> |received after 5000*1.26ms ?
|>
|> no *each* client waits 1.26 ms per call on average
|>
|> (That would mean that I can expect the
|> |container to process about 5000 calls in 5000*1.26ms, which makes
|> |1000/1.26 = 763 calls/s)
|> |
|> |Just curious ...
|> |
|> |Tobias
|> |
|> |
|> |marc fleury wrote:
|> |>
|> |> Test Description Number of concurrent clients
|> |> 1 10 50 100 200 500 1000 2000 5000
|> |>
|> |> (all times in ms)
|> |>
|> |> Read-only call on an entity bean (optimized) 0.83038 1.3163 0.66576
|> |> 0.6892 0.687 0.71442 0.78052 0.8346 1.25902
|> |> Read-only call on an entity bean (serialized) 8.65604
|2.17434 2.56748
|> |> 2.09062 1.98144 2.12986 2.40266 2.54646 1.91216
|> |> Call to stateful session (optimized) 0.26798 0.2712
|0.30144 0.31946
|> |> 0.2788 0.25258 0.273 0.2904 0.33208
|> |> Call to stateless session (optimized) 0.25756 0.26176
|0.28222 0.29342
|> |> 0.28702 0.23854 0.25636 0.29542 0.31706
|> |>
|> |> This is done on a Compaq 700Mhz 256Meg RAM win2k, SUN 1.3 VM
|> |>
|> |> THE IMPORTANT PART OF THIS IS THE READ-ONLY CALL FOR ENTITIES
|> |>
|> |> because it goes through all the container layers the cache lookup the
|> |> contention (there is loads of it there) etc etc
|> |>
|> |> THE CONTAINER LAYERS FOR ENTITY RUN 0.7ms STABLE EVEN WITH
|****2000****
|> |> CLIENTS IN PARALLEL (2000 threads)
|> |>
|> |> ALSO NOTE THAT WE DRIVE THE STUFF FROM THE SAME MACHINE SO THE
|> |CLIENT LOAD
|> |> IS ******IN*******
|> |>
|> |> IF YOU SEE SOMETHING ABOVE 1MS IT IS EITHER NETWORK OR DB!!!!!!!!!!!!
|> |>
|> |> <STRONG EMPHASIS> WE ARE ALSO VERY HAPPY WITH THE FACT THE CONTAINER
|> |> ******SCALES***** EXTREMELLY WELL</STRONG EMPHASIS>
|> |
|> |
|> |--
|> |--------------------------------------------------------------
|> |To subscribe: [EMAIL PROTECTED]
|> |To unsubscribe: [EMAIL PROTECTED]
|> |Problems?: [EMAIL PROTECTED]
|> |
|> |
|>
|> --
|> --------------------------------------------------------------
|> To subscribe: [EMAIL PROTECTED]
|> To unsubscribe: [EMAIL PROTECTED]
|> Problems?: [EMAIL PROTECTED]
|
|
|--
|--------------------------------------------------------------
|To subscribe: [EMAIL PROTECTED]
|To unsubscribe: [EMAIL PROTECTED]
|Problems?: [EMAIL PROTECTED]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
