|
|
|
|
|
by mhusby
5585 days ago
|
|
I guess I can see that argument, but at the same time its so easy to add memcache that it really seems silly not to add memcache for you models at are accessed a lot. Here is a simple user model, adding memcahce is a total of 7 lines. I just cant see the case where you wouldn't add this to start with: from google.appengine.api import memcache
from google.appengine.ext import db
class User(db.Model):
email = db.StringProperty()
password = db.StringProperty()
sessionKey = db.StringProperty()
def userKey(self):
return "User.session="+self.sessionKey
def put(self):
super(User, self).put()
memcache.delete(self.userKey())
memcache.add(self.userKey(), self, 600)
def getCurrent(self, request):
user = memcache.get(self.userKey())
if user is None:
user = User.all().filter('sessionKey = ', request.header.cookie.get('user'))
memcache.add(self.userKey(), user, 600)
return user
|
|
The thing is, if you turn it on right away you never get a chance to see and fix a bunch of low hanging fruit optimizations that can really help you out. You don't know about them until you start to run up against scaling issues despite all your caching. Once you're there, it's not any fun to try to go back, find and fix those original bottlenecks, so you don't have much option but to start throwing hardware at it.
If, on the other hand you hold off and handle your first few scaling episodes by making your queries and code faster, only adding caching after you're not seeing returns from that other stuff anymore, you'll be able to go a lot farther before you have to start adding hardware.