Could it be the GIIL. web2py is a multi-threaded app. Are the threads 
created by the web server doing anything?
What if you use a non-threaded server like gunicorn instead?


On Saturday, 15 March 2014 21:34:56 UTC-5, horridohobbyist wrote:
>
> Well, putting back all my apps hasn't widened the discrepancy. So I don't 
> know why my previous web2py installation was so slow.
>
> While the Welcome app with the calculations test shows a 2x discrepancy, 
> the original app that initiated this thread now shows a 13x discrepancy 
> instead of 100x. That's certainly an improvement, but it's still too slow.
>
> The size of the discrepancy depends on the code that is executed. Clearly, 
> what I'm doing in the original app (performing permutations) is more 
> demanding than mere arithmetical operations. Hence, 13x vs 2x.
>
> I anxiously await any resolution to this performance issue, whether it be 
> in WSGI or in web2py. I'll check in on this thread periodically...
>
>
> On Saturday, 15 March 2014 16:19:12 UTC-4, horridohobbyist wrote:
>>
>> Interestingly, now that I've got a fresh install of web2py with only the 
>> Welcome app, my Welcome vs command line test shows a consistent 2x 
>> discrepancy, just as you had observed.
>>
>> My next step is to gradually add back all the other apps I had in web2py 
>> (I had 8 of them!) and see whether the discrepancy grows with the number of 
>> apps. That's the theory I'm working on.
>>
>> Yes, yes, I know, according to the Book, I shouldn't have so many apps 
>> installed in web2py. This apparently affects performance. But the truth is, 
>> most of those apps are hardly ever executed, so their existence merely 
>> represents a static overhead in web2py. In my mind, this shouldn't widen 
>> the discrepancy, but you never know.
>>
>>
>> On Saturday, 15 March 2014 11:19:06 UTC-4, Niphlod wrote:
>>>
>>> @mcm: you got me worried. Your test function was clocking a hell lower 
>>> than the original script. But then I found out why; one order of magnitude 
>>> less (5000 vs 50000). Once that was corrected, you got the exact same clock 
>>> times as "my app" (i.e. function directly in the controller). I also 
>>> stripped out the logging part making the app just return the result and no 
>>> visible changes to the timings happened.
>>>
>>> @hh: glad at least we got some grounds to hold on. 
>>> @mariano: compiled or not, it doesn't seem to "change" the mean. a 
>>> compiled app has just lower variance. 
>>>
>>> @all: jlundell definitively hit something. Times are much more lower 
>>> when threads are 1.
>>>
>>> BTW: if I change "originalscript.py" to 
>>>
>>> # -*- coding: utf-8 -*-
>>> import time
>>> import threading
>>>
>>> def test():
>>>     start = time.time()
>>>     x = 0.0
>>>     for i in range(1,50000):
>>>         x += (float(i+10)*(i+25)+175.0)/3.14
>>>     res = str(time.time()-start)
>>>     print "elapsed time: "+ res + '\n'
>>>
>>> if __name__ == '__main__':
>>>     t = threading.Thread(target=test)
>>>     t.start()
>>>     t.join()
>>>
>>> I'm getting really close timings to "wsgi environment, 1 thread only" 
>>> tests, i.e. 
>>> 0.23 min, 0.26 max, ~0.24 mean
>>>
>>>

-- 
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