[google-appengine] Re: deploy is very slow

['Nick (Cloud Platform Support)' via Google App Engine]

Hey Adam,

Are you deploying a Flexible Environment app? If so, what do the container 
builder logs from the Console show as far as activity during this time?

Also, is this still occurring, or was it only for a certain period of time? 
If it's transient, it might just be a momentary service degradation, which 
for a Beta product is to be expected at this stage. When a product goes 
into General Availability, we'll often have certain Service Level targets 
in terms of latency, uptime, that you can rely on (for example, read here 
 for Compute Engine SLA's)

Cheers,

Nick
Cloud Platform Community Support

On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
Bittlingmayer wrote:
>
> Deployment with gcloud deploy app is slow (in the low dozens of minutes).
>
> The build is fast, it is the push steps that are slow.
>
> Both steps like Mounted from google_appengine/python and Updating service 
> [test]...\ ie steps that are in the datacentre, not the upload itself.
>
> Thus the size of the code seems to have no effect, it is small enough in 
> this case.  It happens with both python 2 and 3.
>
> Is there a way to increase an allocation to speed this up?  Are there 
> other factors?
>

-- 
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/2f187450-c774-4478-9fbc-a008060d7b6e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: deploy is very slow

[Adam Mathias Bittlingmayer]

Yes, it is the Flex Env.

Reviewing the container build logs, it does not seem deterministic.  The 
total time varies, and the place in the process where multiple minutes pass 
between two log lines varies.


On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform Support) 
wrote:
>
> Hey Adam,
>
> Are you deploying a Flexible Environment app? If so, what do the container 
> builder logs from the Console show as far as activity during this time?
>
> Also, is this still occurring, or was it only for a certain period of 
> time? If it's transient, it might just be a momentary service degradation, 
> which for a Beta product is to be expected at this stage. When a product 
> goes into General Availability, we'll often have certain Service Level 
> targets in terms of latency, uptime, that you can rely on (for example, read 
> here  for Compute Engine SLA's)
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
> Bittlingmayer wrote:
>>
>> Deployment with gcloud deploy app is slow (in the low dozens of minutes).
>>
>> The build is fast, it is the push steps that are slow.
>>
>> Both steps like Mounted from google_appengine/python and Updating 
>> service [test]...\ ie steps that are in the datacentre, not the upload 
>> itself.
>>
>> Thus the size of the code seems to have no effect, it is small enough in 
>> this case.  It happens with both python 2 and 3.
>>
>> Is there a way to increase an allocation to speed this up?  Are there 
>> other factors?
>>
>

-- 
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/31f6a91e-6700-4775-964d-3ce8fac1b8b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: deploy is very slow

['Nick (Cloud Platform Support)' via Google App Engine]

Hey Adam,

Could you capture the deployment logs using the flags "--verbosity debug" 
and "--log-http", piping this output into the "ts" utility to prepend a 
timestamp to each line, and then email me the logs? I'll be able to analyze 
what might be going on that way. On linux / Mac that will look like:

gcloud --quiet --verbosity debug --log-http app deploy app.yaml --version 
${VERSION} 2>&1 | ts | tee -a deploy_log.txt 


(tee is used so that you can still read the output as it hits the console, 
and note that you'll have to put whatever version you want in the command 
where ${VERSION} is written)

On windows, you can use powershell to run the same command line after 
creating the "ts" filter to prepend timestamps by running the following 
line:

filter timestamp {"$(Get-Date -Format s): $_"}


Cheers,

Nick 

On Saturday, February 4, 2017 at 2:30:00 AM UTC-5, Adam Mathias 
Bittlingmayer wrote:
>
> Yes, it is the Flex Env.
>
> Reviewing the container build logs, it does not seem deterministic.  The 
> total time varies, and the place in the process where multiple minutes pass 
> between two log lines varies.
>
>
> On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform Support) 
> wrote:
>>
>> Hey Adam,
>>
>> Are you deploying a Flexible Environment app? If so, what do the 
>> container builder logs from the Console show as far as activity during this 
>> time?
>>
>> Also, is this still occurring, or was it only for a certain period of 
>> time? If it's transient, it might just be a momentary service degradation, 
>> which for a Beta product is to be expected at this stage. When a product 
>> goes into General Availability, we'll often have certain Service Level 
>> targets in terms of latency, uptime, that you can rely on (for example, read 
>> here  for Compute Engine SLA's)
>>
>> Cheers,
>>
>> Nick
>> Cloud Platform Community Support
>>
>> On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
>> Bittlingmayer wrote:
>>>
>>> Deployment with gcloud deploy app is slow (in the low dozens of 
>>> minutes).
>>>
>>> The build is fast, it is the push steps that are slow.
>>>
>>> Both steps like Mounted from google_appengine/python and Updating 
>>> service [test]...\ ie steps that are in the datacentre, not the upload 
>>> itself.
>>>
>>> Thus the size of the code seems to have no effect, it is small enough in 
>>> this case.  It happens with both python 2 and 3.
>>>
>>> Is there a way to increase an allocation to speed this up?  Are there 
>>> other factors?
>>>
>>

-- 
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/90bf7f8d-c218-4d09-bfdf-165cc94af818%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: deploy is very slow

['Nick (Cloud Platform Support)' via Google App Engine]

Just a quick update:

As well, to avoid the timestamp filtering commands above, you could simply 
run the deployment with the --verbosity debug and --log-http flags and then 
run gcloud info to check for where the "latest log file" is stored, and 
upload that file. The output line telling its location will look like:

Last Log File: [/home/anon/.config/gcloud/logs/2017.02.06/18.30.49.455744.log]


On Monday, February 6, 2017 at 12:58:05 PM UTC-5, Nick (Cloud Platform 
Support) wrote:
>
> Hey Adam,
>
> Could you capture the deployment logs using the flags "--verbosity debug" 
> and "--log-http", piping this output into the "ts" utility to prepend a 
> timestamp to each line, and then email me the logs? I'll be able to analyze 
> what might be going on that way. On linux / Mac that will look like:
>
> gcloud --quiet --verbosity debug --log-http app deploy app.yaml --version 
> ${VERSION} 2>&1 | ts | tee -a deploy_log.txt 
>
>
> (tee is used so that you can still read the output as it hits the console, 
> and note that you'll have to put whatever version you want in the command 
> where ${VERSION} is written)
>
> On windows, you can use powershell to run the same command line after 
> creating the "ts" filter to prepend timestamps by running the following 
> line:
>
> filter timestamp {"$(Get-Date -Format s): $_"}
>
>
> Cheers,
>
> Nick 
>
> On Saturday, February 4, 2017 at 2:30:00 AM UTC-5, Adam Mathias 
> Bittlingmayer wrote:
>>
>> Yes, it is the Flex Env.
>>
>> Reviewing the container build logs, it does not seem deterministic.  The 
>> total time varies, and the place in the process where multiple minutes pass 
>> between two log lines varies.
>>
>>
>> On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform Support) 
>> wrote:
>>>
>>> Hey Adam,
>>>
>>> Are you deploying a Flexible Environment app? If so, what do the 
>>> container builder logs from the Console show as far as activity during this 
>>> time?
>>>
>>> Also, is this still occurring, or was it only for a certain period of 
>>> time? If it's transient, it might just be a momentary service degradation, 
>>> which for a Beta product is to be expected at this stage. When a product 
>>> goes into General Availability, we'll often have certain Service Level 
>>> targets in terms of latency, uptime, that you can rely on (for example, 
>>> read 
>>> here  for Compute Engine SLA's)
>>>
>>> Cheers,
>>>
>>> Nick
>>> Cloud Platform Community Support
>>>
>>> On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
>>> Bittlingmayer wrote:

 Deployment with gcloud deploy app is slow (in the low dozens of 
 minutes).

 The build is fast, it is the push steps that are slow.

 Both steps like Mounted from google_appengine/python and Updating 
 service [test]...\ ie steps that are in the datacentre, not the upload 
 itself.

 Thus the size of the code seems to have no effect, it is small enough 
 in this case.  It happens with both python 2 and 3.

 Is there a way to increase an allocation to speed this up?  Are there 
 other factors?

>>>

-- 
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/e10adca8-0b3e-4cef-a121-7426c08fdbba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: deploy is very slow

[Luis F De Pombo]

Hi Nick,
I am having the same issue as Adam but I am using a nodejs Flex env. I have 
the file you point to, what is the best email to get this to you? Thank you.

On Monday, February 6, 2017 at 10:40:48 AM UTC-8, Nick (Cloud Platform 
Support) wrote:
>
> Just a quick update:
>
> As well, to avoid the timestamp filtering commands above, you could simply 
> run the deployment with the --verbosity debug and --log-http flags and then 
> run gcloud info to check for where the "latest log file" is stored, and 
> upload that file. The output line telling its location will look like:
>
> Last Log File: [/home/anon/.config/gcloud/logs/2017.02.06/18.30.49.455744.log]
>
>
> On Monday, February 6, 2017 at 12:58:05 PM UTC-5, Nick (Cloud Platform 
> Support) wrote:
>>
>> Hey Adam,
>>
>> Could you capture the deployment logs using the flags "--verbosity debug" 
>> and "--log-http", piping this output into the "ts" utility to prepend a 
>> timestamp to each line, and then email me the logs? I'll be able to analyze 
>> what might be going on that way. On linux / Mac that will look like:
>>
>> gcloud --quiet --verbosity debug --log-http app deploy app.yaml --version 
>> ${VERSION} 2>&1 | ts | tee -a deploy_log.txt 
>>
>>
>> (tee is used so that you can still read the output as it hits the 
>> console, and note that you'll have to put whatever version you want in the 
>> command where ${VERSION} is written)
>>
>> On windows, you can use powershell to run the same command line after 
>> creating the "ts" filter to prepend timestamps by running the following 
>> line:
>>
>> filter timestamp {"$(Get-Date -Format s): $_"}
>>
>>
>> Cheers,
>>
>> Nick 
>>
>> On Saturday, February 4, 2017 at 2:30:00 AM UTC-5, Adam Mathias 
>> Bittlingmayer wrote:
>>>
>>> Yes, it is the Flex Env.
>>>
>>> Reviewing the container build logs, it does not seem deterministic.  The 
>>> total time varies, and the place in the process where multiple minutes pass 
>>> between two log lines varies.
>>>
>>>
>>> On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform Support) 
>>> wrote:

 Hey Adam,

 Are you deploying a Flexible Environment app? If so, what do the 
 container builder logs from the Console show as far as activity during 
 this 
 time?

 Also, is this still occurring, or was it only for a certain period of 
 time? If it's transient, it might just be a momentary service degradation, 
 which for a Beta product is to be expected at this stage. When a product 
 goes into General Availability, we'll often have certain Service Level 
 targets in terms of latency, uptime, that you can rely on (for example, 
 read 
 here  for Compute Engine SLA's)

 Cheers,

 Nick
 Cloud Platform Community Support

 On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
 Bittlingmayer wrote:
>
> Deployment with gcloud deploy app is slow (in the low dozens of 
> minutes).
>
> The build is fast, it is the push steps that are slow.
>
> Both steps like Mounted from google_appengine/python and Updating 
> service [test]...\ ie steps that are in the datacentre, not the 
> upload itself.
>
> Thus the size of the code seems to have no effect, it is small enough 
> in this case.  It happens with both python 2 and 3.
>
> Is there a way to increase an allocation to speed this up?  Are there 
> other factors?
>


-- 
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/47f0bc40-1427-4db7-bd62-fb7e07a858d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: deploy is very slow

['Nick (Cloud Platform Support)' via Google App Engine]

Hey Luis, 

The best way in fact would be to create a Public Issue Tracker 
thread, and 
we'll be able to follow up there. Post the link here once you've created a 
thread, and I'll be happy to assist, sending you an email which you can 
reply to, attaching the log. 

Cheers,

Nick
Cloud Platform Community Support

On Sunday, February 12, 2017 at 11:57:14 AM UTC-5, Luis F De Pombo wrote:
>
> Hi Nick,
> I am having the same issue as Adam but I am using a nodejs Flex env. I 
> have the file you point to, what is the best email to get this to you? 
> Thank you.
>
> On Monday, February 6, 2017 at 10:40:48 AM UTC-8, Nick (Cloud Platform 
> Support) wrote:
>>
>> Just a quick update:
>>
>> As well, to avoid the timestamp filtering commands above, you could 
>> simply run the deployment with the --verbosity debug and --log-http flags 
>> and then run gcloud info to check for where the "latest log file" is 
>> stored, and upload that file. The output line telling its location will 
>> look like:
>>
>> Last Log File: 
>> [/home/anon/.config/gcloud/logs/2017.02.06/18.30.49.455744.log]
>>
>>
>> On Monday, February 6, 2017 at 12:58:05 PM UTC-5, Nick (Cloud Platform 
>> Support) wrote:
>>>
>>> Hey Adam,
>>>
>>> Could you capture the deployment logs using the flags "--verbosity 
>>> debug" and "--log-http", piping this output into the "ts" utility to 
>>> prepend a timestamp to each line, and then email me the logs? I'll be able 
>>> to analyze what might be going on that way. On linux / Mac that will look 
>>> like:
>>>
>>> gcloud --quiet --verbosity debug --log-http app deploy app.yaml 
>>> --version ${VERSION} 2>&1 | ts | tee -a deploy_log.txt 
>>>
>>>
>>> (tee is used so that you can still read the output as it hits the 
>>> console, and note that you'll have to put whatever version you want in the 
>>> command where ${VERSION} is written)
>>>
>>> On windows, you can use powershell to run the same command line after 
>>> creating the "ts" filter to prepend timestamps by running the following 
>>> line:
>>>
>>> filter timestamp {"$(Get-Date -Format s): $_"}
>>>
>>>
>>> Cheers,
>>>
>>> Nick 
>>>
>>> On Saturday, February 4, 2017 at 2:30:00 AM UTC-5, Adam Mathias 
>>> Bittlingmayer wrote:

 Yes, it is the Flex Env.

 Reviewing the container build logs, it does not seem deterministic. 
  The total time varies, and the place in the process where multiple 
 minutes 
 pass between two log lines varies.


 On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform 
 Support) wrote:
