Put LAMP on a diet

As web programmers, we’ve been spoilt with the luxury of powerful servers as the cost of memory and processing power plummets. The advent of the micro-computer (e.g. the ubiquitous Raspberry PI) has meant that we’re now back to a constrained environment. To paraphrase a famous misquote; “256MB RAM ought to be enough for anybody”. This talk is about getting the overhead of your web stack down. For database and web services and the PHP binaries themselves, we’ll discuss the process of finding lightweight replacements for PHP’s usual entourage. Once the stack is trimmed down, we then need to refocus on our choice of frameworks and even approaches to writing memory and CPU efficient applications. Being sensitive to resource consumption shouldn’t be a novelty. While no-one wants to advocate premature optimisation, if you know what you can squeeze out of PHP’s stack in a memory constrained environment, you should be able to take those principles when approaching a problem more conventional hardware.

Transcript

1. PUT LAMP ON A DIET LEARN FROM THE MICRO-COMPUTING REVOLUTION Adrian Hardy / @adrianhardy
2. WHO AM I Adrian Hardy Lead Developer at Magma Digital (@magma_digital) PHP / MySQL / Linux for 10 years Raspberry Pi owner for 3 months
3. WHAT IS THIS TALK ABOUT? Not a green light for premature optimisation Not a to-do list for production services Learning a few approaches to allow your systems to scale with "modest" hardware Using "micro computing" as a scenario and the motivation to try and squeeze some hardware
4. A NOTE ON BENEFITTING FROM HINDSIGHT Benchmarking is a bitch to get right I had an agenda, I wanted to prove it But the stats were against me It's only made me more curious
5. MICRO COMPUTING, EH? "A real computer for the price of a toy"
6. SUDDENLY, HARDWARE! BeagleBoard, Cubox, Raspberry Pi Affordable, open* and portable hardware Now the domain of the programmer and hobbyist, rather than the electronics expert For my talk, I'll be focussing on the Pi because I own one & it's quickly approaching ubiquity
7. SPOILER ALERT Apache, MySQL and PHP will happily work on a Raspberry Pi with no further modification
8. PLATFORM CONSTRAINTS CPU is under powered, even when compared to a mobile phone So let's make sure the CPU is being used efficiently STORAGE is cheap, plentiful but slooooow Let's avoid disk where possible But using external storage breaks the rules MEMORY is fairly constrained (256MB) memory based caching will make it feel even more cramped, but may be necessary to avoid disk No swap = very hard wall for OOMs
9. THE STACK LINUX APACHE MYSQL PHP
10. LINUX Avoiding the whole "best distro" argument Maybe disto is more important on modest hardware?
11. LINUX - TWEAK use "arm224_start.elf" for a better environment for webservices Deploy usual tricks (noatime, nodiratime, disable services) SD cards are designed for sequential reads/writes Recommended hardware still in its infancy Brand loyalty for PC hardware is firmly in place The community will (hopefully) create a similar ecosystem
12. THE STACK LINUX ✔ APACHE MYSQL PHP
13. APACHE HTTPD Apache HTTPd is still awesome But it's not very resource efficient It doesn't scale well (on a Pi)
14. APACHE HTTPD DEFAULT CONFIG
15. APACHE Uses a thread-per-request model Whether the process is handling PHP or not, mod_php sits there consuming memory Processes sit there waiting for a potential visit Spinning up a new process involves relatively expensive disk lookups
16. APACHE HTTPD ALTERNATIVES Nginx Lighttpd Cherokee Monkey(!)
17. NGINX lighter than Apache HTTPd in memory footprint Faster at delivering static content Faster delivery = more time to do other stuff Lower CPU consumption = more idle time
18. NGINX DEFAULT CONFIG
19. STATS! STATIC HTML - REQUEST TIME
21. STATS! STATIC HTML - CPU USAGE
23. STATS X10! STATIC HTML - REQUEST TIME
25. STATS X10! STATIC HTML - CPU USAGE
27. STAT STATIC HTML - REQUESTS PER SECOND
29. I LIKE NGINX Serves just under 2x the requests in the same time Response time and CPU are more predictable It does it with a fraction of the memory
30. THE STACK LINUX ✔ APACHE ✔ MYSQL PHP
31. MYSQL DeFacto DB server, despite its flaws Fast, well-supported, community-rich
32. MYSQL - SIMPLE TEST Disabled innodb and freed up some more memory Table used in this should be able to sit in memory No joins, sorts, orders so it's just raw speed
33. MYSQL - STATS! Concurrent reads and writes
34. PHP / Nginx are not the bottleneck
35. SQLITE By these estimates, we see at least 500 million SQLite deployments Browsers, Phones, OSes Good enough for me
36. SQLITE - FEATURES It has features coming out of its tiny, well-formed ears transactions triggers constraints(!) foreign keys UDFs
37. SQLITE2 - THE DARK DAYS Used to be very easy to trigger write timeout errors If two processes contend for write access and the first one takes too long to release → exception! SQlite has improved locking model new locking model seems to favour reads I set out to demonstrate this concurrency crash...
38. SQLITE - STATS!
40. SQLITE - QUICK REVIEW Secretly, I had hoped that MySQL would lose horribly 30% read improvement isn't bad LA shoots right up - waiting on IO? Let's test it out
41. SQLITE ON TMPFS Create a temporary filesystem in RAM TMPFS creates a file addressable area of memory Appears to grow as necessary, rather than pre-allocating it Writes fail once you hit that limit We're not constrained by IO any more May need some sort of data-retention solution
42. SQLITE ON TMPFS
44. SQLITE ON TMPFS - STUPID BUT AWESOME Pros We've steadied out read/write disparity Beaten MySQL by almost 2x We have all the missing features from MySQL Cons But LA still goes sky high (1.0+) It's not due to IO wait, so we can't get that LA down
45. THE STACK LINUX ✔ APACHE ✔ MYSQL ✔ PHP
46. PHP WHAT CAN BE IMPROVED? Memory usage CPU usage / speed of execution framework / approach
47. PHP - MEMORY USAGE Disable modules mbstring zip intl phar gd fileinfo
48. PHP - CPU USAGE APC should be seen as part and parcel of PHP Everyone knows APC makes your stuff faster But more importantly, it lowers CPU usage CPU cycles are precious on the Raspi
49. PHP - APC
50. APC is a Good ThingTM
51. PHP - FRAMEWORKS A brief foray into frameworks Not going to benchmark the big boys ZF2, Symfony, Cake Focus on micro-frameworks Clearly, "no framework" is a valid option Lots of anti-framework literature Let's examine two extremes: /hello/$name should output "hello, $name!"
52. ZF2 VS 2LOC 3.65 REQ/SEC - 128.98 REQ/SEC 0.98MB RAM - 0.12MB RAM
53. CLEARLY STUPID Let's aim somewhere in the middle
54. PHP - MICRO-FRAMEWORKS Typically full-stack The next logical step after "hand-rolled PHP" Satisfy three qualities: Speed Low footprint Less code
55. PHP - MICRO-FRAMEWORKS MY STRATEGY No templating No Db Just bootstrap and routing Very hard to benchmark fairly, but I tried anyway...
56. PHP - MICRO-FRAMEWORKS THE SELECTION Silex Slim Fat Free Limonade MicroMVC PhalconPHP (using \Phalcon\Mvc\Micro)
57. PHP - MICRO-FRAMEWORKS REQUESTS PER SECOND - C20 N200
59. PHP - MICRO-FRAMEWORKS FOOTPRINT
63. SO WHO WINS? Code style Speed of execution Memory footprint Dependencies Debugability
64. THE STACK LINUX ✔ APACHE ✔ MYSQL ✔ PHP ✔
65. WHAT NEXT?
66. DO IT ALL AGAIN Different SD card Many more HTTPds out there firebird, postgresql, memcache/redis(!) Rasbian More frameworks, fewer frameworks!
67. A OPEN-SOURCE PI BENCHMARK? self-extracting hardware profile software profile benchmark database
68. QUESTIONS?