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.
