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 >
