These are all very relevant points for application design, but don't particularly impact the proposed pricing changes... these are the same limitations we have to live with today.
FWIW, Similarity does frequently load 50+ entities at a time (say, one set of match results) each of which is a hefty structure that could theoretically be up to the 1M limit in size... but in practice, they're not likely to be more than a couple K. The chance of blowing the heap is finite but very, very low. You're absolutely right, memory consumption goes up with concurrency, and the multithreading option is new, and the scheduler is still being tuned... this is just something to keep an eye on. Jeff On Tue, May 31, 2011 at 1:15 PM, Ugorji <[email protected]> wrote: > I agree that RAM for front end instances *should* not be particularly > relevant. And RAM *should* really only be relevant for backend instances. > However, RAM becomes more relevant as we try to push up the number of > parallel requests that can be handled by a single instance. For example, > suppose for each request, you pull out from memcache a bunch of data, and > crunch and filter through them in-process and then return a response. Assume > each request works on say 2MB of transient RAM (to be garbage-collected > later). In this situation, the number of parallel requests can be limited by > the RAM available for each process ie at n parallel requests, you can be at > 20% CPU utilization but start getting java OutOfMemoryErrors (for example). > [IIRC, you mentioned that in similarity.com, you store some serialized data > structures in the datastore, and pull out of the datastore a batch of > entities and do crunching in-process for some requests] > In most current single-threaded GAE instances, this is not an issue. But it > will become more an issue once we start doing parallel requests more on > GAE. > One way to architect around it is to do a lot of this type of work on the > backend. But even an option like that may be un-natural to your > architecture, and the cost of the backend instances make them very > unattractive. > With everything else, I completely agree. It's hard to discuss datastore > operations, since Google has been vague about what an operation encompasses > (is it dependent on size of the returned result set as Greg alluded to, or > does it map linearly to a single API call as some docs allude to). Without > getting into assumptions, it's a wait-and-see. > > -- > 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.
