Re: [Koha-devel] "The Plack effect" benchmarked
Le 06/06/2012 13:36, Mark Tompsett a écrit :
Greetings, Hi Mark, (answer to koha-devel, as it's of general interest)
These results look good, but how much memory is on the machine you are testing this on? Would it have the same effect in a VM server type environment limited to 204MB? Is there an amount of memory which makes it behave at similar or worse speeds? I think you missed a 8, and speak of 2048 and not 204MB :D
I haven't tested/checked memory, but what I know for sure is that it costs only a small amount of memory. Plack pre-load a lot of things that are loaded on every page by cgi-bin anyway. So you would have 'spent' that memory at run time. Depending on Apache configuration, if 5 ppl are requesting a page at the same time, 5 cgi-bin are launched and 5x memory is consummed. So if you run starman instead of plackup (starman being multi-thread, plackup single thread), the result will be the same. What we have to be *very* careful with is memory hole that result in an always increasing memory consumption. In CGI mode, as everything is freed/deleted after each page, any memory hole is painless. With plack, memory hole will pile up and, at the end ... booom ! (All of this being not measured, so unguaranteed) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Wed, Jun 6, 2012 at 10:10 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 06/06/2012 13:36, Mark Tompsett a écrit :
Greetings, Hi Mark, (answer to koha-devel, as it's of general interest)
These results look good, but how much memory is on the machine you are testing this on? Would it have the same effect in a VM server type environment limited to 204MB? Is there an amount of memory which makes it behave at similar or worse speeds? I think you missed a 8, and speak of 2048 and not 204MB :D
I haven't tested/checked memory, but what I know for sure is that it costs only a small amount of memory.
Plack pre-load a lot of things that are loaded on every page by cgi-bin anyway. So you would have 'spent' that memory at run time.
Depending on Apache configuration, if 5 ppl are requesting a page at the same time, 5 cgi-bin are launched and 5x memory is consummed. So if you run starman instead of plackup (starman being multi-thread, plackup single thread), the result will be the same.
What we have to be *very* careful with is memory hole that result in an always increasing memory consumption. In CGI mode, as everything is freed/deleted after each page, any memory hole is painless. With plack, memory hole will pile up and, at the end ... booom !
This is usually addressed by setting some reasonable amount of requests lifespan for the processes. Anyway, we shouldn't have memory holes! Regards To+
Greetings, The question wasn't about memory holes, though I totally understand the pain they could be. The question was:
Is there an amount of memory which makes [plack] behave at similar or worse speeds [to what we have now]?
Testing for average cases (2GB,4GB,8GB) is fine, but an extreme case or two would be nice. And sadly, I wasn't joking about 204MB. There was no typo. I was wondering, would plack behave poorly in such a cramped memory space. GPML, Mark Tompsett
Hi, schrieb Mark Tompsett am 06.06.2012 15:53:
Testing for average cases (2GB,4GB,8GB) is fine, but an extreme case or two would be nice. And sadly, I wasn't joking about 204MB. There was no typo. I was wondering, would plack behave poorly in such a cramped memory space.
I ran the staff client benchmarks on a slow machine with 224MB RAM and that went really well, 10x faster than without plack. - Mirko
Le 06/06/2012 15:41, Tomas Cohen Arazi a écrit :
What we have to be *very* careful with is memory hole that result in an always increasing memory consumption. In CGI mode, as everything is freed/deleted after each page, any memory hole is painless. With plack, memory hole will pile up and, at the end ... booom !
This is usually addressed by setting some reasonable amount of requests lifespan for the processes. Yes, Dobrica suggested 50 pages iirc.
Anyway, we shouldn't have memory holes! Of course. And maybe we have some since years but never spotted them because of CGI way of doing things
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (4)
-
Mark Tompsett -
Mirko -
Paul Poulain -
Tomas Cohen Arazi