From owner-freebsd-ports@freebsd.org Sat Feb 13 02:11:29 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29631AA7739 for ; Sat, 13 Feb 2016 02:11:29 +0000 (UTC) (envelope-from jim@ohlste.in) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC8E51268 for ; Sat, 13 Feb 2016 02:11:27 +0000 (UTC) (envelope-from jim@ohlste.in) Received: by mail-qg0-x229.google.com with SMTP id y89so76126556qge.2 for ; Fri, 12 Feb 2016 18:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ohlste-in.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=3+M767eaQYkevKZ+DNWdXh9i72Uu2W5K5vc/K24odZo=; b=urnMB5+ioH0MJqiuFi1px23fIXEsraTp3OIBWwhIBSgswPbjakawLDqc8Hpg8/DlMs fZA+6B6/t8EeVSLC84r5zibp+XVwN6ZtQzpnwDIzwKIFOHvF/MMHD8+cixlKyxroj5Mv JjidFWpNgcH/8BloVj6JNh5a8joDFeNCvfdAoLZGvvIDE0qz4wFADplmPZ6xvbWQ+Gx6 zmYmV6DiZQFCPBsQE6xMlOQR8xWAgqr4adXd9KBaXHoHWbDAWKPGFNm3YCnwmGOL2+nH dMFcDX6fpYrpC2XuwuegqKutdY4Hw6XRneamzyXCy2K+ZbJ0Nd+ktwiYhN/H+hUpyQOp PAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=3+M767eaQYkevKZ+DNWdXh9i72Uu2W5K5vc/K24odZo=; b=P5+URYA/Fhi1slUaLL9n7+Dg2qKIC67IbO1GsostJfOClqLcAstI0bBIYQ2APpLlBu SeDWIlTaBmyhzKz3D4XasLak/o+FWsatKFf8WtjFIxXgThtZxcPtCNLM4HdvKvzrywsE nhhMNXdfaJb9/TQ7k/d2VMrHWkmzCUneP1+kaXXOcZHVGupDvoTE/FuLHSPPk61ZI+3x qh+8Hmyhv000xG+KK/hNsU74FQ5O3ANUFgLF5thYPiYLCfsAnAebg4TIi5eRQRHWrlnX InEd1Vp+bgvZn1gqOXwkUg31Sc34grQBv4U7C9oi3+Xmp2S7tayT7O8adkLo6ChLzHNI IvGg== X-Gm-Message-State: AG10YOTbFYjbiQVsCq0ifXn3RpDZTu59jHpXUhghN5+8XuP8/VqMpsIFNrSe3+ZQ9gcjzw== X-Received: by 10.140.108.181 with SMTP id j50mr5977466qgf.104.1455329486757; Fri, 12 Feb 2016 18:11:26 -0800 (PST) Received: from [192.168.1.18] (pool-96-249-243-37.nrflva.fios.verizon.net. [96.249.243.37]) by smtp.googlemail.com with ESMTPSA id e11sm6693998qkb.39.2016.02.12.18.11.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 18:11:25 -0800 (PST) Subject: Re: PHP7 package? To: Kurt Jaeger 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> Cc: freebsd-ports@freebsd.org, miwi@FreeBSD.org From: Jim Ohlstein Message-ID: <56BE90CC.3000304@ohlste.in> Date: Fri, 12 Feb 2016 21:11:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160211162002.GI46096@home.opsec.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 02:11:29 -0000 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