In order to isolate the problem one must take it in steps. This is a good
test but you must first perform this test with the code you proposed before:
def test():
t = time.time
start = t()
x = 0.0
for i in range(1,5000):
x += (float(i+10)*(i+25)+175.0)/3.14
debug("elapsed time: "+str(t()-start))
return
I would like to know the results about this test code first.
The other code you are using performs an import:
from shippackage import Package
Now that is something that is very different in web2py and flask for
example. In web2py the import is executed at every request (although it
should be cached by Python) while in flask it is executed only once. This
should also not cause a performance difference but it is a different test
than the one above.
TLTR: we should test separately python code execution (which may be
affected by threading) and import statements (which may be affected by
web2py custom_import and/or module weird behavior).
On Sunday, 16 March 2014 08:47:13 UTC-5, horridohobbyist wrote:
>
> I've conducted a test with Flask.
>
> fred.py is the command line program.
> hello.py is the Flask program.
> default.py is the Welcome controller.
> testdata.txt is the test data.
> shippackage.py is a required module.
>
> fred.py:
> 0.024 second
> 0.067 second
>
> hello.py:
> 0.029 second
> 0.073 second
>
> default.py:
> 0.27 second
> 0.78 second
>
> The Flask program is slightly slower than the command line. However, the
> Welcome app is about 10x slower!
>
> *Web2py is much, much slower than Flask.*
>
> I conducted the test in a Parallels VM running Ubuntu Server 12.04 (1GB
> memory allocated). I have a 2.5GHz dual-core Mac mini with 8GB.
>
>
> I can't quite figure out how to use gunicom.
>
>
> On Saturday, 15 March 2014 23:41:49 UTC-4, horridohobbyist wrote:
>>
>> I'll see what I can do. It will take time for me to learn how to use
>> another framework.
>>
>> As for trying a different web server, my (production) Linux server is
>> intimately reliant on Apache. I'd have to learn how to use another web
>> server, and then try it in my Linux VM.
>>
>>
>> On Saturday, 15 March 2014 22:45:27 UTC-4, Anthony wrote:
>>>
>>> Are you able to replicate the exact task in another web framework, such
>>> as Flask (with the same server setup)?
>>>
>>> On Saturday, March 15, 2014 10:34:56 PM UTC-4, 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.
