This is very interesting. I have never used uwsgi and cherokee with web2py. I will try reproduce this.
Massimo On 8 Lug, 09:26, Thadeus Burgess <thade...@thadeusb.com> wrote: > Setup: > > Two applications that perform a simple db insert, db select, render a > template and return it. All in all this is a very small application. > The application has two views, one insert/select view and one select > view. Each of these views are tested separately using apache ab test. > > The insert view, will insert a random 6 letter name into the database, > and return a select of the last 10 records inserted. > > The ab test compose of several of the recommended tests that can > easily be found in a google search. Different tests compose of > concurrency, number of connections, etc etc. Each tested individually. > The web server was restarted and the database reset in between each ab > test to prove that everything is starting with a fresh slate. > > The db is in postgresql, and uses the following schema: > > TABLE friends > COL id > COL name > > Each application has their own blank database in postgres to start. > > Web Server: Cherokee with uwsgi running on a 256MB VPS with slicehost. > > During the testing, all other virtual servers were DISABLED except for > the one being tested. This was to ensure that nothing would interfere > with the application. > > First framework tested: > Name: web2py > Configuration > ------------------- > db: DAL > cron: disabled > app: compiled > cache: none > pool_size: 10 > > The end result was about 68% throughput. There were 32% 500 internal > server errors. Error logs reveal IOErrors and the such as has been > duly noted in my previous google group posts. > > Second framework: > name: Flask / werkzeug > Configuration > -------------------- > db: sqlalchemy > cron: n/a > app: python source > cache: none > pool_size: 10 > > The end result was 100% throughput, no 500 internal server errors, no > error logs. > > -- > Thadeus > > On Thu, Jul 8, 2010 at 7:56 AM, Kuba Kucharski <kuba.kuchar...@gmail.com> > wrote: > >> What could it be? > > let's rule things out > > >> - cron when it runs spikes CPU usage. DO NOT USE. In production run > > not the case. no cron, no cpu spikes > > >> - web2py session lock (the the same user can only access one page at > > I have session.forget.. > > >> - sqlite lock (depending on the query and the complexity of > > not the case, I use mysql now > > >> - db connection pooling locks (when look up for open connection) > > > how to check this? I even did pool_size=10 but I never have more than > > 3 users at once I think > > it does not help > > >> - cache locks (it is a global lock, to ensure data integrity) > > how to debug this? > > >> - cache.ram can cause memory leaks if the key depends on variables > > no memory leaks noticed > > >> - problem with web server (Rocket or the apache or mod_wsgi, etc.) > > I use Rocket now, I don't know when I will be able to migrate to wsgi, > > probably soon
