Comments below - I'd say that the person who wrote the article did very
little research, or was using some very out of date resources, if that
article was really written in Feb this year.
On Thursday, 18 August 2011 10:57:34 UTC+1, Thomas Wiradikusuma wrote:
Hi guys,
I just stumbled upon this article:
http://www.ibm.com/developerworks/java/library/j-paasshootout
Are these constraints/limitations still valid? (the article date is
April 2011)
GAE forces any application-initiated connection to close after 5 to
10 seconds
URLFetch requests have the following constaints:
* By default, the deadline for a fetch is 5 seconds. The maximum deadline is
10 seconds for HTTP requests and 10 minutes for task queue and cron job
requests.*
I'm not aware of any timeout for datastore connections, other than the fact
that the datastore operation needs to occur within the 30 seconds, for a
user's web request, or within 10 minutes, for cron and task queue
operations.
But its raw performance is often slow.. ..GAE often takes 1 to 3
seconds to respond to database-related requests.
Almost all of my datastore operations happen within 10s of milliseconds,
although this obviously depends on the datastore operation which is taking
place and whether you're querying a vast amount of data. If it often took
that long for database requests, no one would use it! To be fair to the
author, at the time of writing they may have been experiencing a lot of
database latency spikes, as only the Master/Slave datastore was available at
that time. Since May, the High Replication datastore has been available
which has removed a vast majority of these spikes.
One tip: Set up a cron job inside GAE to load your own website every
2 to 3 minutes to keep the JVM active.
Or pay and have Always On, which has been around since last December.
Instances do get spun-up and spun-down on a regular basis, but if you've
built your application well and make use of warm up requests then I'd say
there is no need to use a cron job. Over the coming months, more controls
will be added to the admin control panel to remove this requirement as well,
I believe, as you'll be able to control how many instances are around in the
background to handle user load spikes.
GAE limits the returned dataset of each query to 1,000 rows
This limitation was removed in August 2010.
GAE allows only 100 indexes per table
The default quota per application is 200, although I do believe you can
request a quota increase.
GAE provides no easy way to delete indexes that are no longer in use
You can vacuum the indexes at any time using the appcfg command line tool:
http://code.google.com/appengine/docs/java/tools/uploadinganapp.html#Deleting_Unused_Indexes
doesn't support free text search in the database
True - I believe it's on the road map.
no standard API for directly accessing BigTable, you must write data-
import and data-export logic into servlets inside your own
application, and use your own web interface to import or export data
There is a Remote API for both the Python and Java SDK:
http://code.google.com/appengine/docs/java/tools/remoteapi.html
The Python API has been available since 2009...
some of the components in GAE still feel experimental rather than
production-ready
Hence it's in beta :)
--
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine-java/-/3KmHGGRKL-0J.
To post to this group, send email to google-appengine-java@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
