performance of fetch.php redirects

[janinko]

From https://bugs.dokuwiki.org/2592.html

Make it easy to move static content (i.e. static images) to different domain (so no cookies are sent).
Maybe 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 or a plugin.) Although this might be more complicated with CSS and JS, but it should be doable.

This was suggested here: https://forum.dokuwiki.org/thread/7766

[janinko]

This would significantly help my page load. I have page with a bunch (38) of images served from external domain. Now the page loads 4 seconds and most of the time is spend calling fetch.php that just return 302 redirect. I have set fetchsize to 0.
The amount of time is also incomparably high to the actual image download (200 - 600 ms per fetch.php, 15 - 30 ms per downloading image, units of ms when the image is already cached).

[Klap-in]

Please see also
#1020

[splitbrain]

600ms for a call to fetch.php with a fetchsize of 0 seems excessive. How exactly are you measuring this? Any chance you can profile where the time is spent within fetch?

[janinko]

I measure it using DevTools in Chrome:

(note that the lines are not paired even thoug it might seems like it, e.g. the first fetch.php on the image is asking for i_robe_cold.png not i_pillow_11.png)

Any idea how could I try to profile it?

[splitbrain]

dev tools is a good start. Unfortunately your screenshot is missing all the interesting bits. Like are those external images? Are they going to different servers? How is the time spent? Are there other requests that chrome is waiting for before even asking for the images?

To truly analyse this a profile with xdebug would be helpful.

[janinko]

Single request details from DevTools:

And output from xdebug profiler:
cachegrind.out.002.gz

[splitbrain]

Thanks for the data! It's very helpful. One thing I notice is that the initial DNS lookup is already taking a lot of time, but that's beyond the scope here. Chrome waits 323.99ms for the first byte which corresponds nicely with the profile data which says processing took 306ms.

I only looked briefly at the call tree, however most of the time is spent in two things: autoloading and plugin initialization. And that makes me wonder...

First of all what PHP version are you using? I believe autoloading would greatly benefit from PHP7's opcache. You should enable that if you can.

The only other thing that comes to mind that would be slow in the mentioned two things would be file system accesses. What file system is your wiki running on? What's the memory utilization of the system and the availability of memory for filesystem caching? In the same line of thinking, is this server by any chance a Windows system?

[janinko]

PHP 5.4.16, filesystem xfs, around 3 GB of memory is used for caching right now, 4 GB used by apps out of 7,6 GB total and it runs on CentOS.

[splitbrain]

PHP 5.4 is seriously outdated and also indicates that you are running an old version of DokuWiki - that's a problem.

I have no experience with the xfs file system. From a quick look at wikipedia it's meant to be especially fast for parallel accesses - I wonder if that means it's slower for a single process accessing a lot of files...

My recommendation would be to upgrade to a recent PHP version and enable opcache. That probably speeds up things considerably. If not reopen this ticket.