1.
PHP Performance<br />Principles and Tools<br />By Kevin Schroeder<br />Technology Evangelist<br />Zend Technologies<br />I have stickers!<br />

2.
About Kevin<br /> Past: Programming/Sys Admin<br /> Current: Technology Evangelist/Author/Composer<br /> @kpschrade<br />

3.
Follow us!<br />Zend Technologies<br />http://twitter.com/zend<br />http://twitter.com/kpschrade (me!)<br />

4.
Join us at ZendConThe premier PHP conference!October 17-19, 2011 – Santa Clara, CA<br />Conference Themes<br />Cloud Computing<br />Learn about the latest developments in PHP Cloud infrastructure, management and application services<br />Mobile and User Experience<br />Learn how to build engaging mobile apps with the latest PHP technologies and tools<br />Enterprise and Professional PHPExplore PHP best practices, new technologies and practical tips with industry experts<br />Conference Highlights<br /><ul><li>Sessions focused on how to best develop and deploy PHP

5.
Sessions designed for all knowledge levels

6.
Intensive tutorials for accelerated learning

7.
PHP Certification crash courses and testing

8.
Exhibit hall showcasing the latest products

9.
Special networking opportunities during meals and events</li></ul>www.zendcon.com<br />

10.
Quiz<br />Who here is a sysadmin?<br />Who here is a developer?<br />Who here is both?<br />

11.
WARNING!<br />Performance is a HIGHLY context sensitive topic<br />There are no answers here; only possible directions<br />Do not micro-optimize<br />20ms cf. 100ms is not a 5 fold improvement in performance, it is a 5 fold waste of your time<br />Unless you’re Yahoo, Google, Facebook, etc.<br />The perception of performance is as important as actual performance<br />Use the scientific method to find performance problems<br />Observe<br />Hypothesize<br />Experiment<br />Solve one problem at a time and MEASURE RESULTS!<br />

12.
General categories of performance problems<br />

13.
Performance – Database<br />Symptoms<br />Pages take a long time to load with Apache/IIS/PHP using proportionally less of the CPU time compared to DB<br />Causes<br />The list could go on for 4.23x105slides<br />There are so many ways you can screw up your queries<br />Tools<br />Intra-application query monitoring, usually via a DB adapter abstraction layer<br />Zend Server – A distinct group of monitoring options for DB calls in PHP<br />

14.
Performance - Database<br />Possible remedies<br />Simplify your queries<br />Make your queries more complex<br />Tune your database<br />Don’t just automatically allocate more memory<br />Don’t just create indexes<br />Keeping this light because there are other, better, MySQL performance experts (many of them here)<br />

15.
Performance – Network Latency<br />Symptoms<br />Depends on where the latency is occurring<br />Often slow page responses with low CPU usage<br />Causes<br />Network Saturation (probably not too likely)<br />DNS Reverse Lookups<br />TCP Handshakes<br />High number of “hops”<br />TCP Backlog<br />… and much more<br />Tools<br />Wireshark<br />Tcpdump<br />Zend Server – monitor slow socket function execution<br />

16.
The TCP handshake<br />T/TCP SYN + Response Data + FIN<br />T/TCP SYN + Response Data + ACK +FIN<br />ACK<br />

17.
Performance – IO Contention<br />Symptoms <br />Unpredictable and difficult to reproduce page load times, but often corresponds to request frequency<br />Causes<br />Too few spindles serving too much data<br />High write concurrency<br />Insufficient free system RAM<br />Insufficient depth of data directory structure<br />Tools<br />Zend Server (in extreme cases, long fopen() calls)<br />vmstat & top (Linux)<br />System Internals Process Explorer (Windows)<br />

18.
Performance – IO Contention<br />Remedies<br />Increase the number of disks<br />Favor directory depth over width for storing raw data files<br />Increase RAM so read operations can be pulled from memory<br />

19.
Performance – CPU Utilization<br />Symptoms<br />Page load times either correspond directly to CPU utilization or are consistently slow<br />Causes<br />Badcode or over-architected solutions<br />Excessive recursion<br />Excessive IO<br />High server utilization<br />too few servers serving too much traffic<br />Tools<br />top & vmstat (Linux)<br />System Internals Process Explorer (Windows)<br />

20.
Performance – CPU Utilization<br />There are often 2 different paths this will usually follow<br />User time<br />Time spent executing the code that you wrote<br />System time<br />Time spent running functionality that your code calls, such as networking, file system, etc.<br />

21.
Performance – Network Connectivity<br />Symptoms<br />Database or web service calls take long to execute<br />Causes<br />If read functions die unexpectedly, bad network hardware might be a cause<br />Slow DNS queries<br />Full TCP backlog<br />Tools<br />Zend Server – monitor failed calls to socket_connect(), fsockopen() or fread()<br />Wireshark<br />Tcpdump<br />

