Not logged in. · Lost password · Register
Forum: General Help and Support Features and Functionality RSS
Optimizing dokuwiki load time
Avatar
baryluk #1
Member since Dec 2011 · 3 posts
Group memberships: Members
Show profile · Link to this post
Subject: Optimizing dokuwiki load time
Hi everybody.

I use dokuwiki for about 7 years now, in multiple projects and pages, and often I'm irritated by page loads.

I have somehow slow server, and slow network connection, and was wondering if loading of dokuwiki pages can be improved.

I performed some analysis using commonly available tools, and many design decisions are very good, but there is still few areas where we can improve page load substantially.

Some optimizations are about default template, but some of them are independent of it, and everyone will take benefit.

So I performed some tests and found few places where great improvements can be done:

1. Serve remote images directly without redirect. This can be accomplished by caching remote images directly in dokuwiki cache, this also helps if remote image is removed without our knowledge. Other solution is to fetch remote resource by dokuwiki code itself on the fly, than to use web browser for this. It can increase load on dokuwiki server, but can be beneficial especially if resource is on the same domain as dokuwiki host. (load and bandwidth will be the same, but latency will improve).

Example: http://smp.if.uj.edu.pl/~www-wiki/wiki/lib/ex…?w=60&…

AFAIK, there was option for caching locally on server remote images, but this doesn't work anymore for some reason.

2. Merge buttons on bottom of the dokuwiki template, and use CSS sprites. Currently there is from 10 to 20 small images on dokuwiki, and it would be better to merge this 20 images each about 1kB into single image of about 20kB and perform single request.

Example: http://www.dokuwiki.org/lib/tpl/default/images/button-xhtm…
http://www.dokuwiki.org/lib/tpl/default/images/button-css.…
http://www.dokuwiki.org/lib/tpl/default/images/button-php.…
http://www.dokuwiki.org/lib/tpl/default/images/button-dona…
http://www.dokuwiki.org/lib/images/license/button/cc-by-sa…  (this last harder, because license can be changed, but still this sprite generation can be done once, and cached on server).

This can be easily turned into css sprites. And will make difference.

There is also multiple icons on page, for example, near each link (internal, external, wikipedia, dokuwiki, mailto, file), but do not know if this can be turned into sprites easily (IMHO it should improve load, because there is small number of them, and if some of them are not used, it will not provide big overhead; however it can be technically hard to do, because of how currently this links are styled).
Example: http://www.dokuwiki.org/lib/images/interwiki/wp.gif
http://www.dokuwiki.org/lib/images/interwiki/doku.gif
http://www.dokuwiki.org/lib/tpl/default/images/mail_icon.gif

There is also smiles images. But again, it can be waste to use sprites with all smiles if only single is used.
Example: http://www.dokuwiki.org/lib/images/smileys/icon_wink.gif
http://www.dokuwiki.org/lib/images/smileys/icon_exclaim.gif


3. Make it easy to move static content (i.e. static images) to different domain (so no cookies are sent).

4. Merge all 3 css into single one with @media queries.

Some analysis here http://tools.pingdom.com/fpt/#!/AaJVHDotN/http://dokuwiki.…
and (some older version of dokuwiki)  http://tools.pingdom.com/fpt/#!/bw9n2mn6H/smp.if.uj.edu.pl

Caching of resources, even dynamically generated is done relatively good (explicit 1h cache expiration + etag based on md5 hash of content, which can be quickly rechecked on server). Static content is also nicely cached, by example on apache, by doing Etags based caching (which uses inode number, file size and modification time, to calculate etag). However, first page load, cannot use caching, and it is good to perform as small number of requests as possible. All 4 solutions pointed above by me, can reduce page load time significantly.

What do you think? I think dokuwiki is mature enough to think deeper about some minor improvements now.
Avatar
zioth #2
Member since Jul 2011 · 77 posts
Group memberships: Members
Show profile · Link to this post
In my experience, image loads have not been the main bottleneck. If that was the problem, the page would load quickly, and then you'd see images appear one by one.

