GAE Free Tier

[Tim Bateson]

I am hosting a php website via the free GAE tier and it is working well so far. We are about to expect more traffic to the site. I am not concerned about bandwidth or storage as I am pretty sure we would be well under the limits for free usage. The main issue I am not sure about is the maximum number of clients that connect to the site at once and how that relates to instances.

I expect around 300-700 devices/users connected at once at peak times, but most of the time we would be < 10. Is there a way to link this to instance usage? Or is that not an issues for the number of devices/users we are expecting

Please do not ask me to look here: https://cloud.google.com/appengine/quotas as I already have :)

[George (Cloud Platform Support)]

Hello Tim, 

Do you mean users sending requests at once? You are right, and I'll respect your wish, not referring you to the already read page, but to "Always Free Usage Limits". You don't have to worry about resources not indicated there, so not measured. 

[Tim Bateson]

Hi George,

The following metric is the one that I am not sure about and how it relates to end users sending requests to load the web pages.

• 28 instance hours per day

Thanks,
Tim

[Anastasios Hatzis]

Tim,

if I understand correctly, your concern is not whether your app can handle so much more traffic, but how the traffic relates to instance hours (that are billed).

There is no general formula to make accurate predictions. But there are some factors you can use to calculate.

• How many devices or requests can one instance of your app handle in parallel? So, if your current daily average is 100 instance hours for 500 clients throughout the day, you probably will need less than 1,000 hours for 5,000 clients per day.
• How well does your app scale with an increasing number of clients? There are factors that your instance hours grow much slower than the number of devices, e.g. if your memcache hit ratio is growing, or you can save money by paying for a dedicated memcache. At least in Python, if thread-safe apps can save money because an instance can handle multiple requests at once (e.g. while it waits for datastore read from request 1, it continues with request 2). Maybe you also have instances running in the background which would run anyway, e.g. a cron-job for an admin task or uptime check, and is not affected by the number of clients. On the other hand, if your app scales worse, you might need exponentially more instance hours for more clients. A typical reason for this would be an increased error-rate (e.g. by writing into hotspots in your datastore causing contention / transaction failures) and for bottlenecked tasks that are not using back-offs. Also see the article Designing for Scale, and if you use Cloud Datastore Avoiding Datastore Contention, and this doc for managing scaling for PHP apps.
• How are these peak-times distributed? Every instance that is started is billed for at least 15 minutes run-time, even when it is idle. The default idle time before an instance is shut down (in auto-scale) is 15 minutes. So, if the peak hits your app every 20 minutes for 1 minute, this would mean that many new instances are launched, working for 1 minute, than idling for 14 minutes, shut down (billed for 15 minutes), and restarted after 5 minutes. In this case it would be cheaper to adjust your configuration so the instances are shutdown only after 20 minutes of idle time or so.

The 28 instance hours per day relate to instance(s) running for 28 real hours of the class F1 (the smallest frontend instances using automatic scaling). F2 would translate to 14 real hours with higher hardware spec, and so on. If you use manual or basic scaling, you use B-class instances that have fewer free instance hours per day. See Instance Classes for the hardware specs.

So, if you think your app will scale more or less linearly, and your future traffic distributes across the day the same as now, just multiply your current instance hours with the factor of client growth you expect. Then just subtract your free instance hours per day.

I hope this was helpful. Good luck!

Ani

[Tim Bateson]

Well just to let everyone know,we burned through our free allocation in an hour. Bandwidth was the issue in the end :)

Now enabled billing and for a $300 credit which was a very nice touch!

I think I will look to move our website to GCP though, as GAE does have limitations in working with native DBs, email with PHP.