App Engine Costs - Frontend InstancesFrankfurt

[ngulamai]

we are seeing that App Engine is consuming lot's of recources. Provided that the traffic that we are sending during this test phase is minimum, we would need you to review the overall setup to reduce costs.

Can't we use cloud functions to reduce costs?

https://www.dropbox.com/s/oww3bd4vcwppsk6/Screenshot%202017-12-16%2013.48.42.png?dl=0

[ngulamai]

https://www.dropbox.com/s/ywerdq4adtqp5ky/Screenshot%202017-12-16%2013.51.31.png?dl=0

[akolchin-MM]

we are seeing that App Engine is consuming lot's of recources. Provided that the traffic that we are sending during this test phase is minimum, we would need you to review the overall setup to reduce costs.

This is the core point - this costs values for now slightly depend on traffic you are still sending to it. It is mostly the zero level. In other words, if you will increase traffic in 10 times, costs will not rise in 10 times.

Costs increased in comparison to the beginning because I tried to resolve some issues by adding more resources:

1. I have increased instances type from F1 to the F2. This led to fixing #2 issue but also to the increasing costs proportionally. https://cloud.google.com/appengine/docs/standard/#instance_classes https://cloud.google.com/appengine/pricing#standard_instance_pricing

Taking into account that this issue raised just 28 times for all the time, I would return back to smaller and cheaper instances class if you don't mind.

2. I have added two Resident instances trying to resolve #1 issue. "_Auto scaling services use dynamic instances; however, if you specify a number, N, of minimum idle instances, the first N instances will be resident, and additional dynamic instances will be created as necessary._" https://cloud.google.com/appengine/docs/standard/java/how-instances-are-managed

I suppose that we also should rollback this change because I don't see the direct impact of it on the latency spikes.

And finally, if you would like that AppEngine will be able to scale down to the real zero you should turn off pings from Stackdriver (Uptime Check). This check prevents AppEngine from scaling to real zero even if there are no real requests to it.

Please let me know if you would like to rollback all these changes. Stackdriver you have to fix by yourself because I don't have required access to configuring it.

[ngulamai]

Hi I propose that you only rollback 2 (resident instance) because we agreed that the spikes in latency is manageable at this stage of the project.

Regarding 1, I understood that you were using the flexible, not the standard environment. Why is the reason for that?

I would propose to change to a Flexible Environment https://cloud.google.com/appengine/docs/flexible/ https://cloud.google.com/appengine/docs/flexible/ to understand if we can save some money and simultaneously fix a few things regarding performance. In parallel we will start sending a bit of additional traffic, to test how the standard environment works vs flexible

Thanks

On 18 Dec 2017, at 15:33, akolchin-MM notifications@github.com wrote:

we are seeing that App Engine is consuming lot's of recources. Provided that the traffic that we are sending during this test phase is minimum, we would need you to review the overall setup to reduce costs.

This is the core point - this costs values for now slightly depend on traffic you are still sending to it. It is mostly the zero level. In other words, if you will increase traffic in 10 times, costs will not rise in 10 times.

Costs increased in comparison to the beginning because I tried to resolve some issues by adding more resources:

I have increased instances type from F1 to the F2. This led to fixing #2 https://github.com/ngulam-ai/Sherlock/issues/2 issue but also to the increasing costs proportionally. https://cloud.google.com/appengine/docs/standard/#instance_classes https://cloud.google.com/appengine/docs/standard/#instance_classes https://cloud.google.com/appengine/pricing#standard_instance_pricing https://cloud.google.com/appengine/pricing#standard_instance_pricing Taking into account that this issue raised just 28 times for all the time, I would return back to smaller and cheaper instances class if you don't mind.

I have added two Resident instances trying to resolve #1 https://github.com/ngulam-ai/Sherlock/issues/1 issue. "Auto scaling services use dynamic instances; however, if you specify a number, N, of minimum idle instances, the first N instances will be resident, and additional dynamic instances will be created as necessary." https://cloud.google.com/appengine/docs/standard/java/how-instances-are-managed https://cloud.google.com/appengine/docs/standard/java/how-instances-are-managed I suppose that we also should rollback this change because I don't see the direct impact of it on the latency spikes.