I think the real problem is that the initial generation of the cached file takes a very long time on a slower server or a server with high load. If you have a popular web site, this isn't such a problem, since cache isn't regenerated very often, but on a site where each page is only visted every few days at most, the site can be very slow.

I think someone needs to do some comprehensive performance analysis on the code that generates javascript, css and html cache, reads metadata (I've timed that myself and I know it can be made about 10x faster), loads templates and loads plugins. I wouldn't be surprised if Dokuwiki could be made much faster.
Avatar
turnermm (Moderator) #3
Member since Oct 2009 · 4627 posts · Location: Canada
Group memberships: Global Moderators, Members, Super Mods
Show profile · Link to this post
In reply to post #1
Not sure why  caching remote images on a slow server would speed things up.  The page comes to the browser and the browser does the fetching.  If the remote images are on a fast server then you are better off having them fetched from the remote.

Edit

I'm not sure how slow you mean.  But I do lots of testing and often will delete the cache entirely, and while there may be a bit of a delay, because there's no cache, it's not especially noticeable. However, I am not testing on high volume sites.   The speed difference would show up in relation to the site's volume.
Myron Turner
github: https://github.com/turnermm
plugins, templates: http://www.mturner.org/devel
This post was edited on 2011-12-16, 02:44 by turnermm.
Avatar
baryluk #4
Member since Dec 2011 · 3 posts
Group memberships: Members
Show profile · Link to this post
> Not sure why  caching remote images on a slow server would speed things up.

Well, it do not need to be really remote, it is "External" to the wiki, in my case it is fact it is same server, and current behavior is just like redirect to same server. Turning such option, that server fetches image, than browser can be faster or slower, depending how fast server have connection, it may be better to fetch using server, than fetch using browser. It will be beneficial if "remote" image is in fact local server, by reducing number of requests done by browser.

It is currently pretty slow, test this:   http://smp.if.uj.edu.pl/  (it is on 10Mbps, but on virtual host, with 500MHz, 320MB, and php-cgi + sudo-exec. It can download files from same domain with something like 3000Mbps without problem, because it is same machine). Performance analysis here: http://tools.pingdom.com/fpt/#!/bw9n2mn6H/smp.if.uj.edu.pl . It is clear to me that changing fetch.php cals here to return actual image, than redirect will speed things up.

Any way, you just commented point 1., how about 2, 3, 4?
This post was edited on 2011-12-16, 17:01 by baryluk.
Avatar
baryluk #5
Member since Dec 2011 · 3 posts
Group memberships: Members
Show profile · Link to this post
I found that setting $conf['fetchsize'] = 1024*1024; is enough to actually enable wanted behavior! :) I also had small DNS/NAT problem, and actuall request to same server from server was rejected, I added nacassary entry in /etc/hosts, and now it works.

It is especially important, if we reference 'external' image, but want also to resize it in the same time. By caching and resizing it on server, we can serve it much faster! It is also usefull if external image for some reason is delete from original location.

There is still small bug in media_get_from_URL, because if for some reason request was failed (due body size bigger than fetchsize limit, or different mime type was received, or if timeout of 25s was reached), then we are still asking browser to do this, and we will perform request again on next page view (because we do not cache negative results, only positive ones).

Big load time improvement:
Old: http://tools.pingdom.com/fpt/#!/bw9n2mn6H/smp.if.uj.edu.pl
New: http://tools.pingdom.com/fpt/#!/B9Z1uK6An/http://smp.if.uj…

Now we see only 24 request served in 10 seconds, than 33 requests served in 13 seconds. It still can be performed by about 1 request, and 1 second if negative caching will be employed. For unknown reason, pingdom gives me now lower performance grade (it says browser side caching is broken, but i tested it in Opera, and it works perfectly only single request is sent to main page, rest is served from cache, if I reload page, then opera sends requests for all resources, but for each one it recives 302 Not modified, response, and serves media from cache anyway).

