Michal Čihař - Blog Archives for Debian

MediaWiki caching

Steve, I know that caching usually helps. But from all test I've made with MediaWiki installation on phpMyAdmin wiki, I can see that enabling any caching slows things down quite a lot.

With memcached based caching, each request takes about 15 seconds, if I add XCache backend for variables, it slows down things to 10 seconds and I receive same results with file based caching. So it doesn't seem to be problem with memcached, but rather MediaWiki issue. Unfortunately it's quite a lot of PHP code to investigate and I didn't find anything obvious in low level caching interface.

So say good bye to variable caching, opcode cache is enough for now and MySQL seems to handle the load quite well.

XCache in Debian is up to date

Same time I complained about not up to date xcache package, I wrote to current maintainer whether I can adopt it. As he promptly agreed to this, we now have up to date package in Debian archives.

The only thing I messed down is that I did upload in hurry and didn't check which all bugs I can close by it. Today it turned out that all opened bugs could be closed, so I made another upload just to close those bugs ;-).

Xcache opcode cacher

As I wrote in previous post, memcached didn't help as expected with wiki performace, so it was time to look for something else.

Since I'm using lighttpd, I still considered using of XCache, but the Debian package is not really up to date (now it even does not install with current php), so it was too much effort.

But today I decided it's time to try it. I built package from current version (you can get it on debian.cihar.com), installed and it seems to increase performance a lot. Most visible it is on wiki pages, which now take about quarter of time to process. I only hope it won't have any stability impacts, but it survived fine stress tests I did so far.

Mailing lists for SVN commits

If you want to follow SVN commits on some of my SVN repositories, you can subscribe to appropriate maling list, which gets notification on each SVN commit. I hope I set up mailman correctly and everything will work as I expect :-).

This list is also automatically forwared to packages.qa.debian.org, so you can also subscribe there for Debian package changes.

Debug packages for Gammu

As I have problem on getting useful reports from Gammu/Wammu crashes, I realised that having debug package for Gammu is good idea. However looking into official documentation didn't reveal how to achieve this. The wiki seems also miss information about this. Well then it must be something obvious. Fortunately I'm not only one who didn't find it on first attempt and dinosaur already wrote about this.

However I still wonder why this didn't get to some official documentation. For now I wrote down this to wiki, so it is easier to find for anybody else.

How could I ever work without *-buildpackage?

I was always a bit afraid to try those complex tools, but now with switch to subversion, I decided to give it a try. And it payed off. Now package management is much easier and everything is recorded in VCS. Yes I could do it with previously used bazaar too, but VCS migration was the latest impulse which made me try it. Now I can only thank to people who invented these tools.

New subversion repositories

I finally managed to migrate some things to Subversion from Bazaar. This does not yet include Gammu related things (Gammu, python-gammu and Wammu), because they are more tricky to migrate.

However all Debian packaging now can be handled using svn-buildpackage, which makes things a bit easier. Also smaller projects like Ukolovnik, polld and dictionary converter have been migrated.

You can see list of repositories at http://svn.cihar.com/, where is also link to web based browser.

Please note that repositories might change in future, because everything is not yet completely settled down.

Hiding configuration

I know that GNOME is trying to hide as much configuration as possible, but Epiphany today suprised me. I started to use is as default browser some time ago, but now I needed to print something for first time. Everything in my system is configured to use A4 paper, so I didn't expect any problem with this configuration.

Unforutanety Epiphany has separate configuration under separate menu item. I don't know why it is separated from print dialog, maybe to confuse users. Also I have no idea why it has default size Letter. Anyway you can set paper size under Print Setup...

This is really great step for usability.