I would suggest the following: 1. Store your "compiled" structure in the datastore. This way, even if you loose it from instance memory or memcached, you can quickly reload it without doing the expensive calculations. One of the concepts in GAE Datastore is that you don't have to store data in normalized form, but rather in a form that would help fast reads and serving to clients. 2. In addition to storing the structure in the datastore, cache it using Memcached. This way all 3 instances see the same data structure. 3. Depending on your requirements you can update the cache using either lazy-loading or active approach. Lazy loading would mean that if a client request comes in and you don't find the structure in memcached, you load it from datastore and update in cache. This should be fairly quickly as you don't do the actual calculation of the structure at this point. The "active" approach would mean that you keep the structure in the cache, regardless of client requests. For instance you could schedule a cron job to run every minute that would read the structure from the datastore and put it in the cache. This would minimize the chances of your data not being in memcached (and if that happens you should fall back to lazy loading).
Thoughts? Hope it helps. Regards, Michael Weinberg On Jan 12, 4:16 pm, "[email protected]" <[email protected]> wrote: > I've got an application that works as follows. > > The main thing it does is handle user request. Handling a user > request entails doing a bunch of processing, then finally returning > the result to the user. It is important that the total time to > process a user request be as small as possible. > > There is also a configuration interface used by admins. The admin can > make a change to configuration that affects what processing is done on > user requests as described above. The information in stored in the > config database has to be "compiled" into fairly elaborate in-memory > structure that handles the user request processing; computing this in- > memory structure from the configuration info takes time (much longer > than processing a user request). > > It is a goal that the time to "compile" the configuration info into > the in-memory structure *not* be on the critical path of processing a > user request. > > Here's the problem. When the admin changes the config info, it's easy > enough to update the in-memory structure for the instance that > happened to process the admin's request. But in order to avoid start- > up latency in processing user requests, I've got three "always on" > instances (which is the minimum number of always on instances -- you > can't ask for just one). How can I get the other instances to realize > that the config has changed and that their in-memory structure needs > to be recalculated? > > Non-solution: on each user request, check the database to see if the > config has changed. This is not acceptable, because if the database > *has* changed then that user request will incur the latency to update > the in-memory structure. > > Non-solution: just like the previous non-solution, but use a > memcache. I believe this has the same latency problem, just delayed > until after the memcache entry expires. > > Lousy solution: redeploy the app after a config change. That works > because it restarts all instances, but it defeats the purpose of > making the config something that can be changed by an admin through UI > screens rather than wired into the code. > > If I could direct a request to *all* deployed instances (or, > equivalently, to a specific instance coupled with the ability to > enumerate all of the instance IDs), then it would be easy for me to > "kick" each instance after the config change. But as far as I know, > there's no way to do that. > > I'm sure others have encountered a similar scenario. Any suggestions? > > Thanks in advance. > > Ken Traub -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" 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-java?hl=en.
