#14833 closed enhancement (invalid)
performance serving static files
Reported by: | sdboer | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.1 |
Component: | Multisite | Keywords: | |
Focuses: | Cc: |
Description
What we are seeing with wordpress3 multisite installations (with subdirectory option) is that the references to, for example, .css files inside pages from a blog point to the filesystem under "http://host.domain.tld/blogname/path/to/file.css".
The file in this case is found on the filesystem under "http://host.domain.tld/path/to/file.css".
The requests are then rewritten to php which in turn will serve out the correct file.
What is worrying about this is in situations where the blog gets a
serious number of hits per minute. Files served out by apache directly from the filesystem can be served out by a single gigabit server at wirespeed to many simultaneous clients. This is much less the case for requests processed by php.
In this particular case if the files referenced from blog pages would point to the correct location on the filesystem, you can benefit from the fact that requests resulting from those references don't have to be processed by php.
Change History (10)
#2
@
14 years ago
- Component changed from General to Multisite
- Keywords needs-patch added
I was under the impression that this was already handled directly through .htaccess but now I get what ms-files.php is for.
I agree that this should be fixed. A fix meaning presenting to the user optimal .htaccess code.
#4
@
14 years ago
There are a few days left before freeze if anyone wants to post a patch to try and get it into 3.1.
#8
@
12 years ago
- Keywords close added
Static files the used to be under /files/ will no longer be handled by php (see #19235). Recommending close.
#9
@
12 years ago
- Keywords needs-patch close removed
- Milestone Future Release deleted
- Resolution set to invalid
- Status changed from new to closed
#10
@
12 years ago
I think this original bug report was focusing on subdirectory links (/blogname/wp-content/themes/something/style.css, versus without /blogname/) being rewritten by .htaccess to drop the /blogname/. This doesn't go through PHP, it is handled by the server. So, this is invalid.
If you wanted (as I wrote originally), you could filter things so you could rely on browser caching by making many assets all go through the same central/common URL.
This should actually be rewritten at the htaccess level.
You can optionally filter things like the stylesheet URI really effeectively. I've done that to reduce server load.