<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 12:50 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
This is one of the reasons to get the wsgi stack off of eventlet and<br>
into a real webserver, as they handle HTTP request backups much much better.<br>
<br></blockquote><div><br></div><div>To some extent I think this is generally true for *many* common workloads, but the specifics depend *a lot* on the application under the webserver that's servicing those requests.</div><div><br></div><div>I'm not entirely sure what you have in mind, and may be mistaken to assume this is a reference to Apache/mod_wsgi?  If that's the case, depending on how you configure it - aren't you still going to end up with an instance of the wsgi application per worker-process and have the same front of line queueing issue unless you increase workers?  Maybe if the application is thread-safe you can use os thread workers - and preemptive interruption for the GIL is more attractive for the application than eventlet's cooperative interruption.  Either-way, it's not obvious that has a big impact on the memory footprint issue (assume the issue is memory growth in the application and not specifically eventlet.wsgi.server).  But you may have more relevant experience than I do - happy to be enlightened!</div><div><br></div><div>Thanks,</div><div><br></div><div>-Clay</div></div></div></div>