Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have local ikiwiki on my notebook (with apache as local webserver). When I save an edit the first time after booting and logging in, saving is very slow (but the second time saving is at normal speed). Any idea how to fix this?

Edit:

Click edit the first time:~ 30 Sek. (it says "waiting for localhost")
Click save the fisrt time:~1 min 30 Sek (it says "waiting for localhost")

Click edit the second time: <3 Sek.
Click save the second time: ~4 Sek.

The problem is independent of beeing online or not.

I am using git as backend.

share|improve this question
    
When you say very slow, is it like(close to) 2min? Did you connect to any network during that time? –  John Siu Feb 7 '13 at 2:30
    
@JohnSiu See my edit –  student Feb 7 '13 at 8:58
    
Is "it" your web browser that says "waiting for localhost"? If so, can you try time curl http://whatever-local-uri-is/ and report what you find? –  livingstaccato Feb 10 '13 at 6:39
    
@livingstaccato I did something like time curl localhost/mywiki/ikiwiki.cgi which roughly gives the same results as described above. –  student Feb 11 '13 at 13:35
    
@student Does the same thing happen with http://127.0.0.1/...? What web server are you running? –  livingstaccato Feb 11 '13 at 19:48

1 Answer 1

Since it stores the data in a RCS, it has some extra overhead and if the repository is big or complicated, the hot cache may really make the difference. You could try a dumb readahead in let's say ~/.bash_profile:

find /path/to/repo -exec cat {} \; > /dev/null &

Do check if it helps at all first. If it does, it is enough to run it once, so some extra logic is needed if you want to prevent that. But it wouldn't hurt to leave it either, since just every new shell would ensure you still have the files in the disk cache.

If you are not the only one working on the repository, you can also try recompressing it. Git for example has this available as git gc (garbage collector).

share|improve this answer
    
Thanks, you have forgotten a \; at the end of the line (before &). To avoid permission problems one might use something like /tmp/test instead of /dev/null. Your approach works, the problem is that it takes some minutes to read it ahead (but it doesn't slow down the login process), so it seems to be a good solutions since the laptop is usually running for a few minutes until I use my wiki. The wiki is very large with lot's of images. So it might be a good idea to migrate to another wiki software with significantly better performance. Do you have a recommendation for an alternative? –  student Feb 11 '13 at 13:33
    
I use Dokuwiki everywhere, but I doubt it would help and it does not have SCM integration by default. You could try some other caching improvements like checkng if the Expires http headers are defined or maybe adding some apache caching module. Unless you're editing a page with a lot of pictures, the I/O overhead should not be that big. –  lynxlynxlynx Feb 11 '13 at 13:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.