I think I mentioned this before, but there is no I/O in the problem. It just collects data in RAM (thousands of individual submissions) and waits for the reaper come get the entire set in one fetch. This is why I do not expect concurrency to help.
Jeff On Thu, Aug 9, 2012 at 3:31 AM, Johan Euphrosine <[email protected]> wrote: > > > > On Thu, Aug 9, 2012 at 7:16 AM, Jeff Schnitzer <[email protected]> wrote: >> >> On Wed, Aug 8, 2012 at 5:44 PM, Waleed Abdulla <[email protected]> wrote: >> > Thanks, Jeff. Is it possible to repeat the test with qps < 10 to rule >> > out >> > the limit that Johan pointed out? In other words, how big is the >> > performance >> > difference if you had less requests that do more work? >> >> You must mean concurrency less than 10? >> >> I'm not really certain how concurrency relates to this. All the tests >> I ran (Node.js, Twisted, Tornado, Simple) were nonblocking servers >> with a concurrency of 1. > > > <nitpick> > Actually those server/framework do support processing multiple request > concurrently, when one of the request handler/callback is doing I/O it can > process another request. (Just like the go backend I tested) > They just don't do parallelism (by default). > </nitpick> > >> >> Maybe - just maybe - it would be possible to >> increase throughput by using multiple system threads up to the number >> of cores available... but then you would lose performance due to >> synchronization. Probably significantly. Optimal hardware >> utilization is one isolated, single-threaded, nonblocking server per >> core. >> >> I really don't know why backends are slow. Maybe it has something to >> do with the request queueing system? Throughput sucks even when >> backends are doing noops. Maybe "increased concurrency" would allow >> more requests to travel through the queueing system at once... but >> it's hard to imagine this helping out the actual server process at >> all. > > > Increasing concurrency could help if you are I/O bound, but it will not help > if you are truly CPU bound. > > For a truly cpu-bound request, you are using as much cpu as the instance > class limit allows for all backends < B8, and half of the CPU limit for B8. > So with threadsafe: true, you can only process: > - 1 cpu bound request at a time on B1 B2 B4 > - 2 cpu bound request at a time on B8 > > If you are not completely CPU bound and idling between CPU burst then > increasing concurrency would help, just like if you were bound on I/O > operations. > > Hope that clarify the situation a bit. > >> >> More timeslicing and synchronization on a cpu- and memory-bound >> problem will reduce performance, not improve it. >> >> Jeff >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" 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/google-appengine?hl=en. >> > > > > -- > Johan Euphrosine (proppy) > Developer Programs Engineer > Google Developer Relations > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" 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/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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/google-appengine?hl=en.
