On May 10, 3:11 pm, Thadeus Burgess <[email protected]> wrote: > Looking at the sites analytics, there are roughly about 1000 requests > a day, of which I will receive 100 of these tickets, give or take 20.
If you want a quick solution, stick nginx in front as a proxy and you likely would eliminate the errors. This is because nginx helps to isolate you from slow clients and some of the problems they can cause. You can also offload static file serving to nginx as well, speeding that up and allowing you to use less resources in Apache to serve same number of requests. I'll comment later when have time on Massimo's comments. Graham > On Mon, May 10, 2010 at 12:10 AM, Thadeus Burgess <[email protected]> > wrote: > > What if there was an IO error with cgi.FieldStorage ? > > > -- > > Thadeus > > > On Mon, May 10, 2010 at 12:06 AM, mdipierro <[email protected]> wrote: > >> Yes. it is safe to ignore, but it still causes a minor slow down > >> because web2py issues a ticket and that may be unnecessary. > > >> On May 10, 12:01 am, Thadeus Burgess <[email protected]> wrote: > >>> So you are saying that a user with a slow connection (which consists > >>> of a large portion of the sites user base) clicks reload, so their > >>> browser stops communicating with that request, so web2py catches it as > >>> an IOError... so then is this safe to ignore? > > >>> Below is a log that I found in apache2.error.log > > >>> [Sun Jan 31 13:42:50 2010] [error] [client ******] (70007)The timeout > >>> specified has expired: mod_wsgi (pid=3961): Unable to get bucket > >>> brigade for request., referer:http://mysite.com/page1 > >>> [Sun Jan 31 13:42:51 2010] [error] [client ******] mod_wsgi > >>> (pid=3926): Exception occurred processing WSGI script > >>> '/web2py/wsgihandler.py'. > >>> [Sun Jan 31 13:42:51 2010] [error] [client ******] IOError: failed to > >>> write data > > >>> -- > >>> Thadeus > > >>> On Sun, May 9, 2010 at 11:52 PM, Graham Dumpleton > > >>> <[email protected]> wrote: > > >>> > On May 10, 1:51 pm, Thadeus Burgess <[email protected]> wrote: > >>> >> Ticket. I usually see them the next day when I check admin. > > >>> >> No, it is usually just one IP but it happens to a lot of people at the > >>> >> same time, scaled by the amount of traffic being put on the server. > > >>> > Then it is likely that the ISP or network all the requests were routed > >>> > by dropped all the connections for whatever reason. > > >>> >> Roughly about 10% of the requests generate this error. > > >>> >> > A user not waiting for a request to complete before clicking on > >>> >> > another link or pressing reload. In other words, client dropped > >>> >> > original connection. > > >>> >> Obviously this is a web2py issue then, because I don't have any > >>> >> problems when I go click-happy on other web sites. > > >>> > Part of the problem is that there is no standard for what type of > >>> > Python exception is generated by a dropped connection. The mod_python > >>> > and mod_wsgi package so happens to use IOError, but different > >>> > descriptions. Other WSGI servers are within their rights to use a > >>> > completely different Python exception or yet another description > >>> > against an IOError. Thus, it becomes really hard for a generic > >>> > framework that can be hosted in various ways to make a judgement as to > >>> > whether a failure on read was due to a particular type of error. Thus > >>> > it becomes hard to ignore errors for loss of connection. You also by > >>> > ignoring them, limit an applications ability to take some special > >>> > action when connections are dropped. > > >>> > It therefore isn't obvious what to do and most Python frameworks will > >>> > as a result just pass the exception up the stack and cause a 500 > >>> > response. If you have a mailout option for errors back to system > >>> > administrators then you obviously may get an lot of emails. Best you > >>> > might do is for that mailout middleware to allow a user to supply > >>> > their own rules, ie., exception types and desription regex, for things > >>> > that should be ignored as far as mailout message to admin. > > >>> > Graham > > >>> >> On Sun, May 9, 2010 at 9:55 PM, mdipierro <[email protected]> > >>> >> wrote: > >>> >> > ure about the problem but I had a few instances of people > >>> >> > clicking reload a lot (and I mean a lot). So I use thi
