That's why I don't have a caching function included with SQLAlchemy. Because then I'd be debugging it, not you :)
On Sep 26, 2013, at 11:38 AM, Jonathan Vanasco <jonat...@findmeon.com> wrote: > 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