>
> Hey Adam,
>
> Are you deploying a Flexible Environment app? If so, what do the 
> container builder logs from the Console show as far as activity during 
> this 
> time?
>
> Also, is this still occurring, or was it only for a certain period of 
> time? If it's transient, it might just be a momentary service 
> degradation, 
> which for a Beta product is to be expected at this stage. When a product 
> goes into General Availability, we'll often have certain Service Level 
> targets in terms of latency, uptime, that you can rely on (for example, 
> read 
> here  for Compute Engine SLA's)
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
> Bittlingmayer wrote:
>>
>> Deployment with gcloud deploy app is slow (in the low dozens of 
>> minutes).
>>
>> The build is fast, it is the push steps that are slow.
>>
>> Both steps like Mounted from google_appengine/python and Updating 
>> service [test]...\ ie steps that are in the datacentre, not the 
>> upload itself.
>>
>> Thus the size of the code seems to have no effect, it is small enough 
>> in this case.  It happens with both python 2 and 3.
>>
>> Is there a way to increase an allocation to speed this up?  Are there 
>> other factors?
>>
>

-- 
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/8084d4d6-2599-4377-8c3a-3fce6525%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[google-appengine] Re: deploy is very slow

[Alex Komoroske]

I'm running into this too with the Go flexible environment. Deploys are 
taking 30+ minutes.

On Monday, February 13, 2017 at 12:44:20 PM UTC-8, Nick (Cloud Platform 
Support) wrote:
>
> Hey Luis, 
>
> The best way in fact would be to create a Public Issue Tracker 
> thread, and 
> we'll be able to follow up there. Post the link here once you've created a 
> thread, and I'll be happy to assist, sending you an email which you can 
> reply to, attaching the log. 
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Sunday, February 12, 2017 at 11:57:14 AM UTC-5, Luis F De Pombo wrote:
>>
>> Hi Nick,
>> I am having the same issue as Adam but I am using a nodejs Flex env. I 
>> have the file you point to, what is the best email to get this to you? 
>> Thank you.
>>
>> On Monday, February 6, 2017 at 10:40:48 AM UTC-8, Nick (Cloud Platform 
>> Support) wrote:
>>>
>>> Just a quick update:
>>>
>>> As well, to avoid the timestamp filtering commands above, you could 
>>> simply run the deployment with the --verbosity debug and --log-http flags 
>>> and then run gcloud info to check for where the "latest log file" is 
>>> stored, and upload that file. The output line telling its location will 
>>> look like:
>>>
>>> Last Log File: 
>>> [/home/anon/.config/gcloud/logs/2017.02.06/18.30.49.455744.log]
>>>
>>>
>>> On Monday, February 6, 2017 at 12:58:05 PM UTC-5, Nick (Cloud Platform 
>>> Support) wrote:

 Hey Adam,

 Could you capture the deployment logs using the flags "--verbosity 
 debug" and "--log-http", piping this output into the "ts" utility to 
 prepend a timestamp to each line, and then email me the logs? I'll be able 
 to analyze what might be going on that way. On linux / Mac that will look 
 like:

 gcloud --quiet --verbosity debug --log-http app deploy app.yaml 
 --version ${VERSION} 2>&1 | ts | tee -a deploy_log.txt 


 (tee is used so that you can still read the output as it hits the 
 console, and note that you'll have to put whatever version you want in the 
 command where ${VERSION} is written)

 On windows, you can use powershell to run the same command line after 
 creating the "ts" filter to prepend timestamps by running the following 
 line:

 filter timestamp {"$(Get-Date -Format s): $_"}


 Cheers,

 Nick 

 On Saturday, February 4, 2017 at 2:30:00 AM UTC-5, Adam Mathias 
 Bittlingmayer wrote:
>
> Yes, it is the Flex Env.
>
> Reviewing the container build logs, it does not seem deterministic. 
>  The total time varies, and the place in the process where multiple 
> minutes 
> pass between two log lines varies.
>
>
> On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform 
> Support) wrote:
>>
>> Hey Adam,
>>
>> Are you deploying a Flexible Environment app? If so, what do the 
>> container builder logs from the Console show as far as activity during 
>> this 
>> time?
>>
>> Also, is this still occurring, or was it only for a certain period of 
>> time? If it's transient, it might just be a momentary service 
>> degradation, 
>> which for a Beta product is to be expected at this stage. When a product 
>> goes into General Availability, we'll often have certain Service Level 
>> targets in terms of latency, uptime, that you can rely on (for example, 
>> read 
>> here  for Compute Engine SLA's)
>>
>> Cheers,
>>
>> Nick
>> Cloud Platform Community Support
>>
>> On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
>> Bittlingmayer wrote:
>>>
>>> Deployment with gcloud deploy app is slow (in the low dozens of 
>>> minutes).
>>>
>>> The build is fast, it is the push steps that are slow.
>>>
>>> Both steps like Mounted from google_appengine/python and Updating 
>>> service [test]...\ ie steps that are in the datacentre, not the 
>>> upload itself.
>>>
>>> Thus the size of the code seems to have no effect, it is small 
>>> enough in this case.  It happens with both python 2 and 3.
>>>
>>> Is there a way to increase an allocation to speed this up?  Are 
>>> there other factors?
>>>
>>

-- 
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/6ac91660-5285-42d4-bf18-9688b92bd9bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/op

[google-appengine] Re: deploy is very slow

['Nick (Cloud Platform Support)' via Google App Engine]

Hey Alex,

Slow deploys can be caused by many factors. If you want to submit a Public 
Issue Tracker  issue 
for us to look at, you should consider including the following information:

1. The size on disk of your project
2. Whether you're using the flexible environment or not, and whether you 
have a Dockerfile (if so, the contents of the Dockerfile)
3. The number of files in the project
4. The deploy log stored in a location given by running gcloud info and 
seeing the "Last Log File" field.

With this information we'll be able to better understand whether the deploy 
time is expected or exceptional.

Cheers,

Nick
Cloud Platform Community Support

On Monday, February 20, 2017 at 11:19:58 AM UTC-5, Alex Komoroske wrote:
>
> I'm running into this too with the Go flexible environment. Deploys are 
> taking 30+ minutes.
>
> On Monday, February 13, 2017 at 12:44:20 PM UTC-8, Nick (Cloud Platform 
> Support) wrote:
>>
>> Hey Luis, 
>>
>> The best way in fact would be to create a Public Issue Tracker 
>> thread, and 
>> we'll be able to follow up there. Post the link here once you've created a 
>> thread, and I'll be happy to assist, sending you an email which you can 
>> reply to, attaching the log. 
>>
>> Cheers,
>>
>> Nick
>> Cloud Platform Community Support
>>
>> On Sunday, February 12, 2017 at 11:57:14 AM UTC-5, Luis F De Pombo wrote:
>>>
>>> Hi Nick,
>>> I am having the same issue as Adam but I am using a nodejs Flex env. I 
>>> have the file you point to, what is the best email to get this to you? 
>>> Thank you.
>>>
>>> On Monday, February 6, 2017 at 10:40:48 AM UTC-8, Nick (Cloud Platform 
>>> Support) wrote:

 Just a quick update:

 As well, to avoid the timestamp filtering commands above, you could 
 simply run the deployment with the --verbosity debug and --log-http flags 
 and then run gcloud info to check for where the "latest log file" is 
 stored, and upload that file. The output line telling its location will 
 look like:

 Last Log File: 
 [/home/anon/.config/gcloud/logs/2017.02.06/18.30.49.455744.log]


 On Monday, February 6, 2017 at 12:58:05 PM UTC-5, Nick (Cloud Platform 
 Support) wrote:
>
> Hey Adam,
>
> Could you capture the deployment logs using the flags "--verbosity 
> debug" and "--log-http", piping this output into the "ts" utility to 
> prepend a timestamp to each line, and then email me the logs? I'll be 
> able 
> to analyze what might be going on that way. On linux / Mac that will look 
> like:
>
> gcloud --quiet --verbosity debug --log-http app deploy app.yaml 
> --version ${VERSION} 2>&1 | ts | tee -a deploy_log.txt 
>
>
> (tee is used so that you can still read the output as it hits the 
> console, and note that you'll have to put whatever version you want in 
> the 
> command where ${VERSION} is written)
>
> On windows, you can use powershell to run the same command line after 
> creating the "ts" filter to prepend timestamps by running the following 
> line:
>
> filter timestamp {"$(Get-Date -Format s): $_"}
>
>
> Cheers,
>
> Nick 
>
> On Saturday, February 4, 2017 at 2:30:00 AM UTC-5, Adam Mathias 
> Bittlingmayer wrote:
>>
>> Yes, it is the Flex Env.
>>
>> Reviewing the container build logs, it does not seem deterministic. 
>>  The total time varies, and the place in the process where multiple 
>> minutes 
>> pass between two log lines varies.
>>
>>
>> On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform 
>> Support) wrote:
>>>
>>> Hey Adam,
>>>
>>> Are you deploying a Flexible Environment app? If so, what do the 
>>> container builder logs from the Console show as far as activity during 
>>> this 
>>> time?
>>>
>>> Also, is this still occurring, or was it only for a certain period 
>>> of time? If it's transient, it might just be a momentary service 
>>> degradation, which for a Beta product is to be expected at this stage. 
>>> When 
>>> a product goes into General Availability, we'll often have certain 
>>> Service 
>>> Level targets in terms of latency, uptime, that you can rely on (for 
>>> example, read here  for 
>>> Compute Engine SLA's)
>>>
>>> Cheers,
>>>
>>> Nick
>>> Cloud Platform Community Support
>>>
>>> On Thursday, February 2, 2017 at 9:02:29 AM UTC-5, Adam Mathias 
>>> Bittlingmayer wrote:

 Deployment with gcloud deploy app is slow (in the low dozens of 
 minutes).

 The build is fast, it is the push steps that are slow.

 Both steps like Mounted from google_appengine/python and Updating 
 service [tes

[google-appengine] Re: deploy is very slow

[Cole Peterson]

Hey Nick. Just go and deploy a service using glcoud deploy and you will see 
the issue.
It is unbearably slow.

On Wednesday, February 22, 2017 at 3:11:06 PM UTC-8, Nick (Cloud Platform 
Support) wrote:
>
> Hey Alex,
>
> Slow deploys can be caused by many factors. If you want to submit a Public 
> Issue Tracker  
> issue for us to look at, you should consider including the following 
> information:
>
> 1. The size on disk of your project
> 2. Whether you're using the flexible environment or not, and whether you 
> have a Dockerfile (if so, the contents of the Dockerfile)
> 3. The number of files in the project
> 4. The deploy log stored in a location given by running gcloud info and 
> seeing the "Last Log File" field.
>
> With this information we'll be able to better understand whether the 
> deploy time is expected or exceptional.
>
> Cheers,
>
> Nick
> Cloud Platform Community Support
>
> On Monday, February 20, 2017 at 11:19:58 AM UTC-5, Alex Komoroske wrote:
>>
>> I'm running into this too with the Go flexible environment. Deploys are 
>> taking 30+ minutes.
>>
>> On Monday, February 13, 2017 at 12:44:20 PM UTC-8, Nick (Cloud Platform 
>> Support) wrote:
>>>
>>> Hey Luis, 
>>>
>>> The best way in fact would be to create a Public Issue Tracker 
>>> thread, 
>>> and we'll be able to follow up there. Post the link here once you've 
>>> created a thread, and I'll be happy to assist, sending you an email which 
>>> you can reply to, attaching the log. 
>>>
>>> Cheers,
>>>
>>> Nick
>>> Cloud Platform Community Support
>>>
>>> On Sunday, February 12, 2017 at 11:57:14 AM UTC-5, Luis F De Pombo wrote:

 Hi Nick,
 I am having the same issue as Adam but I am using a nodejs Flex env. I 
 have the file you point to, what is the best email to get this to you? 
 Thank you.

 On Monday, February 6, 2017 at 10:40:48 AM UTC-8, Nick (Cloud Platform 
 Support) wrote:
>
> Just a quick update:
>
> As well, to avoid the timestamp filtering commands above, you could 
> simply run the deployment with the --verbosity debug and --log-http flags 
> and then run gcloud info to check for where the "latest log file" is 
> stored, and upload that file. The output line telling its location will 
> look like:
>
> Last Log File: 
> [/home/anon/.config/gcloud/logs/2017.02.06/18.30.49.455744.log]
>
>
> On Monday, February 6, 2017 at 12:58:05 PM UTC-5, Nick (Cloud Platform 
> Support) wrote:
>>
>> Hey Adam,
>>
>> Could you capture the deployment logs using the flags "--verbosity 
>> debug" and "--log-http", piping this output into the "ts" utility to 
>> prepend a timestamp to each line, and then email me the logs? I'll be 
>> able 
>> to analyze what might be going on that way. On linux / Mac that will 
>> look 
>> like:
>>
>> gcloud --quiet --verbosity debug --log-http app deploy app.yaml 
>> --version ${VERSION} 2>&1 | ts | tee -a deploy_log.txt 
>>
>>
>> (tee is used so that you can still read the output as it hits the 
>> console, and note that you'll have to put whatever version you want in 
>> the 
>> command where ${VERSION} is written)
>>
>> On windows, you can use powershell to run the same command line after 
>> creating the "ts" filter to prepend timestamps by running the following 
>> line:
>>
>> filter timestamp {"$(Get-Date -Format s): $_"}
>>
>>
>> Cheers,
>>
>> Nick 
>>
>> On Saturday, February 4, 2017 at 2:30:00 AM UTC-5, Adam Mathias 
>> Bittlingmayer wrote:
>>>
>>> Yes, it is the Flex Env.
>>>
>>> Reviewing the container build logs, it does not seem deterministic. 
>>>  The total time varies, and the place in the process where multiple 
>>> minutes 
>>> pass between two log lines varies.
>>>
>>>
>>> On Friday, 3 February 2017 12:40:25 UTC-8, Nick (Cloud Platform 
>>> Support) wrote:

 Hey Adam,

 Are you deploying a Flexible Environment app? If so, what do the 
 container builder logs from the Console show as far as activity during 
 this 
 time?

 Also, is this still occurring, or was it only for a certain period 
 of time? If it's transient, it might just be a momentary service 
 degradation, which for a Beta product is to be expected at this stage. 
 When 
 a product goes into General Availability, we'll often have certain 
 Service 
 Level targets in terms of latency, uptime, that you can rely on (for 
 example, read here  for 
 Compute Engine SLA's)

 Cheers,

 Nick
 Cloud Platform Community Support

 On Thursda