CS6320:  SW Engineering of Web Based Systems

 

Google App Engine: Limits

******* see the following Google webpages for current limits:

Request Limits

  • APPLICATION RESPONSE TIME: An application has 60 seconds to respond to a user request.
    • Near the end of the 60 seconds, the server raises an exception that the application can
      catch for the purposes of exiting cleanly or returning a user-friendly error message.
    • Python: GAE throws google.appengine.runtime.DeadlineExceededError.
    • Java: GAE throws com.google.apphosting.api.DeadlineExceededException.
    • If the request handler has not returned a response or otherwise exited after 60 seconds,
      the server terminates the process and returns a generic system error (HTTP code 500)
      to the client.
    • applies to user web requests, as well as requests for web hooks such as incoming XMPP and email requests.


  • REQUEST HANDLER (invoked by task queue or scheduled task): max run for 10 minutes
  • SIZE OF REQUEST: max 10 megabytes
  • SIZE OF RESPONSE: max 10 megabytes
  • TASKQUES: 10 minutes

 

CPU Limits

  • CPU IS SHARED: CPU of any GAE server is shared by multiple request handlers running at the same time.
  • WHAT HAPPENS WHEN A CPU IS TOO BUSY: App Engine allocating more resources as needed, such as serving apps from alternate
    servers.
  • CPU TIME IS BILABLE $$$
    • to account for differences in CPU speed/characteristics --- App Engine measures CPU usage in "CPU minutes."
    • A CPU minute is the number of megacycles that can be performed by a standard processor in one minute. The standard processor changes --look at google for latest standard. If your app were running by itself on a single standard processor, it
      would do a CPU minute's worth of work in one clock minute. The actual amount ofclock time to perform that work can vary, depending on how App Engine allocates resources.



  • BAD APP (sucking up too much CPU time)-- THROTTLING YOUR APP MAY COST YOU TIME (and maybe $$ IN START AND STOP???):
    • App Engine tries to balance the load so each app gets a consistent rate of CPU attention.
    • If a request handler uses too much CPU time, the app server may throttle the allocation of CPU. In that case, the request handler consumes the same number of CPU minutes, but it takes more clock time to do it.


  • 2 KINDS OF CPU TIME
    • CPU time on app server
    • CPU time in the datastore.
    • NOTE: Other services do not contribute to the CPU time quota; they manage CPU resources in other ways. An app server does not consume CPU time while it is waiting for a service call to return.
      • Python tip: The Python runtime environment provides a function you can call to analyze the CPU
        usage in a request handler. The get_request_cpu_usage() function in the
        google.appengine.api.quota package returns the number of megacycles (not CPU minutes)
        used by the request handler so far. You can call this function before and after a
        calculation to determine how much CPU time the calculation used.




Service Limits

  • There are a slew of services (datastore, memcache, urlfetch, email, etc.)
  • Each service has its own set of quotas and limits.
  • Free account has minimal limits ---budget to raise. (# emails sent from app)
  • EXCEEDING Limits/quotas - get message
    • Python: the runtime environment raises a ...runtime.apiproxy_errors.OverQuotaError.
    • Java, throws a com.google.apphosting.api.ApiProxy.OverQuotaException (note the apphosting package name, not appengine).




  • MANY SERVICES HAVE LIMIT OF 1 MegaByte
    • RESULT: Even though an incoming user request can contain up to 10 megabytes, only 1 megabyte of that data can be stored using a single datastore entity or memcache value.
    • SOLUTIONS FOR A FEW POTENTIALLY DATA HEAVEY SERVICES:
      • DATASTORE (when you have more than 1 MegaByte): The datastore has a "batch" API that allows you to store or fetch multiple data objects in a single service call. The total size of a batch request to the datastore is unlimited: you can attempt to store or fetch as many entities as can be processed within an internal timing limit for datastore service calls. Each entity is still limited to 1 megabyte in size.
      • MEMCACHE: The memcache also has a batch API. The total size of the request of a batch call to the memcache, or its response, can be up to 32 megabytes. As with the datastore, each memcache value cannot exceed 1 megabyte in size.
      • URL FETCH: your app can use URL Fectch to connect to remote hosts using HTTP, can issue requests up to 1 megabyte, and receive responses up to 32 megabytes.

 

Go to Google to see latest limits and charges https://developers.google.com/appengine/docs/quotas

 

 

Deployment Limits

dealing with the app size itself

  • SIZE OF APPLICATION FILE = max 10 Megabytes (code and configuration and static files --everything)

  • TOTAL NUMBER OF FILES = maxium 3,000 (including resource and static files, all code)

  • TOTAL NUMBER TIMES CAN DEPLOY APP IN 1 DAY: An application can only be uploaded a limited number of times per day, currently 250. If you are using app deployments to upload data to the application on a regular schedule, you may want
    to keep this limit in mind.

When a problem === storing lots of user data, video, images, stuff to download. Or when you use a lot of frameworks (which have lots of files).

 

Solution   

  • PYTHON: you can store the code files in a ZIP archive file, then add the path to the ZIP archive to sys.path at the top of your request handler scripts. Thanks to zipimport, a feature built into Python, the Python interpreter will recognize the ZIP file automatically and
    unpack it as needed when importing modules. Unpacking takes additional CPU time($$), but since imports are cached, the app only incurs this cost the first time the module is imported in a given app instance
  • JAVA: Similarly creat jar files ---- If your app has too many .class files, simply put them in a JAR file using
    the jar utility included with the Java development kit. As with Python, app caching reduces the overhead of unpacking JARs. There is no equivalent to zipserve for static files in Java included with the SDK Also, with Java, make sure to use <static-files> and <resource-files> directives in your appengine-web.xml file to exclude the appropriate file. By default, all files outside of WEB-INF/ belong to both groups, and so are counted twice, once for each group. The file count limit is the total count for both groups.

 

 

 

Measuring how much resources used by a Request -- in development mode examing information sent in headers

  • Sign into Google developer account
  • Request URL
  • GAE includes HTTP headers in the response that give you information about resources consumed by that request.
    • View headers using a browser plug-in, such as the Web Developer extension for Firefox (Information menu, View Response Headers).

 

header showing resources in dev. mode

X-AppEngine-Estimated-CPM-US-Dollars monetary cost of the request times 1,000, at the current price in U.S. dollars. That is, it's an estimate of what 1,000 requests similar to this one would cost.


X-AppEngine-Resource-Usage
summarizes various resource usage metrics
for the request in milliseconds

  • ms = clock time
  • cpu_ms = CPU time spent on the app server
  • api_cpu_ms = CPU time spent on APIs.
© Lynne Grewe