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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
