here you go: 1 - db migration is enabled, you should only migrate once and unless you modify your model, you should disable migration. This is generally a deployment step. It would hurt the performance of DAL, which is exactly what we're seeing in these benchmarks.
2 - no caching is enabled. caching is always recommended as a performance improvement as it has the greatest impact. You can use the cache decorator for index, hellos, hellodb, hellodb2, especially since no request variables are used. Adding a cache decorator to those functions, like so: @cache<http://www.web2py.com/examples/global/vars/cache> (request <http://www.web2py.com/examples/global/vars/request>.env.path_info, time_expire=500,cache_model=cache<http://www.web2py.com/examples/global/vars/cache> .ram) and adding changing the return to 'return response.render(dicts) where dicts = dict(rows=rows) or rows=lorem... 3 - sessions should be disabled since it's apparent you are not using them here. adding a call to 'session.forget(response)' as the first line of the function should handle that. If you don't disable sessions, you're limiting web2py to handling one request at a time. 4 - use anyserver.py to serve using gevent or some other async server. (you can still use mod_wsgi). Those are what immediately come to mind. On Sunday, April 21, 2013 1:05:44 PM UTC-7, OJ wrote: > > The application was copied from > https://github.com/seedifferently/the-great-web-framework-shootout/issues/14 > ... > Please point me some performance problems and I'll fix and re-run the > tests. > > .oj > > On Wednesday, April 17, 2013 1:05:35 AM UTC+3, Derek wrote: >> >> Seems a bit low, but no way to really critique until we see the >> application. If you were using the one in issue 14, I can point to several >> performance problems in that application already. >> Also, what version of web2py? >> >> One thing I noticed, you aren't using gevent or any other concurrency >> framework. If you are publishing your site on the internet, and performance >> is essential (hint: it almost always is), chances are you'd use one. >> >> On Tuesday, April 16, 2013 9:18:42 AM UTC-7, OJ wrote: >>> >>> Ok guys here are the results. >>> >>> I repeated and confirmed the results that the great web framework >>> shootout did. Web2py was tested with the application Massimo provided (with >>> couple of fixes that you guys helped me to do). Tests were done in Amazon >>> EC2 M1 Large instance. Because other frameworks were tested using Apache + >>> mod_wsgi combination, web2py were tested the same way. I also wanted to >>> know how fast Rocket was so I tested with it also. All configurations to >>> run web2py followed Massimos complete reference manual 5th edition. >>> >>> Tests were done with 'ab -n 10000 -c 5' and they were run 10 times. >>> Results are average results from these runs (there were no significant >>> deviations). >>> >>> Here are the results for web2py: >>> >>> "Hello world!"-test: web2py apache + mod_wsgi: 459 requests /second, >>> web2py rocket: 363 req/sec (Django: 2012 req/sec, Flask 1858 req/sec) >>> Template test: web2py apache + mod_wsgi: 344 req/sec, web2py rocket: 292 >>> req/sec, (Django: 925 req/sec, Flask: 1625 req/sec) >>> Database + template: web2py apache + mod_wsgi 274 req/sec (sqlite) and >>> 180 req/sec (DAL), web2py with rocket: 245 req/sec (sql), 171 req/sec >>> (DAL)(Django: 450 req/sec, Flask 1076 req/sec) >>> >>> .oj >>> >>> >>> On Monday, March 4, 2013 10:00:42 PM UTC+2, OJ wrote: >>>> >>>> I will, >>>> >>>> I'm currently figuring out how to arrange my EC2 instance. After that >>>> I'm looking for advice with web2py / Apache setup :) One problem at the >>>> time. >>>> >>>> On Sunday, March 3, 2013 3:37:32 PM UTC+2, wwwgong wrote: >>>>> >>>>> Please share the benchmark results when avail >>>> >>>> -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
