So here are more generalizations for APP Engine:
Cache Everything:
Your CPU is slow, when profiling weigh the CPU to the memory cost and speed
for things which you calculate often. It is surprising that even simple
stuff denormalized can be so much faster than the complex operation.
GetByID("Sales-and-Shipping-AZ-1599-1lb") takes less than 3 MS out of
Instance memory cache served from a dedicated backend, 10ms from memcache
120ms from data store. You can't do the 4 lookups and the calculation that
fast. So Don't. Remember all your "Complex business rules" are cacheable.
Anything worth doing is worth caching :-)
API Everything:
Concurrency is your friend. Concurrency comes from using the API. Anytime
your frontend is doing API stuff in request 1, Request 2 can do CPU stuff.
To get your maximum Concurrency you want to make requests to the API, or to
backends that function like API's In the above example you would have a
Ship and Tax Calculator "API" that would calc and store data which could be
"Fetched" by ID. The tiering would only calculate it if the answer wasn't
already stored somewhere. During the calculation simpler requests are not
blocked or held in queue.
The above methodology also allows you to reduce your code foot print and
leverage "specialized memory". If an instance can use all 128M of ram for
saved calculations you can serve those calculations very, very quickly. And
you don't have to manage memory or worry about soft limit instance
termination. If you dump the memory to something that can be init'ed on
startup every so often, you can create a setup where you always on infinite
scale non-expiring memory.
Cascade Defers:
Building defers that do defers themselves can sound scary, but this allows
you to do more throttling of tasks in a very well threaded environment. When
you have task of different sizes and use the max concurrent, you can have
big tasks spawn small tasks and have fewer errors in your tasks. This is
also better for leveling out your peaks and valleys so that your app doesn't
get "sluggy" when there is a spin up. This is because if you have natural
traffic your "sluggy" tasks won't spawn as many "fast" tasks. So you won't
use as many instance hours.
Use Specialized DataTypes:
The biggest thing you give up with frameworks is the ability do the really
awesome GQL stuff with special data types.
Did you know you can do queries based on RGB values of your images? I can
find "Images like this" using just appengine API's (sorry that bit of code
is secret)
But let's say tomorrow you wanted to build an Eharmony clone:
SELECT * FROM Person WHERE age >= 18 AND age <= 35 AND "white" IN
potential_races AND distance(location, geopoint(-33.857, 151.215)) < 15)
The Above Means you don't have much to write. You can even use calculated
values which can off load a LOT of CPU cycles.
When you use frameworks however lots happens in the instance rather than in
the API, AND you pay for more queries in terms of both datastore calls and
CPU time.
To me the above list is the reason to do GAE.
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
