I'm considering delving into DTrace to find out what's going on, but any such instrumentation is apparently very problematic in Linux (eg, poor support, poor documentation, etc.). Is there any other way to find out what the hell is going on?
On Saturday, 22 March 2014 16:24:20 UTC-4, horridohobbyist wrote: > > Well, according to the 'free' command, even when I'm getting these > slowdowns, I'm nowhere close to the memory limits: > > total used free shared buffers cached > Mem: 3925244 392900 3532344 0 23608 123856 > > Like I said, my Linux server doesn't do much. It doesn't get much traffic, > either. So it has plenty of free memory. > > > On Saturday, 22 March 2014 12:49:21 UTC-4, Massimo Di Pierro wrote: >> >> 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.
