On Thu, Aug 9, 2012 at 3:40 PM, Jeff Schnitzer <j...@infohazard.org> wrote:
> 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. > I was just nitpicking because I thought "with a concurrency of 1" applied to "Node.js servers" and not "the tests I ran", sorry for the missunderstanding. > Jeff > > On Thu, Aug 9, 2012 at 3:31 AM, Johan Euphrosine <pro...@google.com> > wrote: > > > > > > > > On Thu, Aug 9, 2012 at 7:16 AM, Jeff Schnitzer <j...@infohazard.org> > wrote: > >> > >> On Wed, Aug 8, 2012 at 5:44 PM, Waleed Abdulla <wal...@ninua.com> > 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 google-appengine@googlegroups.com. > >> To unsubscribe from this group, send email to > >> google-appengine+unsubscr...@googlegroups.com. > >> 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 google-appengine@googlegroups.com. > > To unsubscribe from this group, send email to > > google-appengine+unsubscr...@googlegroups.com. > > 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 google-appengine@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > 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 google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
