On Mon, Jan 18, 2016 at 12:04 PM, Nick <[email protected]> wrote: > Unfortunately, the implementation you describe is completely unsuitable > for appengine. >
I have to concur with Nick here. Number one issue is that the default scaling approach for Google App Engine is "autoscaling": as more users send requests, App Engine spins up entirely new instances -- which do NOT share the memory of instances currently running. For instances to share any state, that state must be stored in explicitly-shared subsystems, primarily the datastore (memcache can help, but its contents are not guaranteed to persist -- thus, it's best to think of it as just a performance helper... it should never be a core aspect of an application's semantics). Manually scaled modules offer a way for your application to control exactly how many instances of a module are running at any given time. However, while this can be very helpful in the right circumstances, it won't help enough with your state-in-memory overall architecture -- if you ever need more than one instance to keep up with the load of user requests, how are you going to ensure that users who want to chat with each other connect to the *same* instance every time? Other platforms such as Google Compute Engine, and our competitors' offerings, also can't help with the core issue underlying all of this: an architecture based on keeping crucial state in memory can only scale up to the number of requests that can be served by a single instance -- and that's WAY too limiting for any application that doesn't have some unusually tiny limit on the number of requests it can serve at any one time. My recommendation is to reconsider your approach to sharing state, so that multiple instances can be accommodated more smoothly than with a "state is in memory" architecture. Once you've done that, then App Engine (or other solutions, such as ones based on Compute Engine or Kubernetes/GKE) can be considered and might offer the best approach for you. Alex > Appengine is designed specifically to make developers think about and > build distributed systems, and what you describe isn't distributed at all. > > You should choose another platform (assuming you need to host this in the > cloud), you will save yourself trouble. If you're keen to use appengine, > you need to do more reading and experimentation, until you have a firm > grasp of its strengths and weaknesses. What you described will not, in the > general sense, work. > > To answer you question directly, all requests will count against your > quota but the application you describe will probably never go over the free > tier. So don't worry about it. > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/google-appengine. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-appengine/9baeba11-22f3-4542-9655-81ccf6d4e773%40googlegroups.com > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-appengine. To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/CAE46Be9c00OhUUAjcfT2_KjRsA5doEipTrfv0qDc4jj4S3hC-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
