Re: AssertionError on barrier addWaiter

--===============5196930250157452474==
Content-Type: multipart/alternative; boundary=94eb2c05ecfc7a3ed1054ec2b1af

--94eb2c05ecfc7a3ed1054ec2b1af
Content-Type: text/plain; charset=UTF-8

On 5 May 2017 at 08:02, Amaury Denoyelle <[email protected]> wrote:

>
> Do you have any idea of the cause of the problem ? Is 10,000 threads
> waiting on one barrier a little bit overkill ?
>

I can't speak about your barrier exception, but I can say that 5000 threads
per server is quite a large number for the JVM to manage. With reasonably
simple test code I usually have a rule of thumb of no more than 100 threads
per core with random sleeps between HTTP requests. This would imply a 50
core server for 5000 concurrent threads.

However you may have a bigger problem if a many of those 5000 threads are
being synchronised at a barrier. You say that the threads aren't
synchronised, but with that number of threads the Linux scheduler is likely
being hammered as many threads become ready to run at the same time. A 16
core hyper-threaded server has 32 hyper-cores, so the Linux scheduler can
physically only concurrently schedule 32 threads. If you're using Windows
the problem is likely worse as the Linux scheduler is a lot more
lightweight than the Windows scheduler.

Finally, keep an eye on your JVM Garbage Collection. With some many threads
creating objects your GC is likely running quite hot.

In all, you will be fighting a lot with your test execution performance and
need to prove to yourself that it isn't the primary bottleneck, otherwise
your test time will reflect the performance of your test harness and not
system under test.

Regards,
Gary

--94eb2c05ecfc7a3ed1054ec2b1af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 5=
 May 2017 at 08:02, Amaury Denoyelle <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><b=
r>
Do you have any idea of the cause of the problem ? Is 10,000 threads<br>
waiting on one barrier a little bit overkill ?<br></blockquote><div><br></d=
iv><div>I can&#39;t speak about your barrier exception, but I can say that =
5000 threads per server is quite a large number for the JVM to manage. With=
 reasonably simple test code I usually have a rule of thumb of no more than=
 100 threads per core with random sleeps between HTTP requests. This would =
imply a 50 core server for 5000 concurrent threads.</div><div><br></div><di=
v>However you may have a bigger problem if a many of those 5000 threads are=
 being synchronised at a barrier. You say that the threads aren&#39;t synch=
ronised, but with that number of threads the Linux scheduler is likely bein=
g hammered as many threads become ready to run at the same time. A 16 core =
hyper-threaded server has 32 hyper-cores, so the Linux scheduler can physic=
ally only concurrently schedule 32 threads. If you&#39;re using Windows the=
 problem is likely worse as the Linux scheduler is a lot more lightweight t=
han the Windows scheduler.</div><div><br></div><div>Finally, keep an eye on=
 your JVM Garbage Collection. With some many threads creating objects your =
GC is likely running quite hot.</div><div><br></div><div>In all, you will b=
e fighting a lot with your test execution performance and need to prove to =
yourself that it isn&#39;t the primary bottleneck, otherwise your test time=
 will reflect the performance of your test harness and not system under tes=
t.</div><div><br></div><div>Regards,</div><div>Gary</div></div></div></div>

--94eb2c05ecfc7a3ed1054ec2b1af--


--===============5196930250157452474==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============5196930250157452474==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
grinder-use mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/grinder-use

--===============5196930250157452474==--