Databases
StackOverflow2013
Postsdbo
POBehaviour when doing requests between 2 Google AppEngine apps
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POBehaviour when doing requests between 2 Google AppEngine apps
    primarykey
    data
    text
    <p>We run 2 apps on Google AppEngine, one in Python, and one in Java.</p> <p>The Python app faces the internet and serves browser users or API calls from our smartphone app.</p> <p>The Python app often communicates with the Java app, which offers workflow engine services. The Java app is never accessed directly from the internet. This is similar to a service oriented architecture.</p> <p>Our Java app is configured with 1 resident instance. However, we often see that when the Python app sends a request to the Java app (which is doing nothing at that moment), that a new Java instance is spawned, instead of having the resident instance serve the request. This way, latencies up to 10 seconds were discovered, whereas the request handling itself takes less than 1 second.</p> <p>Could it be possible that Google considers a request from one appengine app to another one, as a sort of backend workload, for which throughput is more important than latency? Are there different policies for requests coming from the internet versus requests coming from Google internally (defered methods, cron, ... maybe inter-appengine requests also resorts in this category, which is maybe not always correct).</p> <p>Google recommended me to run the Java app as a backend of the Python app, and in fact have only 1 single Appengine app, instead of 2.</p> <p>Some information in this thread: <a href="https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/8O7K3cFzBbY" rel="nofollow">https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/8O7K3cFzBbY</a></p> <p>Any advice on how to force appengine resident instances handle incoming requests, rather than spawn and warm up new instances, which might be good for throughput, but bad for latency?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USCarl D'Halluin
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COAre you setting <instances> to 1 as explained here? https://developers.google.com/appengine/docs/java/config/backends#Backends_Definitions
      singulars
      1. POBehaviour when doing requests between 2 Google AppEngine apps
      1. USGuido van Rossum
    2. COCurrently I am not using a backend; instead I use 2 different appengine apps. The one facing the internet is Python; the internal one is Java. I will definitely try to set up the Java functionality as a backend of the Python, and have only 1 single appengine app. But the question is whether Google has different policies wrt latency and throughput for workloads coming from the internet, versus workload coming from inside the Google datacenters (e.g. another appengine app, a defered, a cron, a warmup, ...)
      singulars
      1. POBehaviour when doing requests between 2 Google AppEngine apps
      1. USCarl D'Halluin
    3. COPolicy questions are better asked on the group: https://groups.google.com/forum/?fromgroups#!forum/google-appengine
      singulars
      1. POBehaviour when doing requests between 2 Google AppEngine apps
      1. USGuido van Rossum
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload