Well, I wouldn't know if leaving sockets open for such a high concurrency is enough to change, but cherrypy is definitely more active. When Tim rejoins we could switch back as soon as the bugs are fixed. @mic: is there really an alternative to cherrypy.wsgiserver (multiplatform, pure python, SSL support, rock solid thread-enabled uwsgi server)?
Il giorno venerdì 28 settembre 2012 11:57:59 UTC+2, Michele Comitini ha scritto: > > If we have to change, could we come up with a list of good candidates, > including cherrypy, and have a voting session? > > mic > > > > 2012/9/27 Massimo Di Pierro <[email protected] <javascript:>> > >> Tim, creator or Rocket has not been very responsive recently. Should we >> revert to cherrypy wsgiserver? >> >> >> On Wednesday, 26 September 2012 18:18:28 UTC-5, Michele Comitini wrote: >> >>> I confirm that is a rocket issue. After a while it starts leaving CLOSE >>> WAIT sockets around until consuming all available file handles. >>> >>> mic >>> >>> 2012/9/27 Niphlod <[email protected]> >>> >>> >>>> On Thursday, September 27, 2012 12:20:03 AM UTC+2, Massimo Di Pierro >>>> wrote: >>>>> >>>>> Are you telling us that under heavy load, trying to generate a new >>>>> session_id at every request using the os entropy generator >>>>> (/dev/urandom), >>>>> results in too many files open, causes tickets, and this produces the >>>>> apparent slow down? >>>>> >>>>> What do you suggest? >>>>> >>>>> >>>> this is not the case within uwsgi....no errors show up. For production >>>> sites handling a lot concurrent requests rocket is not recommended. >>>> >>>> Commenting out the part generating request.uuid on main.py was part of >>>> "the hack" for case 5). Just commenting that turned out in a ~50 reqs/sec >>>> more capability. The big "speed bump" (~400 reqs/sec more) is removing all >>>> the session logic. >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> >>> >>> -- >> >> >> >> > > --
