WordPress MU

Just wanted to find out if there is any particular reason for using /files/2008/09/myimage.jpg instead of /wp-content/blogs.dir/1/files/2008/09/myimage.jpg?

Apart from the pretty url's is there any other reason for using /wp-content/blogs.php to serve static files?

The reason I ask is this seemingly uses server resources unnecessarily. Nginx can serve millions of static files comfortably with low memory and cpu. By serving these files through php it dramatically lowers the amount of static files that can be served on my server, (unless I use nginx fastcgi cache).

If there is no other reason other than pretty url's for using blogs.php then I may write a plugin to override, this feature so that statics can be served directly from nginx.

Honewatson,

I agree with you and i think it's an interesting approach the plugin you mentioned.

As you say, you can serve much much more static images with nginx that way. I'm using now varnish cache as a front-end to cache all the static stuff (img, css, js, ...) to reduce blogs.php requests

Maybe for security reasons it's better not to publish the id, with those urls you'll know the id of each blog. Other problem could be if you move (export/import) a blog from one wpmu to another, the id of the blog will change, for example so the user would have to change the url of the images in the xml manually.

in any case, i'm also interested on this :)

Sorry for the month-old bump, but we're running an installation that has run into the limitations of handling files in this fashion. We have many audio files that are over 90mb and pushing these files through blogs.php is creating a tremendous load on our server.

I would like to continue using the Add from Server plugin, because it makes the process easier on my users. Honewatson, have you come up with a plugin to access files directly?

Any other ideas?

Thanks,
jason

Honewatson,

I am going to play with serving static content with nginx and had about the same line of thought. Have you actually tried to do this?

I just used nginx fastcgi_cache with a very long cache time for images as a quick fix. This means the first time blog.php is accessed for an image it takes the normal php processing time. The 2nd time nginx bypasses php and serves the image in around 0.0002 seconds. fastcgi_cache can be set to serve the static files for a week or a month etc

More here:

http://bookmarks.honewatson.com/2009/09/02/nginx-wordpress-mu-fastcgi_cache-conf-rewrites/

I have begun testing nginx image filter module which can resize images blistering fast compared to php. This method will be able to resize the images and completely bypass php if set up correctly.

You can serve resized images like so:

/resize/files/2008/10/this-image.jpg?w=300&h=300

/resize/ proportionally reduces the image to a specified size.

or

/crop/files/2008/10/this-image.jpg?w=300&h=300

/crop/ proportionally reduces the image to a specified size and trims extra edge.

The strategy is to set up two nginx instances. One for handling the original files and the other for handling image resizing. The main nginx server proxy_pass to the nginx image server then caches the result.

For subdomains I'm looking at the following in the wp-config.php file:

define( "BLOGUPLOADDIR", WP_CONTENT_DIR . "/blogs.dir/{$_SERVER['HTTP_HOST']}/files/" ); (plus the other define() related to upload directory.)

@fserer - the defines above with nginx rewrites could help solve your problem with large files and bypass php completely.

After testing the above strategy out (nginx as image resizer and totally skipping blog.php) I was able to:

1. Serve around 2500 requests per second of a resized image, nginx resized this image every time. CPU was high.

2. With Proxy Pass Cache (image resized once then served by Proxy Pass Cache) I was able to server around 5000 requests per second.

Testing was done on a 1440 Ram Ubuntu Linode.

I used a define for upload directory in wp-config with each upload directory as the http_host (sub domains is used for directory)

I did a write up here:

http://nginxphp.wordpress.com/2010/01/15/nginx-image-filter-module-mu-wordpress-conf/