Robin Haswell wrote: > I had big throughput problems with asyncore for non-trivial > applications. I was making an RSS aggregator and needed to pull in > lots of feeds at the same time to get the job done nearly as fast as > necessary. I found the overhead in parsing then storing the responses > caused my app to spend too long processing and not enough time reading > the buffer. The consequence was that there was lots of data waiting > for me on the socket which I couldn't read fast enough, causing the > socket to fill up and reject incoming packets. My throughput dropped > to 25% of my link bandwidth.
There are not really any fundamental throughput problems in asyncore or asynchat that I know of, other than the fact that they are a little hard to use at first. I suspect that you were putting long-running operations inside your event loop, slowing down your I/O. An approach that often works well for me is to allow asyncore to do all of its work inside its own thread, and queue up the long-running tasks into a Queue and process them from a separate thread. This works great for me, and still keeps things relatively simple. Asynchronous approaches are ideally suited for Comet applications, where request-per-thread and pre-forking solutions would fall down with a large number of active requests. Of course, YMMV :) -- Jonathan LaCour http://cleverdevil.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
