On 14 May 2010 04:35, Deron Meranda <[email protected]> wrote: >> ...From the client's POV - verified with strace >> - the POST request went out at 11:16:10, and the response was received >> at 11:16:21. > ... >> 21827 11:16:10.042475 connect(12, {sa_family=AF_FILE, path="/var/run/ > apache2/wsgi.11746.39.2.sock"}, 110) = 0 > ... >> 21827 11:16:10.124810 shutdown(12, 1 /* send */) = 0 >> 21827 11:16:10.124930 read(12, <unfinished ...> >> 21827 11:16:21.917191 <... read resumed> "Status: 200 OK\r\nVary: >> Cookie, Us"..., 8000) = 2125 >> >> Due to the successful shutdown(), I would expect the client to receive >> the response at that time, but as mentioned, it doesn't receive it >> until the follow-on read unblocks. > > > The shutdown() is called with SHUT_WR (1), which means that > there is a socket half-close situation. This prevents additional > data from being sent by Apache to the wsgi process. However > it has no effect on the reading of data in the other direction. > > Generally the shutdown acts like an end-of-file marker, > it shouldn't affect the delivery of packets or their timing. > A pattern of using half-closes is not unusual and shouldn't > cause any unexplained delays; though it may require somebody > with more modwsgi internals knowledge to answer definitively.
Your analysis is correct. The Apache server process which proxies data to the mod_wsgi daemon process closes that half of the socket connection after it has been able to send all the request content. This informs the mod_wsgi daemon process that there is no more request content. This method is used because you cant rely on request content length as Apache input filters can invalidate that and there may actually be more or less data to process than content length defines. Technically WSGI compliant applications can't handle that, but step outside of WSGI and you can handle it with mod_wsgi. My separate questions were to determine if there was a delay in sending that data what cause may be, but was irrelevant any way as the logs clearing showed the close happening promptly, which means that web application did promptly read and store all the request content. As a result, the delay can only be occurring within the processing done within the web application of that request data once it has been read. Thus, what is the target of the POST doing with that data, is it just storing it as a attachment, or is it going into some special wiki handler which processes the data or uses it in some database transaction? To validate that it is the web application itself which is blocking or taking time, can only suggest to use variants of code recipes in: http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode#Cleanup_At_End_Of_Request augmenting them to log time at start of request, when application first returns and when all response data is sent. This will give you timings to confirm how long application itself too to handle request. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
