Perfect, and a really great site btw. Highly commended
On Wed, Sep 30, 2009 at 6:45 AM, GregF g.fawc...@gmail.com wrote:
On Sep 29, 3:32 pm, Roy Smith roy.smith@googlemail.com wrote:
Since I've never seen my app during maintenance, can you elaborate on the
nice message bit? Are all
A Very good point re. Google changing the cpu usage formula.
Unfortunately we have to pay when Google change the formula. It would
be great if they could tell us if this is true and why.
Your points on what effects api_cpu usage the most seem spot on.
I've stripped back my indexed fields to
Touche! An apt point. The current frequent planned maintenance is a
nuisance, but we warn customers ahead of time and present a nice
message to users explaining what is going on.
Since I've never seen my app during maintenance, can you elaborate on the
nice message bit? Are all GAE apps
On Sep 29, 3:32 pm, Roy Smith roy.smith@googlemail.com wrote:
Since I've never seen my app during maintenance, can you elaborate on the
nice message bit? Are all GAE apps disabled, or are they allowed to run
with reduced functionality? If the latter, is there any systemic information
I did have indexed=False at strategic places ;) However, 5 properties
were listproperties (updates were hourly).
It's mostly annoying that something I have very little control over
turned out to be the most cpu intensive part of my application.
On 28 sep, 02:31, GregF g.fawc...@gmail.com wrote:
GAE doesn't suck. But...
I've really enjoyed building my first GAE project. It does almost
everything I want it to do and so far its seems responsive and
reliable enough. But it is expensive in terms of api_cpu - which is
billable. The vast majority of my quota is used making api calls in
After looking at the reported api_cpu usage numbers for so long, I am
convinced that the usage is estimated with a formula or model. It
varies over time, maybe depending on server condition in that time
period.
For example:
1 put - 66ms
10 batch put same object- 666ms
100 batch put same object
I'm not seeing the same issues as you - I have more objects but you
didn't specify how frequently you update, so maybe that's where the
difference is.
Dumb (of me if you have, of you if you haven't!) question - have you
added Indexed=False to your model properties? This can make an
enormous
the 2nd method makes sense to me. the 1st method looks to me like playing
russian roulette with my data; it is twice as fast when everything is
working but what if memcached crashes? memcached is not fault tolerant and
it was not design to be, after all, its just cache. i think there are
Biggest problem: The datastore is deadslow and uses indane amounts of
cpu. I found 2 ways around it, backwards ones imho, but if it works,
it works.
Maybe my usecase is unique, as it involves frequent updates to the
data (10k records) stored.
1st solution:
Only update the datastore after 2 new
Here's my thoughts on the matter, as posted a few weeks ago
http://joerussbowman.tumblr.com/post/182818817/why-im-dropping-google-appengine-for-my-primary
Basically, it depends on whether or not appengine is the right tool
for the job. If you have a lot of reading/writing to backend
datastore,
thanks a lot for all the comments. i think one comment sums it up
beautifully: Neither Google nor Amazon are idiots so both have their good
and bad points. i think we will go with gae for the prototype but keep the
datastore bits separated just in case the need to switch to ec2 in the
future.
About the link from the OP:
I can confirm better performance than that. I manage a web API on App
Engine that reaches 80-90 hits per second every day during peak load.
About 2/3 of the queries are reads, and 1/3 are write/read combos
reads (6-10 CPU seconds' worth per request).
On Sep 25, 1:08
Having administered a small (4 machine) cluster for a minor web app, I
appreciate what it takes to do the job properly. EC2 takes hardware
out of the equation, but you still need to know your OS, middleware
and database like the back of your hand, and you need to continuously
manage it. Scaling
Well, unless it's a maintenance Tuesday when you appear on Oprah then
you'll wish you were on EC2 and could roll out a couple of extra app
servers :-)
I think you express a balanced view point, GAE has some severe
limitations that make it unsuitable for a large variety of
applications. EC2 is
I am not struggling. I really like the idea of GAE. I would be happy
to have reliable automatically-clustered web applications.
The only problem is that it's not as reliable as I would like. Any
request might fail at any point, and that fades the initial shine of
GAE.
On Sep 24, 9:04 pm, Brandon
On Sep 26, 7:51 am, Rob robert.osbo...@gmail.com wrote:
Well, unless it's a maintenance Tuesday when you appear on Oprah then
you'll wish you were on EC2 and could roll out a couple of extra app
servers :-)
Touche! An apt point. The current frequent planned maintenance is a
nuisance, but we
An email address or a form to submit issues, or an IRC channel would give
more confidence
Appengine Has WAY better support than any other Google product. If you post
to this list server Nick , Jason, and Jeff are good about responding.
Adsense, and Webmasters has awful support. And Adwords
It's written by a PHP/LAMP guy struggling with the language, not the
service.
GAE vs EC2 is really about what are you doing with the platforms. There are
even cases where you may want to do portions of an application that run on
GAE, and others that Run on EC2.
For Instance. I'm using GAE to
We moved our corporate web site ( http://www.kaon.com ) to GAE
recently. It's mostly static content, with some simple dynamic stuff
for events, press, etc. Performance is way up over our old hosted PHP
environment, and the read-only stuff has continued to work through all
the
Hi,
There is some truth to it. One thing the article does highlight
is that you have to write things the appengine way. For people coming
from a RDBMS background thats a hard thing to swallow. The counter
example for instance. The GAE team recommends a sharded approach to
it. Yep that
There are some grains for truth, however he fails to detail the effort
you need to put in to build a moderatley reliable system let alone one
that can with stand
multiple failures.
That alone is worth the price of admission.
Try building a linux ha cluster with load balancing, failover and
On Thu, Sep 24, 2009 at 7:27 PM, Tim Hoffman zutes...@gmail.com wrote:
There are some grains for truth, however he fails to detail the effort
you need to put in to build a moderatley reliable system let alone one
that can with stand
multiple failures.
That alone is worth the price of
That's interesting you mention Erlang: I was working on building an
Erlang based App Cluster around the time when AppEngine was announced/
released. You can achieve a much higher handlers/cpu or handlers/
memory density using Erlang because each handler is a green thread
with cheap context
On Thu, Sep 24, 2009 at 11:49 PM, Robin B robi...@gmail.com wrote:
That's interesting you mention Erlang: I was working on building an
Erlang based App Cluster around the time when AppEngine was announced/
released. You can achieve a much higher handlers/cpu or handlers/
memory density
25 matches
Mail list logo
