costela.net » performance

Re: Making pbuilder just that little bit faster

Leo Antunes — Tue, 29 Dec 2009 22:45:33 +0000

Absolutely, but there are at least two workarounds:

Adding
```
BINDMOUNTS="/var/cache/apt/archives"
APTCACHE=""
```
to your .pbuilderrc, in case you don’t need any special separation of local and pbuilder caches (that’s my case).
Using apt-proxy or the like, which has its overhead, but also its other advantages.

None of them seem all that bad to me, considering the sensible speed improvements to pbuilder, but the ultimate decision probably depends on the amount of disk-access the packages in question need.

Forcing a bit of house-cleaning (old news for most, probably)

Leo Antunes — Thu, 27 Aug 2009 21:24:40 +0000

[UPDATE: why does the internet insist in making my posts embarrassingly obsolete?]

I had seen this Firefox* SQLite VACUUM trick on Lifehacker, but hadn’t done anything about it. Now for some reason I decided to give it a spin, but manually, since the proposed method didn’t work and I had zero patience to try and debug Firefox’s inner black magic.
Regardless, this certainly breathed some new life in the old guy:

#!/bin/sh
find ~/.mozilla/firefox/ -name *.sqlite | while read db; do 
	sqlite3 $db VACUUM; 
done

It’s no miracle, Firefox’s still a juggernaut, but it makes things sensibly snappier. No idea how long this will last, probably depends on the amount of INSERTS and DELETES that go on daily.

But I wonder why they don’t do that automatically. I thought they did and never bothered to check (still haven’t, to be completely honest). It might be to avoid a small hiccup while the VACUUM’s performed, but then again, so many people complain about Firefox being slower then molasses that I can hardly see the point.

Anyway, it’s easy to complain about other people’s work. Gotta keep reminding myself of the old “show me the code!” motto.

* Iceweasel, whatever…

Migrated to lighttpd

Leo Antunes — Wed, 08 Jul 2009 12:21:17 +0000

After toying with the idea for a while I finally managed to switch my humble VPS from apache to lighttpd. The server had been having some strange choking episodes and I wasn’t able to find exactly what caused it, besides knowing it had to do with fastcgi processes bloating up and triggering the OOM killer. It was relatively sporadic, but since the VPS is pretty flimsy, I figured it was worth it to migrate and try to improve the performance a bit.
Plus I wanted to have this long overdue incursion into lighttpd-land more than I wanted to debug the problem…

I also took the opportunity to bust the only SVN code I had lying around (that nasty guck) and imported it to Git, so I could abandon mod_svn and didn’t have to setup a dedicated SVN server.

Migrating the normal sites running on the server was pretty straightforward, including WordPress (thanks to this clever idea to ditch the htaccess-based redirects), but it wasn’t perfect:

I couldn’t make htdigest authentication work, but since it’s nothing serious I just left it unsolved for now.
migrating Trac wasn’t a complete success. Got bitten by this bug which means I had to insert this hack to keep it working like it used to:
url.rewrite = ( "^/trac" => "$0", "^/(.*)" => "/trac/$1" )

UPDATE: actually no, that hadn’t fixed anything, but this did.

Strangely enough lighttpd didn’t really have that big of an impact in the memory footprint. It might be that I just optimized Apache better and that with a bit more fine tuning it would really shine, but I guess I’m expecting a bit too much from the poor VPS.
Anyway, now that everything is set up and a few other tweaks are in place, I hope it’ll breathe a bit of life in the little guy.

UPDATE 2: apparently that clever 404 trick isn’t perfect. I just noticed it doesn’t receive the querystring, which caused my OpenId to stop working. I’ve put a workaround in place, but I must admit this migration wasn’t as smooth as it seemed at first.