And finally, if you would like that AppEngine will be able to scale down to the real zero you should turn off pings from Stackdriver (Uptime Check). This check prevents AppEngine from scaling to real zero even if there are no real requests to it.

Please let me know if you would like to rollback all these changes. Stackdriver you have to fix by yourself because I don't have required access to configuring it.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ngulam-ai/Sherlock/issues/8#issuecomment-352442090, or mute the thread https://github.com/notifications/unsubscribe-auth/AfvWTfAq0xcX6toFFdcQwxjI4Jo61QcCks5tBnfOgaJpZM4REU3b.

[akolchin-MM]

I propose that you only rollback 2 (resident instance) because we agreed that the spikes in latency is manageable at this stage of the project.

Good, I will do it now. I also advise you to turn off Uptime Check in the Stackdriver.

I understood that you were using the flexible, not the standard environment. Why is the reason for that?

I am using standard environment, not the flexible. Because it is a stable and time-proven environment for App Engine.

I have reviewed once again "Choosing an App Engine Environment" article and I didn't find any reasons to switch this application to the flexible environment. Actually, it recommended being used in very rare and not standard cases of App Engine using. Our case in this terms very usual and well suited for the standard environment.

I would ask you to postpone any attempts to improve performance and cost efficiency for a while until I had provided you solution which will be suitable for you in terms of its completeness.

In particular, we have to complete #5 task first of all.

Only after that, I will be able to freeze the development and to be focused on efficiency improvements.

Trying to apply my efforts in both directions, for now, prevent me to achieve the final result on any of them. Sorry.

Among other, we can't clearly compare results of efficiency tuning if at the same time I am continuing to implement processing algorithm. It both can impact on results. I hope on your understanding.

[ngulamai]

Hi We just deleted the stackdriver uptime checker, so please let us know if things improve without it

We agree with you regarding our intention of trying to improve efficiency at this stage. Hence we propose to park these tickets for a while, until we finish the scope Thanks

On Tue, Dec 19, 2017 at 1:42 PM, akolchin-MM notifications@github.com wrote:

I propose that you only rollback 2 (resident instance) because we agreed that the spikes in latency is manageable at this stage of the project.

Good, I will do it now. I also advise you to turn off Uptime Check in the Stackdriver.

I understood that you were using the flexible, not the standard environment. Why is the reason for that?

I am using standard environment, not the flexible. Because it is a stable and time-proven environment for App Engine.

I have reviewed once again "Choosing an App Engine Environment https://cloud.google.com/appengine/docs/the-appengine-environments" article and I didn't find any reasons to switch this application to the flexible environment. Actually, it recommended being used in very rare and not standard cases of App Engine using. Our case in this terms very usual and well suited for the standard environment.

I would ask you to postpone any attempts to improve performance and cost efficiency for a while until I had provided you solution which will be suitable for you in terms of its completeness.

In particular, we have to complete #5 https://github.com/ngulam-ai/Sherlock/issues/5 task first of all.

Only after that, I will be able to freeze the development and to be focused on efficiency improvements.

Trying to apply my efforts in both directions, for now, prevent me to achieve the final result on any of them. Sorry.

Among other, we can't clearly compare results of efficiency tuning if at the same time I am continuing to implement processing algorithm. It both can impact on results. I hope on your understanding.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ngulam-ai/Sherlock/issues/8#issuecomment-352738442, or mute the thread https://github.com/notifications/unsubscribe-auth/AfvWTfCZVlTEa5RaSERJwtc_X95oqlpgks5tB68tgaJpZM4REU3b .

[akolchin-MM]

We just deleted the stackdriver uptime checker, so please let us know if things improve without it

This should allow App Engine scaling down to zero number of instances if there is completely no request during some period. And yesterday it was really so.

---

During last weeks I have applied some changes to the /collect servlet and I see that it lead also to significant decreasing of a number of latency spikes #1 with the less number of started instances at the same time.

It also could be that these last changes can resolve #2 without increasing instances class (memory) So I would like give it a try. I will return back to smaller and cheaper instances class but if this error appears again I will increase instances class back.

[akolchin-MM]

As it seems to me cost efficiency of App Engine optimized as much as it possible for now.