I don't understand why the Flask version of the Welcome test doesn't exhibit this slowdown under Apache. It's executing the same application code. It's configured with the same "processes=1" and "threads=1" WSGI parameters. It's running the same Python interpreter (and presumably using the same GIL).
I'm not sure it's entirely Apache's fault. I suspect it's in the *interaction* between Apache and web2py. The interaction between Apache and Flask seems to avoid this problem. However, I am ill-equipped to follow up on this. On Saturday, 22 March 2014 16:28:22 UTC-4, horridohobbyist wrote: > > 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.
