processes=1 and threads=30 also seems to solve the performance problem. BTW, I'm having a dickens of a time reproducing the problem in my servers (either the actual server or the VM). I have not been able to discover how to reset the state of my tests, so I have to blindly go around trying to reproduce the problem. I thought it might be a caching problem in the browser, but clearing the browser cache doesn't seem to reset the state. Restarting Apache doesn't always reset the state, either. Restarting the browser doesn't reset the state. In desperation, I've even tried rebooting the systems. Nada.
This is very frustrating. I shall have to continue my investigation before coming to a definitive conclusion. On Wednesday, 19 March 2014 21:06:02 UTC-4, Tim Richardson wrote: > > Try threads = 30 or 50 or 100; that would be interesting. Every request > which is routed through web2py will try to start a new thread. Every web > page will potentially generate multiple requests (for assets like images, > scripts etc). So you can potentially need a lot of threads. When you > started two processes, you may not have specified threads which meant you > had a pool of 30 threads (and then you saw better performance). Using few > threads than that isn't going to conclude very much, I think. > -- 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.
