I didn't see anything restrictive about the original worker settings that would cause process churn and thus interruption of connections. I will think some more about it though.
I would though suggest you watch: http://lanyrd.com/2013/pycon/scdyzk/ as I talk about that in how to set the MPM settings. Graham On 22/07/2013, at 10:21 PM, Tera Byte <[email protected]> wrote: > Hello Graham, > > I have some (good) news for you. I didn't kept you promptly updated because I > wanted to test something in this Monday morning in another environment. > > The MPM settings I posted before are obviously low. These are the settings we > use in a controlled testing/pilot environment and until know every > application we served didn't show any problems using these low settings. This > is the first application we deployed in this server that required very long > lived connections (large media streaming). > > As soon as we raised the Apache MPM settings up (we tried with the settings > you provided as a starting reference) everything worked flawlessly. > > I wanted to ask you something since your Apache HTTP knowledge is for sure > far greater that ours: Why is this phenomenon happening? Maybe because our > settings were so low that when Apache needed to create new child processes - > and there was no available process - it would terminate an existing one > "randomly" (ex: the long running process that was serving the media > streaming)? > > Thank you > > On Monday, July 22, 2013 1:52:02 AM UTC+1, Graham Dumpleton wrote: > Can you clarify one point? > > In the instances where this is occurring, is the client always within your > own network, ie., during testing, or is out on the wider Internet. Also, is > the connection coming over HTTPS or a plain HTTP connection. > > That you said that this occurs in embedded mode, still suggests to me that is > an issue occurring between the server and the client. > > Graham > > On 20/07/2013, at 8:50 AM, Tera Byte <[email protected]> wrote: > >> We are in a kind of pilot / tech. evaluation phase so the settings are >> somewhat kind of low: >> >> <IfModule mpm_worker_module> >> StartServers 1 >> MinSpareThreads 5 >> MaxSpareThreads 10 >> ThreadsPerChild 10 >> MaxRequestWorkers 40 >> MaxConnectionsPerChild 0 >> </IfModule> >> >> On Friday, July 19, 2013 11:45:44 PM UTC+1, Graham Dumpleton wrote: >> What do you have for the MPM settings in Apache for worker MPM? >> >> <IfModule mpm_worker_module> >> StartServers 2 >> MaxClients 150 >> MinSpareThreads 25 >> MaxSpareThreads 75 >> ThreadsPerChild 25 >> MaxRequestsPerChild 0 >> </IfModule> >> >> Graham >> >> On 20/07/2013, at 8:25 AM, Tera Byte <[email protected]> wrote: >> >>> Another detail: >>> We are also running mod_jk as our load balancer to Java based application >>> servers. plus mod_ssl. >>> >>> >>> On Friday, July 19, 2013 11:19:37 PM UTC+1, Tera Byte wrote: >>> Hello Graham, >>> >>> Completely forgot to mention those important details. Sorry about that. >>> >>> We are running worker MPM (multi-threaded). We also tried refining the >>> apache log level since we read about that recommendation in other posts. We >>> set the level to trace and observed no additional details about the error. >>> Only the "IOError: failed to write data" message and nothing more. >>> >>> Thank you >>> >>> On Friday, July 19, 2013 10:44:18 PM UTC+1, Graham Dumpleton wrote: >>> What Apache MPM are you using and what are the MPM settings? >>> >>> What else are you running on this Apache server. >>> >>> When using daemon mode this error can also be due to the Apache child >>> worker processes that are proxying requests to the daemon processes being >>> killed off. >>> >>> Make sure you have LogLevel set to info in Apache and see what messages >>> Apache/mod_wsgi is producing when it occurs beyond just the IOError details. >>> >>> Graham >>> >>> On 20/07/2013, at 5:26 AM, Tera Byte <[email protected]> wrote: >>> >>>> Hello, >>>> >>>> I have seen this question asked at least another time here at modwsgi >>>> group but it looks like there is no concrete answer until now (?). >>>> >>>> I'm streaming quite large media files from django + mod_wsgi but the >>>> streaming terminates abruptly in an almost randomly fashion. The file in >>>> question is about 600MB and the streaming usually terminates between 150 >>>> or 200MB streaming progress. >>>> >>>> The error message that is written into the log files is the famous >>>> "IOError: failed to write data". Nothing more is written even if I refine >>>> the log level. >>>> >>>> The django application when deployed in the development server works >>>> flawlessly. But when deployed in Apache together with mod_wsgi causes the >>>> problem. >>>> >>>> I'm running mod_wsgi in "daemon process mode". The server has 4GB of total >>>> RAM, being 3GB available during the test scenario I have isolated. >>>> >>>> The django application is returning an iterator like the following, where >>>> data is a urllib2 data stream: >>>> >>>> class FileIterWrapper(object): >>>> def __init__(self, data): >>>> self.data = data >>>> self.chunk_size = 4096 >>>> >>>> def next(self): >>>> data_block = self.data.read(self.chunk_size) >>>> if len(data_block) == 0: >>>> raise StopIteration >>>> else: >>>> return data_block >>>> >>>> def __iter__(self): >>>> return self >>>> >>>> >>>> I really need help with this one. The streaming component of the overall >>>> application could be easily migrated to another technology / application >>>> server but the goal is to stick all with django and mod_wsgi. >>>> >>>> Any pointers? >>>> >>>> Thank you >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "modwsgi" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/modwsgi. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
