Dutch php conference_2010_opm
- 1. Common Optimization Mistakes Dutch PHP Conference 2010 Ilia Alshanetsky http://ilia.ws 1
- 2. Premature = Optimization Solve the business case, before optimizing the solution 2
- 3. Don’t Over Engineer • Understand your audience • Estimate the scale and growth of your application (based on facts, not marketing fiction) • Keep timelines in mind when setting the project scope 3
- 4. Simplify, Simplify & Simplify! • Break complex tasks into simpler sub- components • Don’t be afraid to modularize the code • More code does not translate to slower code (common misconception) PHP has grown from less than 1 million LOC to over 2 million LOC since 2000 and has become at least 4 times faster. Linux kernel code base increase by 40% since 2005 and still managed to improve performance by roughly the same margin. LOC stats came from ohloh.net 4
- 5. Hardware is Cheaper! VS In most cases applications can gain vast performance gains by improving hardware, quickly rather than through slow, error prone code optimization efforts. 5
- 6. Hardware • CPU bottlenecks can be resolved by more cores and/or CPUs. Typically each year yields a 20-30% speed improvement over past year’s CPU speeds. • Ability to handle large amounts of traffic is often hampered by limited RAM, and thanks to 64bit, each new server can have tons of it. 6
- 7. Hardware • Drives are often the most common bottleneck, SSD fortunately between RAID and Solid State you can solve that pretty easily now a SCSI days. 7
- 8. Hardware Caveat • While quick to give results, in some situations it will not help for long: • Database saturation • Non-scalable code base • Network bound bottleneck • Extremely low number sessions per server 8
- 9. Optimize, but don’t touch the code • Typically introduces substantial efficiencies • Does not endanger code integrity • Usually simple and quick to deploy • In the event of problems, often simple to revert 9
- 10. How PHP works in 30 seconds PHP Script • This cycle happens for every include file, not just for the Zend Compile "main" script. Zend Execute ire re qu / lude in c • Compilation can @ method easily consume function more time than call execution. 10
- 11. Opcode Cache • Each PHP script is interpreted only once for each revision. • Reduced File IO, opcodes are being read from memory instead of being parsed from disk. • Opcodes can optimized for faster execution. • Yields a minimum 20-30% speed improvement and often as much as 200-400% 11
- 12. Quick Comparison 200 Regular PHP Zend Platform 150 APC X-Cache 100 50 0 FUDforum Smarty phpMyAdmin 12
- 13. Use In-Memory Caches • In-memory session storage is MUCH faster than disk or database equivalents. • Very simple via memcache extension session.save_handler = “memcache” session.save_path = “tcp://localhost:11211” Also allows scaling across multiple servers for improved reliability and performance. 13
- 14. Everything has to be Real-time 14
- 15. Complete Page Caching • Caching Proxy (Ex. Squid) • Page pre-generation • On-demand caching 15
- 16. Partial Cache - SQL • In most applications the primary bottleneck can often be traced to “database work”. • Caching of SQL can drastically reduce the load caused by unavoidable, complex queries. 16
- 17. SQL Caching Example $key = md5(“some sort of sql query”); if (!($result = memcache_get($key))) { $result = $pdo->query($qry)->fetchAll(); // cache query result for 1 hour memcache_set($key, $result, NULL, 3600); } 17
- 18. Partial Cache - Code • Rather than optimizing complex PHP operations, it is often better to simply cache their output for a period of time. • Faster payoff • Lower chance of breaking the code • Faster then any “code optimization” 18
- 19. Code Caching Example function myFunction($a, $b, $c) { $key = __FUNCTION__ . serialize(func_get_args()); if (!($result = memcache_get($key))) { $result = // function code // cache query result for 1 hour memcache_set($key, $result, NULL, 3600); } return $result; } 19
- 20. Compile Your Tools • Distribution binaries suck! • More often than not you can realize 10-15% speed increase by compiling your own Apache/PHP/Database from source. (unless you are using Gentoo) 20
- 21. Output Buffering • Don’t fear output buffering because it uses ram, ram is cheap. IO, not so much. 21
- 22. Matching Your IO Sizes PHP Apache OS Client • The goal is to pass off as much work to the kernel as efficiently as possible. • Optimizes PHP to OS Communication • Reduces Number Of System Calls 22 22
- 23. PHP: Output Control • Efficient PHP Apache • Flexible • In your script, with ob_start() • Everywhere, with output_buffering = Xkb • Improves browser’s rendering speed 23 23
- 24. Apache: Output Control • The idea is to hand off entire page to the kernel without blocking. Apache OS • Set SendBufferSize = PageSize 24
- 25. OS: Output Control OS (Linux) OS Client /proc/sys/net/ipv4/tcp_wmem 4096 16384 maxcontentsize min default max /proc/sys/net/ipv4/tcp_mem (maxcontentsize * maxclients) / pagesize ✴ Be careful on low memory systems! 25
- 26. Upgrade Your PHP • Before “upgrading” your code, upgrade your PHP. Newer versions are typically faster! 150 112.5 PHP 4.4 PHP 5.0 75 PHP 5.1 PHP 5.2 37.5 PHP 5.3 PHP-CSV 0 Speed % (base line of PHP 4.4) 26
- 27. Don’t Assume Assume nothing, profile everything! • One of the most common mistakes made even by experienced developers is starting to optimize code without identifying the bottleneck first. 27
- 28. Profile, Profile & Profile Xdebug and XHProf extensions provide a very helpful mechanism for identifying TRUE bottlenecks in your code. 28
- 29. Kcachegrind Xdebug provides kcachegrind analyzable output that offers an easy visual overview of your performance problems 29
- 30. Database before code • One of the most common mistakes people make is optimizing code before even looking at the database. • Vast majority of applications have the bottleneck in the database not the code! 30
- 31. Watch Your Errors • Excessive, non-critical errors, such as E_NOTICE or E_STRICT can only be detected via error-logging. • PHP code that generates any errors is going to impact performance! Not Easily Detectable by Profilers 31
- 32. Micro Optimization • Takes a long time • Won’t solve your performance issues • Almost guaranteed to break something • Cost > Reward 32
- 33. Speed vs Scale • If you are planning for growth, scale is far more important than speed! • Focus on scalability rather than speed, you can always increase scalable app, by simply adding more hardware. 33
- 34. Don’t Re-invent the Wheel • Most attempts to make “faster” versions of native PHP functions using PHP code are silly exercises in futility. 34
- 35. Write Only Code • Removing comments won’t make code faster • Neither will removal of whitespace • Remember, you may need to debug that mess at some point ;-) • Shorter code != Faster Code 35
- 36. Thank You! Any Questions? Slides @ www.ilia.ws Comments @ joind.in/1535 36