Re: [google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

['Lorne Kligerman' via Google App Engine]

Understood, thanks for the write up!



On Mon, Apr 24, 2017 at 4:45 PM, Robert Dyas 
wrote:

> Yes, but in addition to that consider it a feature request that the
> incoming IP address from GAE std to GCE will be easily identifiable (or a
> range). The reason for this is we have some servers that will still be
> accepting requests over their external IP that will be required to be
> encrypted, while the internal ones from GAE can come in unencrypted . To do
> this with MariaDB we need to see the incoming IP address ... so if its
> something like if its in 10.xxx.xxx.xxx we know its internal, and if not
> then its external and requires encryption.
>
>
> On Monday, April 24, 2017 at 7:30:26 PM UTC-4, Lorne Kligerman wrote:
>>
>> More details to come, however we will provide a mechanism to be sure that
>> only your App Engine app can connect to your own GCE VMs.
>>
>> On Mon, Apr 24, 2017 at 1:41 PM, Robert Dyas 
>> wrote:
>>
>>> Question: will the IP address from App Engine Std appear as though its
>>> on the internal GCE network? Hopefully yes so that its easy to filter
>>> incoming requests as coming from a trusted source or not.
>>>
>>> On Sunday, April 23, 2017 at 5:27:25 PM UTC-4, Lorne Kligerman wrote:
>>>
 Hey folks,

 I'm glad to report that this is something that we're actively working
 on!
 Nothing to report at the moment on timing but when ready for some
 testing I'll be sure to send a note here.  Stay tuned!

 Cheers,
 Lorne.
 Product Manager - App Engine

 On Saturday, April 22, 2017 at 7:15:31 AM UTC-7, Robert Dyas wrote:
>
> Yep, that helps. Thank you. I also bet that if you ran a test
> connecting over a 7 day period you would see lots of times where that
> ~200-400ms becomes ~1,000 to ~2,000+ms. When I run this same test
> machine-2-machine using the internal IP addresses on GCE, the time is 
> close
> enough to zero that I don't care. The net difference in our app is a 
> single
> request (a client can make up to 3 for a complex ERP screen) takes
> ~400-900ms (open tls connection, all the back and forth) whereas the same
> thing tested GCE to GCE via intenal ip takes 10ms (with high 
> consistency.).
> Multiply those numbers by 3x for our biggest customers (most complex apps)
> and you are looking at ~30ms vs ~2,000mm wait per click (which gets old.)
> They do tolerate this because they are coming from really nasty systems,
> but we want to provide the best possible cloud experience.
>
> I really hope someone at Google is monitoring this thread. If we could
> allocate our GAE std setup to the default GCE network for our project and
> avoid all this socket overhead it would be a very, very, very good thing.
>
>
>
> On Saturday, April 22, 2017 at 9:05:28 AM UTC-4, Evan Jones wrote:
>>
>> I just took a quick look at the trace viewer for ~5 requests. It
>> looks like sending/receiving data on an existing connection takes around
>> 1-5 ms for the Send and Receive calls.
>>
>> For creating a new connection: I see times like:
>>
>> CreateSocket: 3-5 ms
>> Resolve: 1 ms
>> Connect: 2-12 ms
>>
>> ... a whole bunch of additional Send/Receives that I assume are due
>> to the fact we use TLS connections, so there is a handshake that is
>> required.
>>
>> This whole process can take ~200-400 ms; some of which is "our fault"
>> because our server takes some time to execute the TLS handshake (I'm
>> guessing this adds ~50 ms, looking at the traces).
>>
>> Hope that helps!
>>
>>
>>
>> On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:
>>>
>>> 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 
 

Re: [google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

[Robert Dyas]

Yes, but in addition to that consider it a feature request that the 
incoming IP address from GAE std to GCE will be easily identifiable (or a 
range). The reason for this is we have some servers that will still be 
accepting requests over their external IP that will be required to be 
encrypted, while the internal ones from GAE can come in unencrypted . To do 
this with MariaDB we need to see the incoming IP address ... so if its 
something like if its in 10.xxx.xxx.xxx we know its internal, and if not 
then its external and requires encryption.


On Monday, April 24, 2017 at 7:30:26 PM UTC-4, Lorne Kligerman wrote:
>
> More details to come, however we will provide a mechanism to be sure that 
> only your App Engine app can connect to your own GCE VMs.
>
> On Mon, Apr 24, 2017 at 1:41 PM, Robert Dyas  > wrote:
>
>> Question: will the IP address from App Engine Std appear as though its on 
>> the internal GCE network? Hopefully yes so that its easy to filter incoming 
>> requests as coming from a trusted source or not.
>>
>> On Sunday, April 23, 2017 at 5:27:25 PM UTC-4, Lorne Kligerman wrote:
>>
>>> Hey folks,
>>>
>>> I'm glad to report that this is something that we're actively working on!
>>> Nothing to report at the moment on timing but when ready for some 
>>> testing I'll be sure to send a note here.  Stay tuned!
>>>
>>> Cheers,
>>> Lorne.
>>> Product Manager - App Engine
>>>
>>> On Saturday, April 22, 2017 at 7:15:31 AM UTC-7, Robert Dyas wrote:

 Yep, that helps. Thank you. I also bet that if you ran a test 
 connecting over a 7 day period you would see lots of times where that 
 ~200-400ms becomes ~1,000 to ~2,000+ms. When I run this same test 
 machine-2-machine using the internal IP addresses on GCE, the time is 
 close 
 enough to zero that I don't care. The net difference in our app is a 
 single 
 request (a client can make up to 3 for a complex ERP screen) takes 
 ~400-900ms (open tls connection, all the back and forth) whereas the same 
 thing tested GCE to GCE via intenal ip takes 10ms (with high 
 consistency.). 
 Multiply those numbers by 3x for our biggest customers (most complex apps) 
 and you are looking at ~30ms vs ~2,000mm wait per click (which gets old.) 
 They do tolerate this because they are coming from really nasty systems, 
 but we want to provide the best possible cloud experience.

 I really hope someone at Google is monitoring this thread. If we could 
 allocate our GAE std setup to the default GCE network for our project and 
 avoid all this socket overhead it would be a very, very, very good thing.



 On Saturday, April 22, 2017 at 9:05:28 AM UTC-4, Evan Jones wrote:
>
> I just took a quick look at the trace viewer for ~5 requests. It looks 
> like sending/receiving data on an existing connection takes around 1-5 ms 
> for the Send and Receive calls.
>
> For creating a new connection: I see times like:
>
> CreateSocket: 3-5 ms
> Resolve: 1 ms
> Connect: 2-12 ms
>
> ... a whole bunch of additional Send/Receives that I assume are due to 
> the fact we use TLS connections, so there is a handshake that is required.
>
> This whole process can take ~200-400 ms; some of which is "our fault" 
> because our server takes some time to execute the TLS handshake (I'm 
> guessing this adds ~50 ms, looking at the traces).
>
> Hope that helps!
>
>
>
> On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:
>>
>> 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, 

Re: [google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

['Lorne Kligerman' via Google App Engine]

More details to come, however we will provide a mechanism to be sure that
only your App Engine app can connect to your own GCE VMs.

On Mon, Apr 24, 2017 at 1:41 PM, Robert Dyas 
wrote:

> Question: will the IP address from App Engine Std appear as though its on
> the internal GCE network? Hopefully yes so that its easy to filter incoming
> requests as coming from a trusted source or not.
>
> On Sunday, April 23, 2017 at 5:27:25 PM UTC-4, Lorne Kligerman wrote:
>
>> Hey folks,
>>
>> I'm glad to report that this is something that we're actively working on!
>> Nothing to report at the moment on timing but when ready for some testing
>> I'll be sure to send a note here.  Stay tuned!
>>
>> Cheers,
>> Lorne.
>> Product Manager - App Engine
>>
>> On Saturday, April 22, 2017 at 7:15:31 AM UTC-7, Robert Dyas wrote:
>>>
>>> Yep, that helps. Thank you. I also bet that if you ran a test connecting
>>> over a 7 day period you would see lots of times where that ~200-400ms
>>> becomes ~1,000 to ~2,000+ms. When I run this same test machine-2-machine
>>> using the internal IP addresses on GCE, the time is close enough to zero
>>> that I don't care. The net difference in our app is a single request (a
>>> client can make up to 3 for a complex ERP screen) takes ~400-900ms (open
>>> tls connection, all the back and forth) whereas the same thing tested GCE
>>> to GCE via intenal ip takes 10ms (with high consistency.). Multiply those
>>> numbers by 3x for our biggest customers (most complex apps) and you are
>>> looking at ~30ms vs ~2,000mm wait per click (which gets old.) They do
>>> tolerate this because they are coming from really nasty systems, but we
>>> want to provide the best possible cloud experience.
>>>
>>> I really hope someone at Google is monitoring this thread. If we could
>>> allocate our GAE std setup to the default GCE network for our project and
>>> avoid all this socket overhead it would be a very, very, very good thing.
>>>
>>>
>>>
>>> On Saturday, April 22, 2017 at 9:05:28 AM UTC-4, Evan Jones wrote:

 I just took a quick look at the trace viewer for ~5 requests. It looks
 like sending/receiving data on an existing connection takes around 1-5 ms
 for the Send and Receive calls.

 For creating a new connection: I see times like:

 CreateSocket: 3-5 ms
 Resolve: 1 ms
 Connect: 2-12 ms

 ... a whole bunch of additional Send/Receives that I assume are due to
 the fact we use TLS connections, so there is a handshake that is required.

 This whole process can take ~200-400 ms; some of which is "our fault"
 because our server takes some time to execute the TLS handshake (I'm
 guessing this adds ~50 ms, looking at the traces).

 Hope that helps!



 On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:
>
> 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
>>> 

[google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

[Robert Dyas]

Question: will the IP address from App Engine Std appear as though its on 
the internal GCE network? Hopefully yes so that its easy to filter incoming 
requests as coming from a trusted source or not.

On Sunday, April 23, 2017 at 5:27:25 PM UTC-4, Lorne Kligerman wrote:
>
> Hey folks,
>
> I'm glad to report that this is something that we're actively working on!
> Nothing to report at the moment on timing but when ready for some testing 
> I'll be sure to send a note here.  Stay tuned!
>
> Cheers,
> Lorne.
> Product Manager - App Engine
>
> On Saturday, April 22, 2017 at 7:15:31 AM UTC-7, Robert Dyas wrote:
>>
>> Yep, that helps. Thank you. I also bet that if you ran a test connecting 
>> over a 7 day period you would see lots of times where that ~200-400ms 
>> becomes ~1,000 to ~2,000+ms. When I run this same test machine-2-machine 
>> using the internal IP addresses on GCE, the time is close enough to zero 
>> that I don't care. The net difference in our app is a single request (a 
>> client can make up to 3 for a complex ERP screen) takes ~400-900ms (open 
>> tls connection, all the back and forth) whereas the same thing tested GCE 
>> to GCE via intenal ip takes 10ms (with high consistency.). Multiply those 
>> numbers by 3x for our biggest customers (most complex apps) and you are 
>> looking at ~30ms vs ~2,000mm wait per click (which gets old.) They do 
>> tolerate this because they are coming from really nasty systems, but we 
>> want to provide the best possible cloud experience.
>>
>> I really hope someone at Google is monitoring this thread. If we could 
>> allocate our GAE std setup to the default GCE network for our project and 
>> avoid all this socket overhead it would be a very, very, very good thing.
>>
>>
>>
>> On Saturday, April 22, 2017 at 9:05:28 AM UTC-4, Evan Jones wrote:
>>>
>>> I just took a quick look at the trace viewer for ~5 requests. It looks 
>>> like sending/receiving data on an existing connection takes around 1-5 ms 
>>> for the Send and Receive calls.
>>>
>>> For creating a new connection: I see times like:
>>>
>>> CreateSocket: 3-5 ms
>>> Resolve: 1 ms
>>> Connect: 2-12 ms
>>>
>>> ... a whole bunch of additional Send/Receives that I assume are due to 
>>> the fact we use TLS connections, so there is a handshake that is required.
>>>
>>> This whole process can take ~200-400 ms; some of which is "our fault" 
>>> because our server takes some time to execute the TLS handshake (I'm 
>>> guessing this adds ~50 ms, looking at the traces).
>>>
>>> Hope that helps!
>>>
>>>
>>>
>>> On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:

 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 

[google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

[Robert Dyas]

That's great news! It can't come too soon!

On Sunday, April 23, 2017 at 5:27:25 PM UTC-4, Lorne Kligerman wrote:
>
> Hey folks,
>
> I'm glad to report that this is something that we're actively working on!
> Nothing to report at the moment on timing but when ready for some testing 
> I'll be sure to send a note here.  Stay tuned!
>
> Cheers,
> Lorne.
> Product Manager - App Engine
>
> On Saturday, April 22, 2017 at 7:15:31 AM UTC-7, Robert Dyas wrote:
>>
>> Yep, that helps. Thank you. I also bet that if you ran a test connecting 
>> over a 7 day period you would see lots of times where that ~200-400ms 
>> becomes ~1,000 to ~2,000+ms. When I run this same test machine-2-machine 
>> using the internal IP addresses on GCE, the time is close enough to zero 
>> that I don't care. The net difference in our app is a single request (a 
>> client can make up to 3 for a complex ERP screen) takes ~400-900ms (open 
>> tls connection, all the back and forth) whereas the same thing tested GCE 
>> to GCE via intenal ip takes 10ms (with high consistency.). Multiply those 
>> numbers by 3x for our biggest customers (most complex apps) and you are 
>> looking at ~30ms vs ~2,000mm wait per click (which gets old.) They do 
>> tolerate this because they are coming from really nasty systems, but we 
>> want to provide the best possible cloud experience.
>>
>> I really hope someone at Google is monitoring this thread. If we could 
>> allocate our GAE std setup to the default GCE network for our project and 
>> avoid all this socket overhead it would be a very, very, very good thing.
>>
>>
>>
>> On Saturday, April 22, 2017 at 9:05:28 AM UTC-4, Evan Jones wrote:
>>>
>>> I just took a quick look at the trace viewer for ~5 requests. It looks 
>>> like sending/receiving data on an existing connection takes around 1-5 ms 
>>> for the Send and Receive calls.
>>>
>>> For creating a new connection: I see times like:
>>>
>>> CreateSocket: 3-5 ms
>>> Resolve: 1 ms
>>> Connect: 2-12 ms
>>>
>>> ... a whole bunch of additional Send/Receives that I assume are due to 
>>> the fact we use TLS connections, so there is a handshake that is required.
>>>
>>> This whole process can take ~200-400 ms; some of which is "our fault" 
>>> because our server takes some time to execute the TLS handshake (I'm 
>>> guessing this adds ~50 ms, looking at the traces).
>>>
>>> Hope that helps!
>>>
>>>
>>>
>>> On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:

 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 

[google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

['Lorne Kligerman' via Google App Engine]

Hey folks,

I'm glad to report that this is something that we're actively working on!
Nothing to report at the moment on timing but when ready for some testing 
I'll be sure to send a note here.  Stay tuned!

Cheers,
Lorne.
Product Manager - App Engine

On Saturday, April 22, 2017 at 7:15:31 AM UTC-7, Robert Dyas wrote:
>
> Yep, that helps. Thank you. I also bet that if you ran a test connecting 
> over a 7 day period you would see lots of times where that ~200-400ms 
> becomes ~1,000 to ~2,000+ms. When I run this same test machine-2-machine 
> using the internal IP addresses on GCE, the time is close enough to zero 
> that I don't care. The net difference in our app is a single request (a 
> client can make up to 3 for a complex ERP screen) takes ~400-900ms (open 
> tls connection, all the back and forth) whereas the same thing tested GCE 
> to GCE via intenal ip takes 10ms (with high consistency.). Multiply those 
> numbers by 3x for our biggest customers (most complex apps) and you are 
> looking at ~30ms vs ~2,000mm wait per click (which gets old.) They do 
> tolerate this because they are coming from really nasty systems, but we 
> want to provide the best possible cloud experience.
>
> I really hope someone at Google is monitoring this thread. If we could 
> allocate our GAE std setup to the default GCE network for our project and 
> avoid all this socket overhead it would be a very, very, very good thing.
>
>
>
> On Saturday, April 22, 2017 at 9:05:28 AM UTC-4, Evan Jones wrote:
>>
>> I just took a quick look at the trace viewer for ~5 requests. It looks 
>> like sending/receiving data on an existing connection takes around 1-5 ms 
>> for the Send and Receive calls.
>>
>> For creating a new connection: I see times like:
>>
>> CreateSocket: 3-5 ms
>> Resolve: 1 ms
>> Connect: 2-12 ms
>>
>> ... a whole bunch of additional Send/Receives that I assume are due to 
>> the fact we use TLS connections, so there is a handshake that is required.
>>
>> This whole process can take ~200-400 ms; some of which is "our fault" 
>> because our server takes some time to execute the TLS handshake (I'm 
>> guessing this adds ~50 ms, looking at the traces).
>>
>> Hope that helps!
>>
>>
>>
>> On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:
>>>
>>> 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 

[google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

[Robert Dyas]

Yep, that helps. Thank you. I also bet that if you ran a test connecting 
over a 7 day period you would see lots of times where that ~200-400ms 
becomes ~1,000 to ~2,000+ms. When I run this same test machine-2-machine 
using the internal IP addresses on GCE, the time is close enough to zero 
that I don't care. The net difference in our app is a single request (a 
client can make up to 3 for a complex ERP screen) takes ~400-900ms (open 
tls connection, all the back and forth) whereas the same thing tested GCE 
to GCE via intenal ip takes 10ms (with high consistency.). Multiply those 
numbers by 3x for our biggest customers (most complex apps) and you are 
looking at ~30ms vs ~2,000mm wait per click (which gets old.) They do 
tolerate this because they are coming from really nasty systems, but we 
want to provide the best possible cloud experience.

I really hope someone at Google is monitoring this thread. If we could 
allocate our GAE std setup to the default GCE network for our project and 
avoid all this socket overhead it would be a very, very, very good thing.



On Saturday, April 22, 2017 at 9:05:28 AM UTC-4, Evan Jones wrote:
>
> I just took a quick look at the trace viewer for ~5 requests. It looks 
> like sending/receiving data on an existing connection takes around 1-5 ms 
> for the Send and Receive calls.
>
> For creating a new connection: I see times like:
>
> CreateSocket: 3-5 ms
> Resolve: 1 ms
> Connect: 2-12 ms
>
> ... a whole bunch of additional Send/Receives that I assume are due to the 
> fact we use TLS connections, so there is a handshake that is required.
>
> This whole process can take ~200-400 ms; some of which is "our fault" 
> because our server takes some time to execute the TLS handshake (I'm 
> guessing this adds ~50 ms, looking at the traces).
>
> Hope that helps!
>
>
>
> On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:
>>
>> 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 

[google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

[Evan Jones]

I just took a quick look at the trace viewer for ~5 requests. It looks like 
sending/receiving data on an existing connection takes around 1-5 ms for 
the Send and Receive calls.

For creating a new connection: I see times like:

CreateSocket: 3-5 ms
Resolve: 1 ms
Connect: 2-12 ms

... a whole bunch of additional Send/Receives that I assume are due to the 
fact we use TLS connections, so there is a handshake that is required.

This whole process can take ~200-400 ms; some of which is "our fault" 
because our server takes some time to execute the TLS handshake (I'm 
guessing this adds ~50 ms, looking at the traces).

Hope that helps!



On Friday, April 21, 2017 at 5:56:55 PM UTC-4, Robert Dyas wrote:
>
> 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/dced197e-6d15-4ad1-acfa-1df31fa0d60d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

[Robert Dyas]

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.

[google-appengine] Re: need to connect App Engine Std to GCE via internal IP address

[Evan Jones]

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/12e7836c-ec26-4b9c-aa24-2ec086056317%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.