Make WordPress Core

Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#14833 closed enhancement (invalid)

performance serving static files

Reported by: sdboer's profile sdboer Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.1
Component: Multisite Keywords:
Focuses: Cc:


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)

#1 @nacin
13 years ago

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.

#2 @scribu
13 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.

#3 @scribu
13 years ago

  • Milestone changed from Awaiting Review to 3.1

#4 @jane
13 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.

#5 @nacin
13 years ago

  • Milestone changed from 3.1 to Future Release

Tempting to wontfix, but punting.

#6 @scribu
13 years ago

Related: #15552

#7 @scep
13 years ago

  • Cc scep added

#8 @wpmuguru
11 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 @SergeyBiryukov
11 years ago

  • Keywords needs-patch close removed
  • Milestone Future Release deleted
  • Resolution set to invalid
  • Status changed from new to closed

#10 @nacin
11 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.

Note: See TracTickets for help on using tickets.