Thanks. I caved in and stayed up until 3am last night to add a ton of log.debug() statements across the app.
The culprit was my read-through-caching layer ( built on dogpile ). It was implemented in such a way that SqlAlchemy looked to have issues. The performance on the DBM datatstore was less than ideal. I haven't benched the pylibmc version yet ( which is running on production ). GETs performed fine ( slower than I expected, but generally fine ). The SET operations were a killer though. The speed on this machine was something like 50/s GET vs 10/s SET. With a DBM backend, a "moderate" page is taking 3.5s to generate on an unprimed cache; the same page on a memory backend... .05 s. hitting a fully primed cache was taking under .05s on both backends. -- 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/groups/opt_out.
