On Mon, Nov 14, 2011 at 12:19 PM, Pol <p...@everpix.net> wrote: > > But note that concurrent requests will *not* improve the utilization > > of CPU-bound requests. Running multiple threads on the same CPU just > > proportionally slows each thread down. > > That doesn't make sense: apps do a mix of CPU stuff and RPC stuff (and > possibly URL requests). What's the points of concurrent requests if it > slows down the CPU stuff while allowing to parallelize your RPC calls? > The end result will be the same number of instance as requests end up > taking longer. Isn't the scheduler supposed to watch all this and > ensure the CPU on each physical machine is not saturated? > > Only apps that do long poll URL requests and barely use the CPU would > benefit of concurrent requests then. >
The vast majority of web applications (on any platform) spend the majority of their time blocked waiting for I/O. It's usually an order of magnitude difference - and this isn't long polling, it's just normal database access and whatnot. It sounds like your bcrypt library is intolerably slow in python, which creates a rare CPU bound situation. Either decrement the number of rounds or consider more efficient but still reasonably secure alternatives in this thread: http://stackoverflow.com/questions/7027196/how-can-i-use-bcrypt-scrypt-on-appengine-for-python Also, I +1 Nick's comment about DON'T roll your own. There are plenty of off-the-shelf options written by people who have spent significant portions of their educated life thinking about this problem. 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.
