I think the Great Typo Memory Leak of 2006 has been fixed:
It was an interaction between the action cache and all of the other
filters
that we’re using–when the action cache’s before_filter found a cache
hit,
it cancels the rest of the filter chain and returns the cached results
to
the user. Unfortunately, if any of the other filters are saving data in
their before_filter and planning on dropping it in their after_filter,
then
they’re going to cause a memory leak, because the after_filter will
never be
called.
The fix is to straighen out the filter order. I moved the cache’s
filters
to the very outside, and that gave us a big speed boost, as well as
fixing
the memory leak. Longer-term, we need to audit our filters, because
they’re
getting too complex. But for now, I think we’re okay.
I also fixed a bunch of slow DB queries. On my test DB, we were making
almost 300 calls to the DB just to render the index page. We’re back
down
around 40 now, and 21 of those are Blog.find(1), which we should be able
to
get rid of. I killed off two queries that were taking > 3 seconds to
finish
(one for the archive sidebar and one for the index page paginator). By
and
large, we should now be similar to Typo 2.6’s performance, and perhaps a
bit
ahead.
On my laptop, the action cache is up around 25 requests/second on the
index
page, which is around 2M hits/day. Unfortuantely, without the cache it
still takes almost 1 second to render, but I should be able to speed
that
up. Picking a random article page seems faster, 45 requests/sec from
the
cache and about 1.8 req/sec without the cache. I’d like to be able to
serve
5 pages/second from a blog with lots of content on moderate hardware
without
using the cache, but that’s probably faster then we can go right now.
I’ve probably introduced a few bugs while speeding all of this up. I
haven’t tested mysql or sqlite at all yet, although they’re proabably
okay.
Can people please check it out for me?
Scott