Re: Policy for instance startup

Not been a Googler can't help much with this.
Having said that, I suspect there is a kind of build in algorithm that
does some kind of application profiling taking into acount QPS,
response times, and other parameters which adjusts instance life time,
number of instances to start etc..
This could possibly explain the difference in behaviour between your
staging and production appls.

happy coding;-)

World Countries and IP geocoding API for App Engine

I have been writing here again and again about the inherent problem that App Engine based Applications have in using third party API’s with quota limits based on ip addresses since all of those are served from the same block of ips alocated by Google  © and therefore have to share those quotas with other applications hosted on App Engine using the same service.

Today I am happy to offer a free IP geocoding and world countries information service API and hope this solves to some extend the problem of Server side IP geocoding for fellow App Engine developers.

Detailed service description and more information is provided here : "World countries API"

Happy coding:-)

maximum number of requests that may be handled in a single process lifetime

I was doing some load tests on app engine today when I noticed a new Info message in the logs: "After handling this request, the process that handled this request reached the maximum number of requests that may be handled in a single process' lifetime, and exited normally."

So what that supposed to mean ?
Up to know we new that application instances are automatically terminated after some inactivity time out. If I understand this message well now we know that a process can be terminated after handling so many requests. How many exactly ? is this a new magic number ? Lets hope we will have some definite answers from the always helpful App Engines team.

I am doing some latency optimization (lazy imports) in this app based on the assumption that an instance will stay live as long as there are more requests coming in and I was scared this new number spoils my optimization logic. After some more testing I have found out that this is not true since whatever this number is it must be in the order of thousands requests - so no big trouble in my use case. Still I think App Engine's developers deserve to know more about such parameters, it helps both developers and the platform.

Downloan app code feature or bug ? - download_app

I think App Engines developers community has by a vast majority rejected the idea of code downloading at least as default (opt out) option.
I also do not like the idea of a payable service, since it :

• will complicate the pricing model
• will attract criticism against the platform and 
• help guys who are in the business of doing unreasonable GAE vs S3 vs whatever_looks_like_cloud comparisons happy.

But ... then again who am I to tell mother G what to do ? -:)
( see my post at google-appengine group )

Instances console in App engine's Admin Tools

It seems a new feature has just been rolled out in App Engine's production Admin tools - instances - it shows a view of total running instances along with QPS, Latency and memory used Memory as well as averages for the above values.
There is also a summary of the above in application's dashboard.
It is a very useful feature that will help a lot with application performance monitoring and resolving issues on when and how many new instances are started and killed.
Well done dev team. :-)

Yahoo claims about spam filtering

From Techcrunch :
Yahoo claims -55% less spam than Gmail. 40% less than hotmail.
I am sure that if Yahoo have not been an MS partner the numbers would have been reversed.
Something like 55% less spam than hotmail. 40% less than Gmail.
Any way ... lets wait to hear what MS have to say about those figures.

App Engine scalability issues

There is an issue going on for sometime now about App Engine's scaling capability.
We know that all App Engine's user facing HTTP Requests should be processed within a time-frame of 30 seconds, other wise will throw an exception. That is a rule that started with App Engine's introduction some two and half years ago, and until some time it was the only law applicable as far as I know. Then some months ago a new magic number has been introduced in group posts. It started as 1000ms within which an application has to respond other wise it could not scale properly (No new threads will be started to cope with increasing demand) later this number was lowered to 800ms.
I have raised this issue a month ago here :
" This "800ms" rule started as 1000ms some time ago, now it moved to 800ms and 400ms enters the scene. I am afraid it has became a moving target approaching 0ms too fast. Somebody must stop the bar somewhere."
But I got no reply.
In that thread even "sub-400ms" as optimal number is mentioned by a Ikai L.
Today it turns out nobody stopped the bar, instead this magic number has decreased even further to 700ms which turns my above mentioned prophecy of approaching 0ms a step closer to true. I do agree with all people in this group who complain that this is troublesome and concerning. Main advantage of App Engine is scalability, but this number kills scalability in most practical application scenarios.
It is understandable to raise the bar a little to reflect for advances in datastore latency but talking about 700 and sub 400 ms renders App Engine's scalability irrelevant for most if not all practical use cases.
There are other issues here that I am sure concern a lot of us poor App Engine's developers:

1) The always changing numbers.-I think it is reasonable to expect that an application put into production a year ago should have the same or better scalability  behaviour today or a year from now. I know we operate on a Beta platform so we have to take some risk and follow up and improve our applications when Google changes the parameters under which we operate but we will never be able to catch up with this kind of drastic changes.
2) Transparency - We should be informed about those limits, so we know in advance if what we have in mind is doable with App Engine. I understand there can be some trade secrets for engineering and/or marketing reasons, but still we must be in the loop and at least know basic things that affect our Appls.
Having complained about this I want also to be fair to App Engine and its team. Up to know the usual practice is that most of those limits that affect our applications (quotas etc.) are improving over time not vice versa. This is an exception and I think it must be rectified.