Have you checked memory consumption? On Saturday, 22 March 2014 10:15:59 UTC-5, horridohobbyist wrote: > > Scratch my solution. It's not correct. My test results are all over the > place. You don't even have to wait an hour. Within the span of 15 minutes, > I've gone from fast, fast, fast, fast, fast, fast to super-slow (90+ > seconds), super-slow to slow, slow, slow, slow. The variability seems to be > pseudo-random. > > I should also mention that "threads=30" doesn't always work. This is > probably part of the pseudo-random nature of the problem. > > I don't think the solution lies in configuring "processes" and "threads" > in the Apache web2py configuration. At this point, I don't know what else > to do or try. > > > On Saturday, 22 March 2014 11:01:16 UTC-4, horridohobbyist wrote: >> >> Something very strange is going on. After I've run the Welcome test where >> the results are consistently fast (ie, ~1.6 seconds), if I wait an hour or >> so and run the test again, I get something like the following: >> >> Begin... >> Elapsed time: 97.1873888969 >> Percentage fill: 41.9664268585 >> Begin... >> Elapsed time: 1.63321781158 >> Percentage fill: 41.9664268585 >> Begin... >> Elapsed time: 13.2418119907 >> Percentage fill: 41.9664268585 >> Begin... >> Elapsed time: 1.62313604355 >> Percentage fill: 41.9664268585 >> Begin... >> Elapsed time: 13.3058979511 >> Percentage fill: 41.9664268585 >> >> The first run is ENORMOUSLY slow. Subsequently, the runtimes alternate >> between fast and slow (ie, 1.6 seconds vs 13 seconds). >> >> To reiterate: This happens if I give the server lots of time before I >> resume testing. Please note that nothing much else is happening on the >> server; it gets very little traffic. >> >> If I restart Apache, then I get back to the initial situation where the >> results are consistently fast. *This pattern is repeatable*. >> >> FYI, I'm using "processes=2" and "threads=1". >> >> >> On Thursday, 20 March 2014 11:34:03 UTC-4, horridohobbyist wrote: >>> >>> 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.
