Re: unnecessary processes spawn during large POST's
Igor <[email protected]>
| Newsgroups | gmane.comp.web.fastcgi.devel,gmane.spam.detected |
|---|---|
| Message-ID | <[email protected]> |
Hello IR, Tuesday, July 3, 2007, 6:12:13 PM, you wrote: > In a Django / python app for uploading files I am experiencing the problem of unnecessary processes being spawn every 3 seconds during these large POST's. I believe I am experiencing the same problem as I found this old thread which http://www.fastcgi.com/archives/fastcgi-developers/2004-January/003206.html The proposed solution, writing the Content-type and flushing this before the POST is completely received does not work for me. It might somehow be related to: -flush (none) Force a write to the client as data is received from the application. By default, mod_fastcgi buffers data in order to free the application as quickly as possible. -startDelay n (3 seconds) The number of seconds the web server waits patiently while trying to connect to a dynamic FastCGI application. If the interval expires, the process manager is notified with hope it will start another instance of the application. The startDelay must be less than appConnTimeout to be effective. FastCGI is rarely used to upload/download files. In this particular job it is less effective than CGI. You gain nothing except a doubtful advantage given to you by the fast-cgi process manager. That case opens the whole new view why POST requests are banned on servers and what is the disadvantage of non-caching web servers working with POST requests.... POST is difficult. > Has there been any other solutions invented in the meantime? And could one explain exactly why these processes get launched every three seconds? And what they are supposed to do? Why is it not sufficient to start only *one* extra process when it thinks another process hangs? Also I suspect that if I use the singleThreshold 1 setting, only one user per time can request a page. So if the first user is uploading a large file, a second user cannot see the homepage (gets a 500 error instead). Am I correct in this assumption? ----------------------------- -- www.rol.ru Best regards, Igor mailto:[email protected] ___________________________________ fastcgi-developers mailing list http://fastcgi.com/fastcgi-developers/