Date: Fri, 12 Feb 2016 21:11:24 -0500 From: Jim Ohlstein <jim@ohlste.in> To: Kurt Jaeger <lists@opsec.eu> Cc: freebsd-ports@freebsd.org, miwi@FreeBSD.org Subject: Re: PHP7 package? Message-ID: <56BE90CC.3000304@ohlste.in> In-Reply-To: <20160211162002.GI46096@home.opsec.eu> References: <56B68BFD.20102@buildingonline.com> <56B6B4D4.7000109@gmail.com> <56B74421.3070700@buildingonline.com> <20160207133214.GS46096@home.opsec.eu> <56BCA279.1030409@ohlste.in> <20160211151236.GH46096@home.opsec.eu> <56BCAA68.8060607@ohlste.in> <20160211162002.GI46096@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello,
On 2/11/16 11:20 AM, Kurt Jaeger wrote:
> Hi!
>
>> That's fewer than I'd have thought, but there are also ports like
>> php56-redis which don't show up as "pecl" though they are in the PECL
>> repo.
>
> Then we have to add them manually to the 'ports-to-test' list.
>
>> I'd say that in order to be rigorous, all php*- and pecl- ports need to
>> be tested (at least) for compilation against php70 in in a clean system,
>> and it's a good opportunity to update all with current versions. I'm
>> happy to help. Feel free to contact me off list.
>
> Three tests then: build-test, run-test, use-test
>
I've run some initial tests on PHP 7.0 and 10-STABLE in jails. The good
news is I have definitely seen quantifiable page load time improvements
in a small (~150 blogs of varying activity) WordPress Multisite
installation using nginx and php-fpm that I tested using both Pingdom's
page load test and curl's "time_starttransfer" result from nearby and
remote IP's. This is evident even with the use of a Redis object cache
via predis. The bad news is there seems to be a bug in php-fpm. When
started at jail startup it results in the following:
last pid: 61693; load averages: 4.69, 2.11, 1.07
up
13+14:07:02 20:50:42
16 processes: 6 running, 10 sleeping
CPU 0: 37.8% user, 0.0% nice, 61.4% system, 0.8% interrupt, 0.0% idle
CPU 1: 41.7% user, 0.0% nice, 58.3% system, 0.0% interrupt, 0.0% idle
CPU 2: 29.9% user, 0.0% nice, 70.1% system, 0.0% interrupt, 0.0% idle
CPU 3: 42.5% user, 0.0% nice, 57.5% system, 0.0% interrupt, 0.0% idle
Mem: 327M Active, 1531M Inact, 13G Wired, 27M Cache, 236M Buf, 963M Free
ARC: 10G Total, 4367M MFU, 3956M MRU, 691K Anon, 131M Header, 1824M Other
Swap: 8192M Total, 8192M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME
WCPU COMMAND
61600 www 1 96 0 155M 25160K RUN 2 1:41 84.47%
php-fpm: pool www (php-fpm)
61587 www 1 96 0 155M 25160K CPU1 1 1:38 81.88%
php-fpm: pool www (php-fpm)
61588 www 1 96 0 155M 25160K CPU3 3 1:41 77.49%
php-fpm: pool www (php-fpm)
61536 www 1 96 0 155M 25160K CPU2 2 1:44 77.29%
php-fpm: pool www (php-fpm)
61535 www 1 96 0 155M 25160K RUN 0 1:40 76.76%
php-fpm: pool www (php-fpm)
This is fixed by restarting php-fpm. Otherwise these processes will spin
out of control happily consuming 60-90% of each CPU indefinitely. For
now my somewhat less than elegant workaround has been to restart php-fpm
using a cron and a five second sleep after boot. It never recurs, at
least not after 24 hours. I haven't had a chance to look into this
further but am curious if anyone else has noticed it. Note that these
children are spawned inappropriately as there are no requests coming
into this particular jail and pm.start_servers is set to the default of
2 with the default pm.max_children = 5. After restart there are just the
2 children behaving as expected.
--
Jim Ohlstein
"Never argue with a fool, onlookers may not be able to tell the
difference." - Mark Twain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56BE90CC.3000304>