YJL

Firstly: Hey, GAE team thanks for updating the side-by-side new price info in Billing History.

They just posted an update. (My TL;DR: Still prepare to move out if you have already decided to do so.) Believe me, there will be another flood coming, just see.

In one of my posts, I’ve mentioned that I have an app which receives 2.5M pageviews per month. That is just roughly speaking. It has two versions, the newer one is just a simple JavaScript which is run on other websites.

Which is actually the reason of suffering running out of free quota. I had to cease using GAE processing or that app is easily capped. But the version is different than the original, the original processes and stores data. It’s fairly simple but processing really uses a lot of resources. The original currently serves 80 to 100 websites a day, it still runs just didn’t accept new websites.

It receives close to 200K requests a day, average CPU time is 23 (7 for API), uses 96% of overall CPU time. No errors. Since it uses 96%, I am pretty sure that I would redirect to new script, I think they are compatible. Not really sure, can’t remember last time I updated either of them.

Here is the updated new pricing estimation:

Clearly, I will need to react. 300+ websites (200 from new script) use my stuff, I can’t really just let their viewers see error message saying the BRPS is out of service.

But that’s not all, this blog is also affected. Currently, it uses 26+ instance hours (I have no idea what that means). Basically, the app I uses to serve for this blog only provides static files and font files, though there does have some Python code running for HTTP header setting and checking if request font path is valid. I don’t understand why it costs so much free quota, or it doesn’t just new pricing has much lower quota?

I will need to look into this.

Still not ends here yet. Third app, it uses 24+. Crap! Wait, not yet. Fourth app, 30+. Darn! Get back to your seat, fifth and sixth apps, they have heavy cron tasks. 50+, two corpses.

That’s all, thanks for reading.

<THIS IS A SEPARATOR IN ASCII SO IT WON'T SUCK UP FREE QUOTA>

One thing this personal post says very right, GAE has been in three year preview state. (I only skim it)

This is how I look at it. Three years is way too long and we get tired of it. In the beginning, you were very excited of new feature just being added, bugs got fixed. But as the version number grew, you didn’t even want to download the new version, needless to read the changelog carefully.

You just want to the existing code to continue running as before. You don’t want to use new API or even some experimental hooks, you just can care less how much improved performance you can get by using new stuff.

The old one runs well, why bother to update? Not to mention there might be bug in new thing, who knows when that would explode? Old is stable already, life is exciting already, I need no more surprise.

Free quota now is really free. I used to feel, it’s not easy to use them all if your program is small. Now, it’s like dining at 100$+ restaurant, you eat for atmosphere not the food for your stomach.

Oh, wait, just saw this: “Increased free Instance Hours: We are increasing the number of free Instance Hours from 24 to 28,” does that mean I have one more dessert? Come on, ever heard a word “double?”

“We’re now giving you almost eight weeks before introducing the new pricing,” then I will start tuning.

Starting on October 31st. Anyone with me?

<THIS IS ANOTHER SEPARATOR IN ASCII SO IT WON'T SUCK UP FREE QUOTA>

Edit: a couple of minutes after I hit the publish button, I received the following letter from GAE regarding the recent M/S datastore outage and my app brps.

Subject: Google App Engine application brps affected by unapplied writes

Dear Developer,

During the day of Aug 19th, 2011, Google App Engine experienced a
serving outage that lasted approximately 2 hours affecting Master
Slave application. HRD applications were not impacted. In the minutes
leading up to the outage, we received a number of writes from your
application that we were unable to replicate to the secondary
Datastore. This caused the secondary Datastore to be slightly out of
sync when we began serving traffic as part of the outage recovery
process. We call these type of writes “unapplied writes.” Rest
assured, unapplied writes do not impact the transactional consistency
and have not corrupted your application data.

During the recovery of the failed data center, we were able to produce
a log of the unapplied writes that occurred during the outage
period. As a service to you, these unapplied writes are now available
from within your application’s to make it easy for you to re-integrate
them. We have also developed a number of tools and example on how to
do so. If you are interested in better understanding this logged data
and how you can work with it, please visit the Unapplied Writes FAQ:
http://code.google.com/appengine/kb/unappliedwrites.html

The following application you own has unapplied writes:
brps

You can determine which entities are impacted by unapplied writes by
looking at the Admin Console Datastore Viewer. If you see any Kinds in
the Kind dropdown box with the prefix __unapplied_write__, this Entity
Kind has unapplied writes that can be re-integrated.

No action is required on your part; you can choose to ignore these
writes if you choose. We're making these writes available to you
because we want you to know that whenever possible, we take every step
we can to recover any data, complete or incomplete, that you attempt
to store on App Engine.

Additionally, if you have any follow up questions, feel free to fill a
production ticket on the public issue tracker:
http://code.google.com/p/googleappengine/issues/entry?template=Production%20issue

Note that application using the High Replication Datastore for Storage
are not impacted by datacenter failovers, because App Engine commits
data synchronously to multiple datacenters before returning to the
applications.

We strongly suggest you to migrate to HRD to prevent future datacenter
failovers to impact your application.

We are about to release an improved HRD migration tool, if you haven’t
already we strongly encourage you to signup for early testing here:
http://goo.gl/3jrXu

We apologize for any inconvenience this may have caused you and thank
you for your continued support of Google App Engine.

The App Engine team

© 2011 Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043

You have received this mandatory email service announcement to notify
you about important maintenance for your Google App Engine
application.

IDGAD. Archived.