Trying to optimize PHP on a T5140
in [Solaris]
|
Prev: zfs snapshort says "dataset is busy". Any better solution than remounting file system ?
Next: Sun v40z + 64bit Windows
From: hume.spamfilter on 4 Feb 2010 15:05 I've got some developers who have obtained a "php benchmarking" script, obtained from http://www.free-webhosts.com/php-benchmark-script.php . They started using this while investigating perceived slowness in their Horde Webmail application. What this script does is essentially summed up as: for($i = 1; $i <= 20000; $i++) { $x=$i * 5; $x=$x + $x; $x=$x/10; $string3 = $string1 . strrev($string1); $string2 = substr($string1, 9, 1) . substr($string1, 0, 9); $string1 = $string2; } So the entire test is essentially a boatload of arithmetic and string manipulation. But I can't really dismiss it as an unfair test, since a webmail client is essentially a pile of string manipulation. Now the T5140s, when running this script, average around 448ms for the 20k iterations when using both Webstack PHP and local-compiled PHP. If I recompile PHP with Sun Studio 12u1 with "-fast" I can get that down to an average of 390 ms. Oddly enough -xipo doesn't do as well, with an average of 404 ms. In contrast, a Xeon box running Linux (2.2GHz) averages 40 ms. Yes, the x86 runs at twice the clock speed; but it delivers ten times the performance (both machines unloaded). Anyone have any suggestions I could look at to make the Suns more competitive? Or at least explain definitively why the Suns do worse? (I've already pointed out that the Coolthreads machines are built for power efficiency and parallelism...) -- Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
From: Andrew Gabriel on 4 Feb 2010 16:10 In article <hkf99g$dl9$1(a)kil-nws-1.ucis.dal.ca>, hume.spamfilter(a)bofh.ca writes: > I've got some developers who have obtained a "php benchmarking" script, > obtained from http://www.free-webhosts.com/php-benchmark-script.php . > They started using this while investigating perceived slowness in their > Horde Webmail application. > > What this script does is essentially summed up as: > > for($i = 1; $i <= 20000; $i++) { > $x=$i * 5; > $x=$x + $x; > $x=$x/10; > $string3 = $string1 . strrev($string1); > $string2 = substr($string1, 9, 1) . substr($string1, 0, 9); > $string1 = $string2; > } > > So the entire test is essentially a boatload of arithmetic and string > manipulation. But I can't really dismiss it as an unfair test, since a > webmail client is essentially a pile of string manipulation. > > Now the T5140s, when running this script, average around 448ms for the 20k > iterations when using both Webstack PHP and local-compiled PHP. If I > recompile PHP with Sun Studio 12u1 with "-fast" I can get that down to an > average of 390 ms. Oddly enough -xipo doesn't do as well, with an average > of 404 ms. > > In contrast, a Xeon box running Linux (2.2GHz) averages 40 ms. Yes, the > x86 runs at twice the clock speed; but it delivers ten times the performance > (both machines unloaded). You're only using somewhere between 1% and 6% of the T5140. > Anyone have any suggestions I could look at to make the Suns more competitive? > Or at least explain definitively why the Suns do worse? (I've already > pointed out that the Coolthreads machines are built for power efficiency > and parallelism...) How many mail users are there going to be? Only one? Run 256 of them in parallel, and compare the total times. If your mail sessions are encrypted, add in a couple of hundred cryto sessions on top (all done in hardware in the T5140 if you use the crypto framework correctly). The Xeon box should be left miles behind. -- Andrew Gabriel [email address is not usable -- followup in the newsgroup]
From: hume.spamfilter on 5 Feb 2010 12:39 Andrew Gabriel <andrew(a)cucumber.demon.co.uk> wrote: >> In contrast, a Xeon box running Linux (2.2GHz) averages 40 ms. Yes, the >> x86 runs at twice the clock speed; but it delivers ten times the performance >> (both machines unloaded). > > You're only using somewhere between 1% and 6% of the T5140. I realize this. I KNOW the 5140 will blow the Xeon out of the water under massive load. But... for that one, single-threaded process... running at half the clock rate you'd expect the process to take twice as long, while the other 127 vcpus twiddled their thumbs because they couldn't help out. The question I'm being asked by the developers is: if the Sun runs at half the clock rate, 40 ms becomes 80 ms, being generous and round it up to 100 ms. Where is the other 290 ms going? Is it being lost to context switching? Is the nature of the way PHP does substring calls hostile to the cache? (I've run into that problem before, though not with PHP...) Something else? I managed to squeeze another 14% performance out of PHP by recompiling PHP with SS12u1 and enabling the -fast CFLAGS. > How many mail users are there going to be? Only one? No, thousands. And I fully expect the Suns to shine in that environment. But we all know that the END user doesn't care that you're supporting a thousand more users than any x86 could... as far as they're concerned, they want one server per user if it means you make the page refresh twice as fast. (I actually commented to the devs that we could replace the two 5140s with 32 Xeon boxes... I don't think the tone of my comment went over well... :) ) > If your mail sessions are encrypted, add in a couple of hundred > cryto sessions on top (all done in hardware in the T5140 if you > use the crypto framework correctly). I wish. The primary application on these machines isn't Horde, but a vendor black box being set up exactly to vendor recommendations... which includes a Cisco load balancer handling all the SSL. -- Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
From: David Kirkby on 6 Feb 2010 03:14 On 4 Feb, 20:05, hume.spamfil...(a)bofh.ca wrote: > I've got some developers who have obtained a "php benchmarking" script, > obtained fromhttp://www.free-webhosts.com/php-benchmark-script.php. > They started using this while investigating perceived slowness in their > Horde Webmail application. <SNIP> > Anyone have any suggestions I could look at to make the Suns more competitive? > Or at least explain definitively why the Suns do worse? (I've already > pointed out that the Coolthreads machines are built for power efficiency > and parallelism...) > > -- > Brandon Hume - hume -> BOFH.Ca,http://WWW.BOFH.Ca/ As as been pointed out, the benchmark you give is single threaded and so would not run this well. There is nothing more to say about that. I just Googled the T5140 and find a broken link, but the dual- processor verssion, the T5240, has a valid link. I use a T5240 myself. I think the blurb on the T5240 could be more accurate and honest. To quote from that page. http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/cmt-servers/031584.htm "Watch the T5240 server blaze through anything you throw its way," Obviously the page describes the parallism, but nowhere does it say the single-threaded performance will be poor, so it is not suited for all tasks. I'm pretty sure, had the information about the poor single-threaded performance beeen noted, then University of Washington would not have accepted the donation of a T5240 by Sun. . A couple of sentences such as "It should be noted the T5240 is not suitable for all applications, and in particular it will not perform well for a small number of single-threaded tasks" It's true to say its key applications are quoted, but I think it would be sensible to point out the limitations. Sun have a habbit of doing this. The spec sheet on the Ultra 27 states it can take take 12 GB of RAM and the RAM runs at 1333 MHz. Nowhere does it say that the speed drops if the memory is over 6 GB. I only found thst burried deep in te service manual. I've got 12 GB in my Ultra 27, and are very pleased with its perforance. The 3.33 GHz processor is faster than any other machine I've used, expect on machines with many more cores, using multi- threaded code. In the case of the Ultra 27, the memory issue is a minor one. In the case of the T5240, I believe a few sentances describing tasks it is not suitable for would be a good idea. If nothing else, it would be someting to point someone at, every time there are reports of poor performance from these machines. Dave
From: ChrisS on 6 Feb 2010 11:35
On Feb 6, 3:14 am, David Kirkby <drkir...(a)gmail.com> wrote: > On 4 Feb, 20:05, hume.spamfil...(a)bofh.ca wrote: > > > I've got some developers who have obtained a "php benchmarking" script, > > obtained fromhttp://www.free-webhosts.com/php-benchmark-script.php. > > They started using this while investigating perceived slowness in their > > Horde Webmail application. > > <SNIP> > > > Anyone have any suggestions I could look at to make the Suns more competitive? > > Or at least explain definitively why the Suns do worse? (I've already > > pointed out that the Coolthreads machines are built for power efficiency > > and parallelism...) > > > -- > > Brandon Hume - hume -> BOFH.Ca,http://WWW.BOFH.Ca/ > > As as been pointed out, the benchmark you give is single threaded and > so would not run this well. There is nothing more to say about that. > > I just Googled the T5140 and find a broken link, but the dual- > processor verssion, the T5240, has a valid link. > > I use a T5240 myself. I think the blurb on the T5240 could be more > accurate and honest. To quote from that page. > > http://www.oracle.com/us/products/servers-storage/servers/sparc-enter... > > "Watch the T5240 server blaze through anything you throw its way," > > Obviously the page describes the parallism, but nowhere does it say > the single-threaded performance will be poor, so it is not suited for > all tasks. > > I'm pretty sure, had the information about the poor single-threaded > performance beeen noted, then University of Washington would not have > accepted the donation of a T5240 by Sun. . A couple of sentences such > as > > "It should be noted the T5240 is not suitable for all applications, > and in particular it will not perform well for a small number of > single-threaded tasks" > > It's true to say its key applications are quoted, but I think it would > be sensible to point out the limitations. > > Sun have a habbit of doing this. The spec sheet on the Ultra 27 states > it can take take 12 GB of RAM and the RAM runs at 1333 MHz. Nowhere > does it say that the speed drops if the memory is over 6 GB. I only > found thst burried deep in te service manual. > > I've got 12 GB in my Ultra 27, and are very pleased with its > perforance. The 3.33 GHz processor is faster than any other machine > I've used, expect on machines with many more cores, using multi- > threaded code. > > In the case of the Ultra 27, the memory issue is a minor one. In the > case of the T5240, I believe a few sentances describing tasks it is > not suitable for would be a good idea. If nothing else, it would be > someting to point someone at, every time there are reports of poor > performance from these machines. > > Dave Not to start a fight between admins and developers, but after admins have thrown more horse-power at a web application it's time to get the developers to earnestly re-look at their own code. I've had our web developers do that after I've exhausted server-side solutions. The developers, more times than not, find a better way of writing their code, and speeding up their apps 2 or 3-fold. In a few instances it was simply changing the logical order of processing their code. I love when they admit defeat. :-) Having a truly open dialog between admin & devs is priceless. Good luck |