On 06/28/2012 03:15 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.
That's handy, thanks. So no performance difference on PHP, but
significant difference on static content performance, and about 30%
smaller memory footprint. Worth having, I suppose. :)
apache httpd size seems a bit on the large side, though. The httpd
threads running *.redsleeve.org seem to be hovering around the 25MB
mark. I guess the discrepancy could be down to the PHP code being used.
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.
In general, my view on benchmarks is to never trust someone else's
benchmarks unless they have showed in detail their workings. If you can
pick a flaw in their testing, disregard the results completely and do
your own testing.
I guess web stack optimization on *.redsleeve.org is something I should
really look into sooner rather than later. Let's face it, it's only a
matter of time before it gets /.-ed. Having said that, it survived being
el reg-ed without going into meltdown, so maybe it's not that big an issue.
> and put them on rpms.adrianhardy.co.uk
<http://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.
FWIW I have every intention of extending RS by including a port of EPEL.
It's just that there are a few more pressing things (kernels, signing
all the packages) that need to be done for the proper release, and that
takes priority.
Having said that, maybe I should fire off a background mock rebuild of
all the epel packages on a few of the machines anyway, and see how many
actually build... Maybe I'll do that in the next few days...
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".
Opinions seem to be divided. My view is to leave it all as is, with just
the el6 distro tag as it is upstream. If you don't trust a repository to
not break anything (e.g. atrpms, remi) you make sure they aren't enabled
by default. If you trust the repository and their track record is
reasonably clean (e.g. epel, repoforge), you leave them enabled by
default. When you try to install something that clashes, yum will tell
you. If you install something but it's broken, you should have the
details of what was installed in /var/log/messages, courtesy of yum, so
you can always manually back it out.
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.
No swap? Linking will be painful, but at least it won't OOM. Swapping to
the SD card is painful (and it will hammer the SD card into premature
death), but swapping onto an iSCSI block device works pretty well, at
least for me.
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.
Ouch. Try iSCSI over ethernet, if you have another Linux box running
nearby. It should make a large dent in your 25 hour compile time. :)
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
