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.
