I am taking http://techspot.zzzeek.org/?p=17 and making a benchmark_dal.py and testing the results vs sqlalchemy.
So far it looks promising, the DAL seems to be much more efficient than SQLAlchemy, and brick tons faster too. This is good news for me, as it proves that the DAL is valuable... if only we could make it its own package instead of apart of web2py... that will be my next project. Here I have attached to aggregate screenshots, and the file used to test DAL. I compared both SQLAlchemy and the DAL on my VPS server, each got their own postgresql database. I am using a slightly modified DAL (I removed validators completely). However, after I ran the tests I realized migrate was still set to True.... so If I were to re-run the tests I expect the DAL to outperform SQLAlchemy even more. Refer to the link at techspot.zzzeeek for more information about the tests. http://static.thadeusb.com/total_time.jpg http://static.thadeusb.com/call_count.jpg http://static.thadeusb.com/benchmark_dal.py I think it is safe to say that the DAL is not what is causing these 500 server errors. I think David is on to something. On my production sites, I always get errors related to the pages with SQLFORM on them, never on regular pages that just render a template. -- Thadeus On Mon, Jul 19, 2010 at 1:27 AM, David Marko <dma...@tiscali.cz> wrote: > I can see the same problems with failed requests on many my machines. > (WinXP, Debian 5) . The simple test using default web2py examples > shows me, that template rendering is OK > e.g. http://localhost:8000/examples/template_examples/test_for but > when using form example like in > http://localhost:8000/examples/form_examples/form > causes request failures. Constantly, when I did test repeatedly, > template rendering example caused no problem, but form based example > claimed 13-15% of failed requests for me. I have use apache ab. As > stated above, I could see the same results despite of platform. > > I tested today on latest version 1.81.4 with default Rocket web server. > (I remember I could see the same issues with CherryPy as well) > > David > > On 19 čnc, 06:22, Thadeus Burgess <thade...@thadeusb.com> wrote: > > I am wondering if this is a web2py issue or a DAL issue. > > > > I would like to re-run my tests just rendering a simple template with no > > dbio and see if I still get the same results. I love the DAL and there is > > nothing else quite like it, and would hate for it to be the cause. > > > > I would like to compare the DAL standalone, without web2py to determine > it > > is not the cause. > > > > -- > > Thadeus > > > > On Sun, Jul 18, 2010 at 6:10 PM, MikeEllis <michael.f.el...@gmail.com > >wrote: > > > > > > > > > I was just about to create new topic, but thought I'd start by > > > reporting here since it could be related. > > > > > The short description is: > > > > > 1. Serve web2py (rocket.py, sqlite3, etc) over a lan connection from a > > > laptop > > > 2. Open a page from my app on another laptop. > > > 3. Also open the same page on the server laptop. > > > 4. Start clicking reload alternately between the two laptops at about > > > 1Hz > > > 5. All goes well for an indeterminate period of time, typically about > > > 1 minute. > > > 6. Occasionally a reload will take about 20 seconds. Can happen on > > > either box. > > > > > Other Info > > > * db is very small - only 2 tables with only a few entries each. > > > * App is not doing anything intensive and the pages are relatively > > > simple. > > > * web2py 1.92 > > > * OS X 10.6 on both laptops > > > * Browser = Chrome > > > > > Observations > > > * No evidence of high CPU usage. > > > * Happens even with pages that don't write to the db. > > > * I even managed once to produce the problem with an unmodified > > > Welcome app, but it took a really long time to make it happen and the > > > latency wasn't as bad. > > > > > When I reproduce the problem with Chrome DevTools open, the delay > > > corresponds to an incredibly long latency, ie 20 seconds, fetching one > > > or more .js or .css modules. Usually it's jquery.timers-1.2.js or > > > base.css but can occur with other modules. It's never the page html, > > > that always arrives in milliseconds. > > > > > Here's the Header info from the long fetch on base.css: > > > > > Request URL:http://192.168.253.105:8000/init/static/base.css > > > Request Method:GET > > > Status Code:304 Not Modified > > > > > Request Headers > > > Accept:text/css,*/*;q=0.1 > > > Cache-Control:max-age=0 > > > If-Modified-Since:Mon, 14 Jun 2010 23:30:00 GMT > > > Referer:http://192.168.253.105:8000/init/editproblem/index > > > User-Agent:Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-US) > > > AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4 > > > > > Response Headers > > > Connection:keep-alive > > > Content-Type:text/html; charset=UTF-8 > > > Date:Sun, 18 Jul 2010 22:32:09 GMT > > > Server:Rocket 1.0.5 Python/2.6.1 > > > > > One other oddity: I've been seeing (and ignoring) the following > > > warning from DevTools when js/css files are loaded: > > > > > "Resource interpreted as stylesheet but transferred with MIME type > > > text/html." > > > > > Someone on stackoverflow.com suggested putting > > > > > <meta http-equiv="content-script-type" content="text/javascript"> > > > > > into the head of the document. I tried that (in layout.html) but it > > > had no effect on the warnings. > > > > > Anyone seen similar problems or have an idea what could be causing the > > > long fetch times? > > > > > Thanks, > > > Mike > > > > > On Jul 18, 1:20 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: > > > > Massimo, web2py.com is not a valid application to be testing this > on. > > > Most > > > > of what web2py.com does is just render a template and display it, it > > > hardly > > > > does any kind of strenuous dbio. > > > > > > As you know I have a few separate servers running different > > > configurations. > > > > > > I mainly decided to do this testing as to the problems I have had > with my > > > > application at work (which runs apache + mod_wsgi). I wondered if my > blog > > > > had the same issue (which when I ran ab tests on it and spiked its > usage, > > > it > > > > did). Interesting thing is my blog ran on cherokee + uwsgi. I doubt > it is > > > a > > > > configuration issue since I still have the same problem on two > completely > > > > different apps running completely different setups all different > except > > > > web2py. They both use postgres as well. > > > > > > I am attaching the two apps that I tested, as well as a text file > that > > > > contains the raw ab tests that I collected to run > > > > > > -- > > > > Thadeus > > > > > > On Sun, Jul 18, 2010 at 4:39 AM, mdipierro <mdipie...@cs.depaul.edu> > > > wrote: > > > > > Last week I run some tests. I can confirm I have NO dropped > requests > > > > > on web2py.com running with the recommended configuration (apache > > > > > +mod_wsgi 3.1). > > > > > > > Here is the httpserver.log for 3 days of running (I removed the IPs > > > > > from the logs and requests for static files served directly by > > > > > apache). > > > > > > > http://www.web2py.com/examples/static/logs.txt > > > > > > > You can see that most pages are served in about 50 millisecond and > all > > > > > of them return a 200 OK. > > > > > > > At 2010-07-08 16:58:22 I also run a test and you can see the logs > for > > > > > that. No propped request from ab. > > > > > > > Clearly something is wrong with Thadues setup. I cannot help debug > > > > > this if I cannot reproduce the problem. > > > > > As soon as I have some time I will install uwsgi and try it. > > > > > > > @Thadeus. Can you post the application you used for testing? > > > > > > > Massimo > > > > > > AB_WEB2PY_FLASK.tar.lzma > > > > 1011KViewDownload >
