A couple quick notes... I can verify Brandon's post about high throughput apps having extreme performance, while low throughput, test apps don't scale up very well. There is a learning algorithm at play, which favors production apps over test apps. Go figure ;-}
" I might expect better results if 'ab' isn't competing with node for CPU resources. The only practical difference of moving 'ab' off localhost is whether the network card driver on the VPS server is dramatically less efficient than the loopback driver. " - Comparing anything against lo is apples to oranges. In regard to having all clients hit the server at the same time, you could probably ramp QPS way up by having each clients results stored into a concurrent queue in ram, aggregate 25 units per entity and perform either DS or cache puts asynchronously in batches (first batch ten, subsequent batches 25), such that each client request just pushes to RAM and gets out to free up the request handler, and have a single thread asynchronously streaming results into DS. I've found with all performance tuning, having each request lock individually on appengine services leads to poor and choppy performance, while running using a single thread to mass push entities from shared concurrent queues using asynch batch puts results in extreme performance. Also, using known string keys is far, far better than having appengine generate long keys one at a time for your app. If you can't possible generate a UUID from your data, at least lease big batches of keys to reduce bottlenecks. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/Sv2gm6_pzkEJ. 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.
