How does Google App Engine Instance hours counted in this particular situation?

[Hung Ha]

I got an app built on top of App Engine.

We got a User class and many other classes as well. When user loged in.

How Google count the Instance hours when I do the following:

User user=request.getParameter("user");

I also have public static variable to hold chat messages & that could be called every 5 seconds if a user enter chat room (note: if many users enter the chat room then that variable could be called many times every 5 seconds), as the following:

public static Map<User, ConcurrentHashMap<User, CopyOnWriteArrayList<String>>> chatRoomConcurrentMap=new ConcurrentHashMap<User, ConcurrentHashMap<User, CopyOnWriteArrayList<String>>>();

If that is the case then how Google count the instance hours of that static variable?

SO, How does Google count instance hour when we instantiate an object and when we call a public variable?

[Nicholas (Google Cloud Support)]

Instance hours are determined by how long an App Engine instance is running. What the instance does while running only affects instance hours if it takes a long time to execute its code, thus extending how long it is operational.

Assuming 'request' is the parameter provided to the servlet method of type HttpServletRequest, this data resides in memory while responding to the request and thus does not require any additional external resources. The same can be said about chatRoomConcurrentMap. Neither of these should affect instance hours.

I must point out that this architecture requires that only a single instance be run and that it be running uninterrupted at all times. If requests to this application get low enough in frequency and have enough time between them, the instance may shut down to save on operation only to spin up later. When this occurs, variables instantiated in the first instance will be lost and therefore, not reachable by the next instance. In addition, if the maximum number of instances is not capped at 1 in your appengine-web.xml, additional instances may spin up with an influx a requests. In these situations, the variables from one instance will not be available to other instances.

If you need this application to scale with demand, you would need to separate your application state (chatroom messages and present users) from the request-handling runtime. I would consider using Datastore or Cloud SQL to store chat messages and memcache in the middle to mostly reduce data retrieval costs. More real-time (low-latency) and scalable solutions could employ Managed VMs. An example of a chat service over websockets can be found at the bottom of the previously linked page.