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 >
