PHP that Scales

Presented at GeekCampSG 2013.

Transcript

1. PHP THAT SCALES The Secret to Writing Responsive PHP Web Apps Saturday, 7 September, 13
2. MICHAEL CHENG SENIOR SOFTWARE ENGINEER, MIG33 HTTP://TWITTER.COM/CODERKUNGFU HTTP://GITHUB.COM/MICCHENG HTTP://CODERKUNGFU.COM Saturday, 7 September, 13
3. http://j.mp/phpscales Saturday, 7 September, 13
4. SCALE? • Ability for your application to handle a number of HTTP requests in a reasonable amount of time. • Response time. • Concurrent users. • Total requests. Saturday, 7 September, 13
5. APDEX • Open standard for reporting and comparing the performance of software applications in computing. • Apdex = (Satisfied Count + Tolerating Count / 2) / Total Samples • Example: if there are 100 samples with a target time of 3 seconds, where 60 are below 3 seconds, 30 are between 3 and 12 seconds, and the remaining 10 are above 12 seconds, the Apdex score is: • (60 + 30 / 2 )/ 100 = 0.75 T Saturday, 7 September, 13
6. APDEX Saturday, 7 September, 13
7. WHAT TO FOCUS ON? • PHP itself • Everything else around PHP • Application Design Saturday, 7 September, 13
8. FOCUS ON PHP Saturday, 7 September, 13
9. PROFILE THE CODE • Where is it slow? Find out where the bottle-neck is. • Which part of the call stack in taking the longest time? • Tools: Xdebug, New Relic, XHProf Saturday, 7 September, 13
10. OPCODE CACHING • PHP is an interpreted language. • When PHP file is requested, it is read by PHP interpreter and “compiled” into machine language for execution (Opcode). • Opcode caching reduces the interpretation time by storing the Opcode in memory. • No need for re-compilation = Faster • http://en.wikipedia.org/wiki/List_of_PHP_accelerators Saturday, 7 September, 13
11. ALTERNATIVE PHP RUNTIME • There are different ways of running PHP in a web server. • PHP is fundamentally very fast. But how it runs on the web server has memory impact. • mod_php - easy to install, only on Apache. • FastCGI - some config required, runs on any web server. • PHP-FPM - Alt FastCGI implementation. • Compiled PHP via HipHop Saturday, 7 September, 13
12. USE NATIVE PHP FUNCTIONS • Don’t reinvent the wheel. Read the friendly manual! • Native PHP functions are optimized for speed and performance. • eg. Array functions, sort functions. • Only write it if its not available in your PHP version. Saturday, 7 September, 13
13. EVERYTHING BUT PHP Saturday, 7 September, 13
14. SERVER • Add more RAM (memory bound) • vmstat -n 1 • Use faster HDD (SSD) (I/O bound) • Get faster CPU (process bound) • Get faster network card / more bandwidth (network bound/ high latency) Saturday, 7 September, 13
15. DATA STORE • Indexing your database tables. • Turn on slow query log. • Use a faster data store (in-memory data store = faster read/ write) • Memcache, Redis, MongoDB, Couchbase, etc. • Measure the performance vs your current setup. Saturday, 7 September, 13
16. WEB SERVER • PHP performs very well on Apache because it is part of the Apache memory process. But it gets loaded even when serving that don’t need PHP. • Use separate server for static content (Nginx or CDN). • Distribute the concurrent load (Load balancing). • Caching Server (HAProxy, Varnish Cache). • Try FastCGI/PHP-FPM. • Measure different setup. Saturday, 7 September, 13
17. SHARE NOTHING • Each server performs one role. • Web, Database, Redis, memcache. • Optimize the CPU/memory/disk I/O allocation. • But might result in more network latency. Saturday, 7 September, 13
18. APPLICATION DESIGN • Scalable code is usually quite ugly. • Non-blocking processes - asynchronous tasks, no locking, improve response time. • File caching of views and data. • Abstraction layers - easily switch between standalone or multi- server architecture. • Flush your output buffer as soon as you can. Saturday, 7 September, 13
19. APPLICATION DESIGN • PHP CMS vs General Purpose Framework. • CMS is easy to install & configure. Limited by what they provide. • General Purpose Framework is more open to hacking and alternative ways of doing things. Not easy to setup. Saturday, 7 September, 13
20. CONCLUSION • Don’t pre-optimize. • Measure the current performance of your app. • Measure the performance improvement of each enhancement. Saturday, 7 September, 13
21. RESOURCES • http://developer.yahoo.com/performance/rules.html • http://highscalability.com/ • http://www.quora.com/Server-Architecture • https://github.com/CoderKungfu/php-queue • https://github.com/miccheng/scalingphpdemo Saturday, 7 September, 13
22. QUESTIONS? Saturday, 7 September, 13
23. MICHAEL CHENG SENIOR SOFTWARE ENGINEER, MIG33 HTTP://TWITTER.COM/CODERKUNGFU HTTP://GITHUB.COM/MICCHENG HTTP://CODERKUNGFU.COM Saturday, 7 September, 13