Do Google App Engine charge my application for this action?

127 views
Skip to first unread message

Hung Ha

unread,
Jan 18, 2016, 8:22:50 AM1/18/16
to Google App Engine

I am building a Java chat app based on App Engine platform. The app will not store data into database but in a public static variable.

Ok, Now, here is the logic

A user can enter chat.html & post messages to server and the messages will be stored inside a ConcurrentHashMap<User, List<String>

Then chat.html will have a checkLatestMsg() function that runs every 3 secs. Thus function will read the ConcurrentHashMap<User, List<String> &

for(String s: list){
    if(s!=null && "".equals(s)){
        resp.setContentType("text/plain;charset=utf-8");
        resp.getWriter().println(s);
    }
  }

So the resp.getWriter().println(s); won't show anything the list has no data. My question is that:

Will Google count the number of call requests?

What if we send a request but resp.getWriter().println(s); shows nothing, then will Google count that call?

The Quota pages tell nothing about this: https://cloud.google.com/appengine/docs/quotas

Could you clarify it?

Nicholas (Google Cloud Support)

unread,
Jan 18, 2016, 11:48:52 AM1/18/16
to Google App Engine
Thank you for posting some of your sample code here for your chat project. Without having the complete picture, I have assume the following about the contents and behavior of your application:
  • chat.html is the chat application's front-end for the user to interact with other users
  • The front end checks for chat updates every 3 seconds presumably by refreshing the page (essentially issuing an HTTP GET requests to a given URL), or by using Javascript's XMLHttpRequest towards said URL.
  • The code snippet above resides in the App Engine HttpServlet responding so above-mentioned URLs.
  • The application does not store any data elsewhere, or make any URL requests and simply responses to requests sent to it.
Assuming the above, the 'Requests' quota section and 'Instance hours' quota section should help in identifying the quotas your application will encounter. Instance hours accumulate during application operation as described in said article. Regarding requests, usage is accrued based on the quantity of data transferred, not how many requests are in fact made. Therefore, every request sent to the application counts as towards 'Inbound Bandwidth'. Every response counts towards 'Outbound Bandwidth' regardless of the content. Note that printing an empty string to the HttpServletResponse only sets the message body to a zero-length string. The message will still contain all the expected HTTP headers and be sent in response by the application.

I hope this answers your questions.

Nick

unread,
Jan 18, 2016, 3:04:17 PM1/18/16
to Google App Engine
Unfortunately, the implementation you describe is completely unsuitable for appengine.

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.

Alex Martelli

unread,
Jan 18, 2016, 3:19:26 PM1/18/16
to google-a...@googlegroups.com
On Mon, Jan 18, 2016 at 12:04 PM, Nick <naok...@gmail.com> 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 google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
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.

Reply all
Reply to author
Forward
0 new messages