in the database, is there an index on `app_key` ? I'd imagine selects are going to be slow on a sequential scan.
If there is a "unique" constraint on the app_key or it's a primary key, that's going to be a performance hit too. Personally, I've found digest/hash style keys to have terrible performance. I would probably have the table like this: id = primary key + serial/auto-increment app_key = unique index i'd grab the app_key at the start of the web-request and note the object id. then i'd do updates using the object id. the database should optimize locating the record by app_key using the index field; and they tend to be faster finding records with an integer key than strings (for your updates) Other than that, this looks to me like an anti-patten. You're not opening/closing new Sessions for every request, but for every Database operation. Your "session" should ideally start at the beginning of the http web request, and end when you're ready to commit/close. Your design will not scale. SqlAlchemy doesn't have much overhead, but you've designed your application in a way that you get hit by virtually all the overhead multiple times on every action. That's your biggest problem. Honestly, I think your best way to improve performance would probably be to toss this module, and start from scratch. the various python web frameworks integrate sqlalchemy differently, but most have recommended practices. I'd start with that. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.