X-Sendfile support
|
wagnerp
Joined: 2004-07-26
Posts: 6 |
Posted: Sun, 2008-11-02 17:53
|
|
Hi, I've been using Gallery2 for quite some while now and while upgrading to v2.3 I also wrote up a quick summary about a patch I'm using for more than a year now. It adds support for X-Sendfile to Gallery, which lets the webserver (Apache with mod_xsendfile or lighttpd) send the file to the user directly. This gives a noticeable speed improvement and takes load away from the web server. Philipp |
|
Posts: 32509
Sweet. Do you have any benchmarks showing the benefits of this modification? I'd expect memory usage to go down, CPU usage to go down a little as well, overall allowing for serving more page and file requests / second. The actual impact would be interesting though.
Posts: 6
I knew that question would come up
I did some quick benchmarks, which are pretty impressive overall.
http://philipp.wagner.name/blog/2008/11/its-all-about-benchmarks/
Philipp
Posts: 32509
Thanks, so it's about a 30% win in latency, which is pretty good.
We know about the advantages of a php opcache like xcache for g2. So I'm just interested in the x-sendfile aspect of your benchmarks.
I think your benchmark doesn't do full justice to x-sendfile though since one doesn't see the decreased memory usage. Thanks to freeing the PHP process sooner, there's more memory available. Thus you could change the apache config to increase the maximum number of workers / threads. Or is that number already high enough such that it's maxed out and eating into the swap space in both cases (with and without x-sendfile)?
FYI: For G3 (yes, we're starting from scratch again, see gallery-devel emails), we stop using PHP to serve public files. We'll use .htaccess as image firewall. So we could still use x-sendfile for non-public files.
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage
Posts: 6
That server is pretty much limited by everything (RAM and especially CPU; when running the benchmark I get 100% cpu usage), so I wouldn't expect useful output of any further benchmarking apart from a general trend (and also I don't have much time on my hands for any sophisticated benchmarking right now).
*gg*
Using .htaccess even more makes it more difficult to use other web servers (for lighttpd I already had to work around much of the .htaccess detection and do the rewrite rules myself). Not to discourage you or start a big discussion about it, just as a side note if it pops up in some other developer discussion again. I'm sure most stuff can be emulated with other web servers, too.
Posts: 32509
understood. can you please file your patch at http://sourceforge.net/tracker/?group_id=7130&atid=307130 ?
thanks!
@.htaccess:
even IIS is supporting .htaccess and apache's syntax to some degree now (see http://www.isapirewrite.com/ ).
and compatibility will only improve since it's in the interest of MS.
that's for mod_rewrite and that's all we depend on. i'm sure there must be a similar mod for lighty since mod_rewrite is so popular.
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage
Posts: 6
sure, I filed it at
https://sourceforge.net/tracker2/?func=detail&aid=2219542&group_id=7130&atid=307130
@.htaccess
sure lighttpd supports some kind of mod_rewrite. it looks like that:
The problem is more that lighttpd does not support any kind of per-directory configuration, all config is done inside the main web server configuration. This increases the speed quite a bit. This also makes all changes require a web server reload.
Posts: 136
NGINX also has a type of mod_rewrite support, but doesn't use .htaccess files. I've switched to it from Apache, and am very pleased, although I did have to translate all of my rules.
I don't know how committed the G3 team is to this type of solution; while I recongnize that .htaccess is the only real solution that can be controlled by the webserver (since hopefully a PHP process can't overwrite the web server's config files <g>), it does limit G2 to Apache and IIS (and lighttpd and nginx are growing in popularity, not shrinking). Even some Apache users often prefer to disable .htaccess in order to speed up processing).
That said, I think the idea of not using PHP as an image firewall has a great deal of promise, especially for performance and scalability (mirroring, CDNs, etc).
Posts: 32509
for g3 we're applying the 80/20 rule for most design decisions. if we can simplify things / make things faster for 80% of the prospective users, we do it that way.
we didn't want to give up the image firewall feature (application level file access auth). our solution for g2 was ok, but it's quite slow if you compare it to files that are served by the web server directly. we looked at other alternatives, like two different album folder trees (public and private) putting the public one into the doc root, etc.
all these solutions have major drawbacks. so we ended up with the .htaccess solution. we think it's reasonable.
we might add an option to switch from per directory .htaccess to a a single .htaccess in the root folder. that too has drawbacks (concurrency). but it could make things easier to export those rules into your webserver config.
as for nginx and other high speed (low tech) webservers:
users of such webservers often aren't shy of trying new things, heterogeneous setups. what could work is using nginx for normal g2 requests and other things you want to serve and using apache for g2 file requests (to process the .htaccess mod_rewrite rules).
--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage
Posts: 136
I can't really argue with your design decisions (either on technical level (the highest level I use in programming on a regular basis is the MISRA subset of C; most of my day is spent writing assembly...) or on a user level (as you have much more feedback from users), but I would request that where possible, keep 100% of the audience in mind. You're right that nginx->apache is possible, but avoiding Apache completely is always nice; perhaps suitable documentation (to make it easy to translate the .htaccess -> nginx / lighttpd rules) would be a good compromise.
Posts: 136
Attached please find a patch that provides X-Sendfile (or X-Accel-Redirect) for NGINX as well.
Note that the NGINX config is a little quirky; if the g2data directory is outside the webroot (as recommended), it should be referenced in the nginx.conf file as:
location /full/path/to/g2data/ { internal; alias /full/path/to/g2data/; }Posts: 6
@vailant:
it probably should be possible to give the user/administrator a choice between using web server based access control (.htaccess) or let a PHP script (then possibly using X-Sendfile) do it. I don't mean you need to implement that in the first version of g3, but I think if it's needed I (or somebody else) will be able to provide a patch for that. There should not be too much overhead of using PHP together with X-Sendfile for access control if checking the permissions does not require the whole object tree to be built up (e.g. using a static lookup table).
Philipp