very interesting. What is code being benchmarked here?
could you post your apache configuration?
On Monday, 17 March 2014 11:08:53 UTC-5, horridohobbyist wrote:
>
> Anyway, I ran the shipping code Welcome test with both Apache2 and
> Gunicorn. Here are the results:
>
> Apache:Begin...
> Apache:Elapsed time: 0.28248500824
> Apache:Elapsed time: 0.805250167847
> Apache:Percentage fill: 60.0
> Apache:Begin...
> Apache:Elapsed time: 0.284092903137
> Apache:Elapsed time: 0.797535896301
> Apache:Percentage fill: 60.0
> Apache:Begin...
> Apache:Elapsed time: 0.266696929932
> Apache:Elapsed time: 0.793596029282
> Apache:Percentage fill: 60.0
> Apache:Begin...
> Apache:Elapsed time: 0.271706104279
> Apache:Elapsed time: 0.770045042038
> Apache:Percentage fill: 60.0
> Apache:Begin...
> Apache:Elapsed time: 0.26541185379
> Apache:Elapsed time: 0.798058986664
> Apache:Percentage fill: 60.0
> Gunicorn:Begin...
> Gunicorn:Elapsed time: 0.0273849964142
> Gunicorn:Elapsed time: 0.0717470645905
> Gunicorn:Percentage fill: 60.0
> Gunicorn:Begin...
> Gunicorn:Elapsed time: 0.0259709358215
> Gunicorn:Elapsed time: 0.0712919235229
> Gunicorn:Percentage fill: 60.0
> Gunicorn:Begin...
> Gunicorn:Elapsed time: 0.0273978710175
> Gunicorn:Elapsed time: 0.0727338790894
> Gunicorn:Percentage fill: 60.0
> Gunicorn:Begin...
> Gunicorn:Elapsed time: 0.0260291099548
> Gunicorn:Elapsed time: 0.0724799633026
> Gunicorn:Percentage fill: 60.0
> Gunicorn:Begin...
> Gunicorn:Elapsed time: 0.0249080657959
> Gunicorn:Elapsed time: 0.0711901187897
> Gunicorn:Percentage fill: 60.0
>
> There is no question that the fault lies with Apache.
>
>
> On Monday, 17 March 2014 00:05:58 UTC-4, Massimo Di Pierro wrote:
>>
>> What kind of VM is this? What is the host platform? How many CPU cores?
>> Is VM using all the cores? The only thing I can think of is the GIL and the
>> fact that multithreaded code in python gets slower and slower the more
>> cores I have. On my laptop, with two cores, I do not see any slow down.
>> Rocket preallocate a thread pool. The rationale is that it decreases the
>> latency time. Perhaps you can also try rocket in this way:
>>
>> web2py.py --minthreads=1 --maxthreads=1
>>
>> This will reduce the number of worker threads to 1. Rocket also runs a
>> background non-worker thread that monitors worker threads and kills them if
>> they get stuck.
>>
>> On Sunday, 16 March 2014 20:22:45 UTC-5, horridohobbyist wrote:
>>>
>>> Using gunicorn (Thanks, Massimo), I ran the full web2py Welcome code:
>>>
>>> Welcome: elapsed time: 0.0511929988861
>>> Welcome: elapsed time: 0.0024790763855
>>> Welcome: elapsed time: 0.00262713432312
>>> Welcome: elapsed time: 0.00224614143372
>>> Welcome: elapsed time: 0.00218415260315
>>> Welcome: elapsed time: 0.00213503837585
>>>
>>> Oddly enough, it's slightly faster! But still 37% slower than the
>>> command line execution.
>>>
>>> I'd really, really, **really** like to know why the shipping code is 10x
>>> slower...
>>>
>>>
>>> On Sunday, 16 March 2014 21:13:56 UTC-4, horridohobbyist wrote:
>>>>
>>>> Okay, I did the calculations test in my Linux VM using command line
>>>> (fred0), Flask (hello0), and web2py (Welcome).
>>>>
>>>> fred0: elapsed time: 0.00159001350403
>>>>
>>>> fred0: elapsed time: 0.0015709400177
>>>>
>>>> fred0: elapsed time: 0.00156021118164
>>>>
>>>> fred0: elapsed time: 0.0015971660614
>>>>
>>>> fred0: elapsed time: 0.00315999984741
>>>>
>>>> hello0: elapsed time: 0.00271105766296
>>>>
>>>> hello0: elapsed time: 0.00213503837585
>>>>
>>>> hello0: elapsed time: 0.00195693969727
>>>>
>>>> hello0: elapsed time: 0.00224900245667
>>>>
>>>> hello0: elapsed time: 0.00205492973328
>>>> Welcome: elapsed time: 0.0484869480133
>>>>
>>>> Welcome: elapsed time: 0.00296783447266
>>>>
>>>> Welcome: elapsed time: 0.00293898582458
>>>>
>>>> Welcome: elapsed time: 0.00300216674805
>>>>
>>>> Welcome: elapsed time: 0.00312614440918
>>>>
>>>> The Welcome discrepancy is just under 2x, not nearly as bad as 10x in
>>>> my shipping code.
>>>>
>>>>
>>>> On Sunday, 16 March 2014 17:52:00 UTC-4, Massimo Di Pierro wrote:
>>>>>
>>>>> 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.
