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.

Reply via email to