Terence J. Grant wrote:
I don't use dokuwiki's compression, but apache's deflate handler. I will take a look at what the performance hit is, but I doubt its significant either way. The files aren't particularly big and the processing is not complex. The files are cached anyways, so its highly unlikely there is any sort of impact on the webserver or the client browser.Hi Chris,
If you're looking at bottlenecks, I have a couple that I would like to know about based on my knowledge of the last stable release...
"Compress CSS and javascript files"; I am of the opinion that the benefits probably don't outweigh the costs... is this a potential bottleneck?
Yes they are cached, they communicate properly with the browser returning appropriate http codes to tell the browser if it should use its copy or not. I doubt the cache file is timestamped on each use, it wouldn't be necessary. Both css.php and js.php have appropriate logic to determine whether their cached version is current. In a stable DokuWiki installation, there is no reason why each css or js file would be generated more than once. Given that once is most likely for the wikiadmin during installation, changing of configuration or plugins, there is not likely to be any impact on other visitors.Also, is css.php returning a cached file? Does its time stamp change each time its called, or is it considered "no-cache"? If so there could be some serious bandwidth issues here as well as the browser would be cacheing the file otherwise...
Its not difficult, browse the source on line - splitbrain has the details. Since you only need to follow the cache success track, you're only looking at about 100 lines of php. Probably less than in this thread already ;-)
Or if you're certain these are ok, that's good too; this is just something I've been wanting to investigate myself but I don't think I'll have time before a new release...
Cheers,
Chris
-- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist
