> Multi-threaded apache is supposed to be faster than multi-process apache > under real load (i.e. multiple users) because starting processes is expensive > in time and memory.
IMHO under linux the difference is really negligible. Popularity of threads rose in mid '90 because a very popular OS was not able to do forks properly. Java developed threading API, instead of a multiprocess and message passing API as a consequence of that flaw. Today there is no need of threading in general concurrent programming, unless one is stuck in Java. 2014-03-19 10:24 GMT+01:00 Tim Richardson <t...@growthpath.com.au>: > Did you explicitly set the number of threads as well? By default you get 15 > threads per process. The documentation implies that this is a hard limit, > but I'm not sure. > Maybe you have simply found a bottleneck in threads. Did you also try > increasing the number of threads instead of adding more processes? > Multi-threaded apache is supposed to be faster than multi-process apache > under real load (i.e. multiple users) because starting processes is > expensive in time and memory. > So any conclusion that you need more processes is dubious, I think. I can't > recall how many simultaneous users your benchmarking is testing. > Bear in mind that the fastest servers, the greenlet or co-operative async > servers, are not only limited to one process, but even to one thread. > > > > > > > > > > > > On Wednesday, 19 March 2014 14:25:47 UTC+11, horridohobbyist wrote: >> >> I shall do that. Thanks. >> >> With the knowledge about "processes=", I've tuned my actual Linux server >> to eliminate the 10x slowdown. As it turns out, for my 2.4GHz quad-core Xeon >> with 4GB RAM, "processes=2" works best. I found that any other value (3, 4, >> 5) gave very inconsistent results–sometimes I would get 1x (the ideal) and >> sometimes I would get 10x. Very bizarre. >> >> "processes=2" is counter-intuitive. After all, I have 4 cores. Why >> shouldn't "processes=4" be good? >> >> Anyway, not only is the shipping code fast, but I find that my overall >> web2py app feels a lot snappier. Is it just my imagination? >> >> If "processes=2" is boosting the speed of Python in general, then you >> would expect all of web2py to benefit. So maybe it's not my imagination. >> >> Anyway, the takeaway, I think, is that you must tune the Apache >> configuration for the particular server hardware that you have. The default >> "processes=1" is not good enough. >> >> >> On Tuesday, 18 March 2014 22:37:58 UTC-4, Massimo Di Pierro wrote: >>> >>> Thank you for all your tests. You should write a summary of your results >>> with recommendations for Apache users. >>> >>> On Tuesday, 18 March 2014 19:44:29 UTC-5, horridohobbyist wrote: >>>> >>>> Done. With processes=3, the 10x discrepancy is eliminated! (And this is >>>> in a Linux VM configured for 1 CPU.) >>>> >>>> >>>> On Tuesday, 18 March 2014 16:26:24 UTC-4, Michele Comitini wrote: >>>>> >>>>> > WSGIDaemonProcess hello user=www-data group=www-data threads=5 >>>>> >>>>> with web2py try the following instead: >>>>> WSGIDaemonProcess hello user=www-data group=www-data processes=<number >>>>> of cores + 1> threads=(0 or 1) >>>>> >>>>> If it's faster, then the GIL must be the cause. flask by default has >>>>> much less features active (session for instance) >>>>> >>>>> >>>>> >>>>> 2014-03-18 21:04 GMT+01:00 horridohobbyist <horrido...@gmail.com>: >>>>> > I took the shipping code that I ran in Flask (without Apache) and >>>>> > adapted it >>>>> > to run under Apache as a Flask app. That way, I'm comparing apples to >>>>> > apples. I'm comparing the performance of the shipping code between >>>>> > Flask and >>>>> > web2py. >>>>> > >>>>> > Below, I've included the 'default' file from Apache2/sites-available >>>>> > for >>>>> > Flask. >>>>> > >>>>> > Basically, the code in Flask executes 10x faster than the same code >>>>> > in >>>>> > web2py. So my question is: if Apache is at fault for the web2py >>>>> > app's slow >>>>> > performance, why doesn't Apache hurt the Flask app's performance? >>>>> > (This >>>>> > doesn't seem to be related to GIL or WSGI.) >>>>> > >>>>> > >>>>> > <VirtualHost *:80> >>>>> > ServerName 10.211.55.7 >>>>> > WSGIDaemonProcess hello user=www-data group=www-data threads=5 >>>>> > WSGIScriptAlias / /home/richard/welcome/hello.wsgi >>>>> > >>>>> > <Directory /home/richard/welcome> >>>>> > Order Allow,Deny >>>>> > Allow from all >>>>> > </Directory> >>>>> > </VirtualHost> >>>>> > >>>>> > -- >>>>> > Resources: >>>>> > - http://web2py.com >>>>> > - http://web2py.com/book (Documentation) >>>>> > - http://github.com/web2py/web2py (Source code) >>>>> > - https://code.google.com/p/web2py/issues/list (Report Issues) >>>>> > --- >>>>> > You received this message because you are subscribed to the Google >>>>> > Groups >>>>> > "web2py-users" group. >>>>> > To unsubscribe from this group and stop receiving emails from it, >>>>> > send an >>>>> > email to web2py+un...@googlegroups.com. >>>>> > For more options, visit https://groups.google.com/d/optout. > > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
