[typo] Sitealizer in trunk a bad idea? Bloat and stability issues

Tim Connor timocratic at gmail.com
Fri Apr 13 15:21:50 EDT 2007

Okay, maybe I'm completely off base here, but this seemed like the
best place to check.  Sorry if I step on any toes.  Something in a
recent upgrade seems to have made my typo install a total memory hog -
like way more than it was before, even.  I did an update where the
addition of sitealizer was the most obvious change, and then
everything went tits up.  I'm just picking on sitealizer, because it's
an obvious target, but I have zero firm evidence that is it, and I
might be completely wrong.

I'm trying to get my blog back up after the subsequent downgrade, and
then I'll see if it runs smoother - like less than a couple hundred
megs across 4 worker processes it is immediately consuming upon

I assume sitealizer runs some around filters on each request, or
something similar?  Does it do so on admin requests too, because my
live preview went super extra wonky (even if sitealizer isn't the main
cause of my problem, having it run on the live preview would be bad,
obviously).  Does this not invalidate some of the benefits of the
caching? I know trunk isn't expected to be stable, but maybe sort of
thing should go in experimental?

I understand the wish to add every possible feature, but I figure most
bloggers capable of running typo have google analytics, feedburner,
and their own server side analysis tools already and typo doesn't
exactly have a reputation as the sveltest platform.  In fact issues
keeping typo running on a shared host seem to be one the biggest
common Rails
deployment problems.  Hmm, I wonder if a default base install with a
lot of the "optionals" *coughcruftcough* not on by default would help


More information about the Typo-list mailing list