<div dir="ltr">inline:<div><br><div class="gmail_quote">On Sun, Mar 14, 2010 at 3:54 PM, Peter Portante <span dir="ltr"><<a href="mailto:peter.a.portante@gmail.com" target="_blank">peter.a.portante@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
<font face="Verdana, Helvetica, Arial">On 3/14/10 7:31 AM, "Nir Aides" <<a href="http://nir@winpdb.org" target="_blank">nir@winpdb.org</a>> wrote:<br><br>
</font><blockquote><font face="Verdana, Helvetica, Arial">There are two possible problems with Dave's benchmark:<br><br>
1) On my system setting TCP_NODELAY option on the accepted server socket changes results dramatically.<br>
</font></blockquote></div><font face="Verdana, Helvetica, Arial"><font color="#FF0000">Could you document what you saw and explain how you think TCP_NODELAY makes a difference, including what kind of system you ran your tests and what the application was that demonstrates those dramatic results?<br>
</font></font></div></blockquote><div><br></div><div>I first disabled the call to spin() but client running time remained around 30 seconds. </div><div>I then added TCP_NODELAY and running time dropped to a few dozen milliseconds for the entire no-spin run.</div>
<div>The system is Ubuntu Karmic 64bit with latest revision of python 3.2.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><blockquote>
<font face="Verdana, Helvetica, Arial">2) What category of socket servers is dave's spin() function intended to simulate?<br>
</font></blockquote></div><font face="Verdana, Helvetica, Arial"><font color="#FF0000">What is the problem you are trying to get at with this question?<br><br>
Does Dave’ spin() function have to have a category? Or perhaps the question is, for these solutions, what category of application do they hurt? Perhaps we can look at the solutions as general, but consider their impact in various categories.<br>
</font></font></div></blockquote><div><br></div><div>In Dave's code sample, spin() is loading the CPU regardless of requests. This may demonstrate how short IO bound requests will behave while the server is processing a long Python-algorithmic CPU intensive request, or an ongoing CPU intensive task unrelated to incoming requests. However is this typical for socket servers?</div>
<div><br></div><div>If you change the sample server code to start a CPU bound thread with work X for each incoming request you will see different behavior.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><blockquote><span style="font-family:Verdana, Helvetica, Arial">There is still the question of latency - a single request which takes long time to process will affect the latency of other "small" requests. However, it can be argued if such a scenario is practical, or if modifying the GIL is the solution.</span></blockquote>
</div><font face="Verdana, Helvetica, Arial"><font color="#FF0000">Perhaps Dave already documented this effect in his visualizations, no?<br></font></font></div></blockquote><div><br></div><div>Naturally. I did not imply otherwise. His analysis is brilliant.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><blockquote><font face="Verdana, Helvetica, Arial">If a change is still required, then I vote for the simpler approach - that of having a special macro for socket code.<br>
</font></blockquote></div><font face="Verdana, Helvetica, Arial"><font color="#FF0000">What is that simpler approach? How would that special macro work?<br></font></font></div></blockquote><div><br></div><div>The special macro for socket code is one of the alternatives proposed by Antoine above.</div>
<div><br></div><div>However, thinking about it again, with this approach as soon as the new incoming request tries to read a file, query the DB, decompress some data or do anything which releases the GIL, it goes back to square one. no?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><blockquote><font face="Verdana, Helvetica, Arial">I remember there was reluctance in the past to repeat the OS scheduling functionality and for a good reason.<br>
</font></blockquote></div><font face="Verdana, Helvetica, Arial"><font color="#FF0000"><br>
In what ways do we consider the CPython interpreter to be different than another application that has multiple threads and contention for one resource? Perhaps we have a unique problem among all other user space applications. Perhaps we don’t.<br>
</font></font></div></blockquote><div><br></div><div>I think a rule of thumb is to protect a resource (typically a data structure), as tightly as possible, avoiding for example locking across function calls, etc, if possible. In contrast CPython is "locked" the entire time.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><font face="Verdana, Helvetica, Arial"><font color="#FF0000">As for the behavior of the GIL, how are the proposed solutions repeating OS scheduling functionality? </font></font></div>
</blockquote><div><br></div><div>Dave discussed this in his analysis. </div><div><br></div><div>Nir</div><div><br></div><div><br></div><div><br></div><div> </div></div></div></div>