Do you have any idea how much slower creating a new connection is? This is probably our issue.
We don't use connection pooling currently as each user is logged in to the db with their own credentials (ERP type app), but it might be worth exploring if the pooling and driver can handle that. It would be great to know how much slower you found creating the connection is vs write to open connection... On Wednesday, April 19, 2017 at 8:24:59 PM UTC-4, Evan Jones wrote: > > My understanding is that App Engine Standard can only talk to things that > are accessible via a "public" Internet IP address, so I'm not sure I'm > going to be able to provide any magic suggestions. However, I will mention > that in our experience we can get "reasonable" latency. In particular, we > collect application-specific metrics by sending them from our Python App > Engine Standard code to compute engine, over an SSL encrypted socket (this > is using the socket API directly). The App Engine standard traces show > these packet writes taking about ~1-2 ms, but we certainly see that > creating a *new* connection is much, much slower. With a connection pool, > our application sees reasonable latency. > > We also have some things making HTTP requests via the urlfetch API, and > again we see "reasonable" latency (although I should check what it actually > is, I haven't looked recently). > > I have no experience with JDBC on App Engine standard, so I can't really > help there. > > Good luck, > > Evan > > > On Wednesday, April 19, 2017 at 2:50:28 PM UTC-4, Robert Dyas wrote: >> >> I need to connect App Engine Std (AES) to GCE via an internal IP address. >> >> - Would GAE being issuing request and GCE, responses? The other way >> around? Both? >> - AES would issue the requests only >> - Are requests and responses tightly coupled like HTTP >> requests/responses or more independent like tasks in task queues >> reflecting >> asynchronous requests? >> - mostly tightly coupled request wait for response (JDBC connection >> from AES -> GCE) >> - if we neeed async, we could build a service on GCE to take a >> request immeiately and work on it for however long - so not an issue >> - What type of scaling would be employed for the App Engine >> component? Would the Compute Engine instances also be scaled? >> - normal AES scaling as now would be fine - our AES product shards >> amoung server, so no special requirement there >> - What solutions have you tried? Any of the ones posted above? >> - our current "solution" is using a GCE external IP - this sucks >> for a number of reasons >> - 1) the latency between AES and GCE is too high for fast JDBC >> communication (much, much, much slower than GCE internal ip --> GCE >> internal ip which is very very fast in our testing... the moment >> the same >> requet comes for GAE there is a ton of overhead... and JDBC is very >> "chatty" in our application) >> - 2) we really should use SSL between GAE and GCE since going >> over external IP, but this makes the problem even worse >> - >> >> -- 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-appengine+unsubscr...@googlegroups.com. To post to this group, send email to google-appengine@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/2bcd4215-db0d-46d0-8c2f-847817f3eb31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
