trac optimization

Hi

due to continuing performance issues (and complaints) about trac speed
ive switched the database to WAL mode. This should make th db signifciantly
faster but iam not sure the database was the limiting factor.
Now reading and writing can proceed concurrently, before writes would block
everything.
One might think "but there wasnt that much changed/writen" this is logic but
not true. The database stores every recent spammer access and everything that
could be a spammer, every session cookie (we have 129379 temporary sessions in
teh ffmpeg trac databse for example). This is bad design arguably of course ....

If you notice any new issue, please report it here.
Ive made a backup from trac before this and we have daily trac backups
if this causes a major issue i intend to rollback to a previous backup and
disable it again. But i expect no major issue, its likely either faster or not.

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

_______________________________________________
MPlayer-dev-eng mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

-----BEGIN PGP SIGNATURE-----

iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZASahgAKCRBhHseHBAsP
q7bbAJ0SoUOTnx/3H5DyiYsbL2Sn6zvZ+wCeL84ZSHIB8lApgEbtkNC1X8EU2wM=
=b3NM
-----END PGP SIGNATURE-----