On Thu, Jun 28, 2012 at 2:45 PM, Gordan Bobic <[email protected]> wrote:
> On 06/28/2012 02:29 PM, Adrian Hardy wrote: > > The first thing I wanted to do when I got redsleeve on my >> Raspberry Pi >> was see how it coped with a web dev stack, or however close I >> could get >> to it. I've recompiled a few lightweight alternatives to Apache, >> php and >> mysql >> >> >> Cool stuff. Do you have a basic benchmark comparison between the >> standard Apache/PHP and NginX/PHP-FPM? >> >> >> My main motivation is memory. The footprint for a single NginX worker is >> about 4MB, and then you've got each PHP-FPM worker rolling in anywhere >> between 2MB and 5MB depending on which PHP modules you enable. The >> problem with apache is that mod_php (+ all extensions) must be loaded in >> for every single request, even if you're only requesting a .css file. >> This is not very memory efficient. >> > > True, but the Apache threads are "universal" and long-lived. Since each > thread can do any required task (static file or php program) and doesn't > get reaped for hundreds or thousands of requests, I'm not sure the gain you > mention is that great. > > On the memory footprint, can you provide some process size figures between > standard apache/php and nginx/php-fpm, after, say, a hundred requests to > the dynamic php content? I'll have a go. I realise that all my assertions are heresay, but at least I've now got the RPMs to either disprove or prove my claims :) I did a comparison a while ago not on ARM, I've suffixed that to the bottom of this email. > All that said, NginX is documented >> to be faster than apache for serving static files, but about the same >> for PHP. >> > > Link? Including figured on ARM? > I had assumed that the benefits would carry through to ARM - perhaps that's not a wise assumption. The stats I have are at the bottom of the email. > > > and put them on rpms.adrianhardy.co.uk >> <http://rpms.adrianhardy.co.uk**> >> > <http://rpms.adrianhardy.co.**uk__<http://rpms.adrianhardy.co.uk__>>, >> which works as a YUM repo. >> >> >> Could you roll up something like adrianhardy-release rpm that brings >> the yum .repo config file and keys (if you are signing the packages) >> for your repository? >> >> >> There's a lot that needs to be done to the packages before I sign them - >> > > No rush, I didn't mean "right now". :) > > > php-fpm RPM is still trying to chown directories using "apache" and I >> should also mark the RPMs with .ah. somewhere to show they're not stock. >> > > I see, taking a leaf out of RepoForge's book (they postfix their version > tags with .rf.). I'm not sure what the right thing to do is - we're not porting/supporting EPEL, so they're not official releases. I don't necessarily want to put .ah. in there so I'm not sure how to convey that they're not "official" and people should not assume that they will work with other upstream RPMs. Or is it just a case of "we're all adults, we handle it if something goes wrong". > > I'll read up on making an RPM from scratch to make the .repo file (I >> normally butcher other people's SPECS, rather than make them). >> > > Off the top of my head, if it's just some static files it is sufficient to > copy them to BUILDROOT and list them in the %files section. RPM will then > do the rest of the work for you. > > > What I'd *really* like to do is figure out how to make it so that the >> php 5.4 SPEC file I've used doesn't compile apache, apache-zts, etc etc >> which could trim the compile time down to about 4 hours. The problem is >> I don't know what I'm doing ^H^H^H I'm not an expert. >> > > Hmm, I haven't looked at the php spec file you speak of, but I would > imagine it would involve a bunch of --without options to ./configure and > pruning the corresponding entries from %files. But you may want to test > that on a fat x86 box until you get it right, as waiting 25 hours for the > build to complete just to find out that you left an extra line in %files > sucks. For what it's worth, I understand that pain - troubleshooting kernel > builds on ARM is painful. Doing the same with OpenOffice is excruciating. When I first started out with this endeavour, I kept getting OOM errors during compilation so I started hacking away at the SPEC. While I was there, I started removing targets to try and speed the process up. I eventually gave up, added some swap (using a memory stick) and let it compile overnight. Now that I know it will compile given enough memory, I can, as you suggest, mess around using a desktop. > Thank you for the interest. I'll keep the list posted of any updates. >> > > Please do. > > --- Hope this formatting comes through. Apologies to any mutt users. This is processing 40,000 requests with a concurrency of 50. Hardly a real use case for a raspi, but this was for something else on an x86 box. *HTTP kb* *+ PHP-FPM kb* *PHP (sec)* *STATIC (sec)* apache 94844 16.428 4.94 cherokee 39608 97560 18.77 2.77 nginx 4958 62910 16.85 2.68 Php-fpm 57952
_______________________________________________ users mailing list [email protected] http://lists.redsleeve.org/mailman/listinfo/users