I guess pingdom says that 1h is too small, and I agree. Few resources have 1h expiration, some other 24h, which all is somehow to low IMHO.

So almost perfect :)

Now, how about 2, 3, 4?
This post was edited on 2011-12-16, 18:20 by baryluk.
Avatar
turnermm (Moderator) #6
Member since Oct 2009 · 4627 posts · Location: Canada
Group memberships: Global Moderators, Members, Super Mods
Show profile · Link to this post
2. First I've never used sprites myself but I do understand the principle.  How many images will appear on your main page will depend on the template you are using.  The default template uses images only in the footer, and you can eliminate those if you choose to do so.

3.  Not sure what you are referring to.

4.  By default, Dokuwiki merges all  css, including plugin css, into a single compressed file. It does the same with javascript.  Check your configuration settings.
Myron Turner
github: https://github.com/turnermm
plugins, templates: http://www.mturner.org/devel
Avatar
ach (Administrator) #7
Member since May 2006 · 1909 posts · Location: Folkestone, UK
Group memberships: Administrators, Members, Super Mods, Wiki Managers
Show profile · Link to this post
In reply to post #1
Quote by baryluk on 2011-12-14, 18:47:
1. Serve remote images directly without redirect. [...]
AFAIK, there was option for caching locally on server remote images, but this doesn't work anymore for some reason.

As you found out by now, the fetchsize config option fixes that.

Quote by baryluk on 2011-12-14, 18:47:
2. Merge buttons on bottom of the dokuwiki template, and use CSS sprites.

The new config option cssdatauri is your friend. :) This is available since Angua (currently in RC stage).

Quote by baryluk on 2011-12-14, 18:47:
3. Make it easy to move static content (i.e. static images) to different domain (so no cookies are sent).

That's a good point. I think it's a good idea to implement a config option to easily change the path to all static content. (Obviously, the syncing to a CDN server needs to be done by an external source.)

Quote by baryluk on 2011-12-14, 18:47:
4. Merge all 3 css into single one with @media queries.

That's something I've been thinking of doing for a long time now. There are other things which need to get improved in regards to the CSS and JS dispatcher. We are planning to do something about that either for the next release (April 2012) or the one after that (October 2012).
Avatar
turnermm (Moderator) #8
Member since Oct 2009 · 4627 posts · Location: Canada
Group memberships: Global Moderators, Members, Super Mods
Show profile · Link to this post
Very instructive.  Thanks.
Myron Turner
github: https://github.com/turnermm
plugins, templates: http://www.mturner.org/devel
Avatar
ach (Administrator) #9
Member since May 2006 · 1909 posts · Location: Folkestone, UK
Group memberships: Administrators, Members, Super Mods, Wiki Managers
Show profile · Link to this post
In reply to post #7
Quote by ach on 2011-12-18, 16:49:
Quote by baryluk on 2011-12-14, 18:47:
3. Make it easy to move static content (i.e. static images) to different domain (so no cookies are sent).

That's a good point. I think it's a good idea to implement a config option to easily change the path to all static content. (Obviously, the syncing to a CDN server needs to be done by an external source.)

To keep track of this idea, I just added a feature request here: https://bugs.dokuwiki.org/index.php?do=details&task_id…

Quote by ach on 2011-12-18, 16:49:
Quote by baryluk on 2011-12-14, 18:47:
4. Merge all 3 css into single one with @media queries.

That's something I've been thinking of doing for a long time now. There are other things which need to get improved in regards to the CSS and JS dispatcher. We are planning to do something about that either for the next release (April 2012) or the one after that (October 2012).

This has been implemented in the latest release "Adora Belle". (Although more improvements are planned).
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please enter the word from the image into the text field below. (Type the letters only, lower case is okay.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-05-23, 03:59:33 (UTC +02:00)