22.
OO<br />Beware of magic!<br />__get, __set, __call<br />Situations where they are often used<br />When representing another object that it has no knowledge of - I.e. Soap requests, COM objects, Java objects, database tables<br />When there are property-level permissions on an object’s properties. Keeping the properties private and using __get/set to determine access<br />If used sparingly they won’t affect you, but many modern applications have lots of recursion or large underlying architectures that can have unpredicted consequences<br />

23.
!Preg<br />Use preg_match for data checking only when you have to<br />stripos(‘http://’, $website) is over twice as fast as preg_match(‘/http:/i’, $website)<br />ctype_alnum() is almost 5 times as fast as preg_match(‘/^*$/’);<br />Casting “if ($test == (int)$test)” is well over 5 times faster than preg_match(‘/^*$/)<br />Preg will probably not bite you unless you have a lot of recursive logic that depends on it<br />

24.
Tools<br />

25.
OS tools to use<br />Devs are really bad about thinking about the OS<br />Use OS tooling!!!<br />vmstat<br />top<br />tcpdump & wireshark<br />strace<br />Try stracehttpd –X at least once<br />lsof<br />You can map file descriptors found in strace to descriptors in lsof<br />

26.
Zend Server<br />Monitors for several events like slow requests, slow DB calls, high memory usage, etc.<br />Provides the context for those requests<br />Can be configured to provide profile-like data from production installations<br />Has a built in queuing mechanism that allows you to offload non-immediate processing (which can actually be quite a lot)<br />

27.
Do you queue?<br />Offloading long running processes to a queuing system can help make your front end servers scale more vertically<br />Examples include<br />Job Queues<br />Zend Server 5 (http://www.eschrade.com/ tag: job-queue)<br />Gearman<br />Beanstalk<br />Message Queues<br />ActiveMQ<br />RabbitMQ<br />

28.
TODO || ! TODO<br />

29.
What not to do<br />This is not complete!!!<br />“Oh we’ll just cache it”<br />“Our NFS server is just fine for serving PHP files”<br />Use a frigging deployment mechanism<br />“That LIKE query is necessary”<br />You may need to structure your data a little different<br />Don’t make your DB gues<br />You might need to use a search engine instead<br />Zend_Search_Lucene<br />SOLR<br />“Using arrays is faster than objects, we’ll use them instead”<br />“Monitoring/diagnostic tools are too expensive”<br />

30.
List of things to do<br />This is not complete!!!<br />THINK before you code!!<br />Minimize require_once calls/use an autoloader<br />Try to make your architecture more horizontal rather than vertical<br />People from Java backgrounds tend to go more vertical<br />There is often a correlation between long stack traces and poor performance<br />Use Lazy Loading/Load on Demand<br />SPL arrays and such are great for this<br />

31.
List of things to do<br />Use diagnostic tools!<br />Zend Server Monitoring and Code Tracing<br />Some kind of profiler <br />Utilize compiled PHP functionality for iterative complex functionality.<br />Use Ajax<br />Allows you to make a more responsive page by having fast content available immediately and slow content available as it’s ready<br />

32.
List of things to do<br />With multiple service calls, consider batching multiple NB-IO requests<br />Facebook does this, so it must be cool<br />Synchronous requests – 4.2 seconds<br />Asynchronous requests using curl – 1.5 seconds<br />

33.
Fin<br />

34.
Questions?<br />

35.
To contact me after my presentation, text XIK to INTRO (46876)<br />Follow us!<br />Zend Technologies<br />http://twitter.com/zend<br />http://twitter.com/kpschrade (me!)<br />

36.
Join us at ZendConThe premier PHP conference!October 17-19, 2011 – Santa Clara, CA<br />Conference Themes<br />Cloud Computing<br />Learn about the latest developments in PHP Cloud infrastructure, management and application services<br />Mobile and User Experience<br />Learn how to build engaging mobile apps with the latest PHP technologies and tools<br />Enterprise and Professional PHPExplore PHP best practices, new technologies and practical tips with industry experts<br />Conference Highlights<br /><ul><li>Sessions focused on how to best develop and deploy PHP

37.
Sessions designed for all knowledge levels

38.
Intensive tutorials for accelerated learning

39.
PHP Certification crash courses and testing

40.
Exhibit hall showcasing the latest products

41.
Special networking opportunities during meals and events</li></ul>www.zendcon.com<br />

42.
List of things to do<br />Similarly, be careful when dealing with lots of Ajax data<br />Developers running test data often under-estimate how much data their code will send back<br />The browser needs to process that data<br />With large data sets the browser may take a while to update the DOM<br />2 options<br />Use staggered loading<br />Pass rendered content to the browser and attach with innerHTML<br />

43.
List of things to do<br />Be aware of your page size<br />Oracle – 104kb – 861ms<br />Zend – 183kb – 2.4 seconds<br />Microsoft – 238kb – 4.4 seconds<br />IBM – 640 kb – 4.6 seconds<br />There is a relatively direct relationship between the amount of data on your web page and the render time<br />