High performance PHP: Scaling and getting the most out of your infrastructure


Published on

ZendCon 2010 session on performance optimization tips and best practices

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Public facing, router – then into network. LB cand do natting.
    Examples of hardware appliances Coyote point, Barraccuda
    Talk about load balancer redundancy – no SPF

  • 10X less sytem calls with and without O+. Most of the system calls that are gone are fstat and lstat, which are both file ops.
    We could get even better results by not checking file timestamps.
  • One point to talk about here is Drupal bencchmark O+ v/s APC
  • We released Zend Server and Zend Server Community Edition in April this year
    Products written from scratch based on our very extensive experience with Platform technologies
    Full integrated stack, native installer, ZF and Studio integration, software updates, all new UI, …
    Both editions have been very well received by users (love performance boost, ease of use, deployment)
    Great fit to our partners – we’re working with Varien/Magento, KnowledgeTree, MCS, …
    Next step will round up web app server offering to support high availability and scalability – more on this in the next few months
  • Infobright is one of the exhibitors here at ZendCon.
  • ZF – remember opcode caching?

    Desing in modular way

    Application performance optimization – question to always ask yourself: 1- what am I gaining? 2- would it be cheaper to throw hardware at the problem? 3- how do I prove it. -> if gaining 2X by optimizing but cost is 3X what it would cost to buy a server and gain 1.5 or 1.8 times, decision is relatively easy. Cost v/s gain.

    ORM is going to return results in any way it knows -> up to you to optimize

    Trade-offs of performance v/s code readability and “pretty” architecture. Cf. Martin fowler on Enterprise architecture design patterns.
  • What I mean here is that you need to start thinking about what the app is going to be used for at the early planning stage, because that will define certain design decisions you make.

    If low traffic, I can send 100-200 queries to db per page, they’re really fast. I can therefore use a readable code because at the code level I’m just using my most basic objects to perform CRUD. But if high traffic app, then I need to start thinking, do I really want 100-200 queries to the DB per page, or should I, instead, try to optimize this by designing special objects that perform CRUD specific to this context?
  • A Zend Consultant’s secret weapon: Code tracing. -> DEMO

    Know the hardware:
    If I know the HW I’m writing for, if for example I’m writing a read/write heavy app, and I know that disks are particularly slow, I’ll emphathize caching.

    That’s valid advice for caching too by the way. If a piece of code takes 3 seconds to execute (some kind of recursive menu build), and it takes a few minutes to add caching to it, if the menu does not change often, why bother spending hours rewriting?... Better to just add caching.

    Performance optimization in general is an art, not a science. Like good application design.
  • EXPLAIN is your friend. Using the power of an in application query profiler combined with EXPLAIN, you can tune your SQL statements to the dot.

    Demo: ZFA app (wiki) with the use of Zend_Db_Profiler

    Add indexes where needed, if a query is too intensive on the server, try to take some of the logic out of the query, split it into multiple subqueries and do some heavy lifting in PHP instead of the database.
  • If you are given time, try to optimize before caching. I know I said before that if caching is easier, then go with that, but as with everything, if it’s too easy, you cache and cache, and before you knmow it, well you’re running memcached on a 40 Gb RAM server that holds a copy of your databse and you’ve written a whole architecture/layer to keep your cache in sync with DB.

    It’s all about balance, and that comes with experience.
  • Explain vmstat output
    Important because in an ideal world, 3 limits would be hit together. But if you know what you app’s usage patterns are, then you know where to optimize, and you know what the specs to your next server are!
  • High performance PHP: Scaling and getting the most out of your infrastructure

    1. 1. © All rights reserved. Zend Technologies, Inc. High performance PHP: How do I make it go faster? Maurice Kherlakian Professional Services Consultant maurice.k@zend.com
    2. 2. © All rights reserved. Zend Technologies, Inc.2 Agenda • What we will be covering  The network, database, and application aspects in optimization  Tools and techniques that assist in optimization (Code tracing, profiling)  OS level optimizations and tools  Best practices in application development for an optimized application  Server clustering  DEMO
    3. 3. © All rights reserved. Zend Technologies, Inc.3 The network •Entry point into your system •Needs to be secured Firewall Layer separation: External – DMZ - internal •Unless you have one server, need to find a traffic distribution mechanism – Load balancers Different kinds of load balancers: hardware v/s software Hardware appliances are costly but robust, do layer 7 lb Software alternatives are cheaper, do a good job also • HAProxy • Ldirectord • Nginx, Apache with balancer modules
    4. 4. © All rights reserved. Zend Technologies, Inc.4 The network •Reverse proxy Avoid having application servers in an externally accessible environment Can also be used to load balance Apache, nginx, lighttpd Usually reverse proxy connect to backend servers
    5. 5. © All rights reserved. Zend Technologies, Inc.5 The web server •Different alternatives – choose based on performance Apache – mod_php Nginx, lighty with php-fcgi or php-fpm Windows IIS – FastCGI •Zend Server Apache-based, on Linux, Windows, IBM i Zend engine
    6. 6. © All rights reserved. Zend Technologies, Inc.6 Web servers clustering •1st step towards scaling solution After moving the database to a separate server Configuration syncing: rsync, rmp/deb, svn Application code deployment ZSCM
    7. 7. © All rights reserved. Zend Technologies, Inc.7 Deployment strategies •SVN as a deployment tool •RPM/deb •PEAR •Zend Server .zpk •More info: watch deployment strategies webinar (http://www.zend.com/en/resources/webinars/php) •Check out Shahar’s Best practices in deploying PHP apps
    8. 8. © All rights reserved. Zend Technologies, Inc.8 Web servers session clustering •What is session clustering •Failing over to other servers •Mechanisms for session clustering Memcached Lightweight key/value server Database Zend Server SC
    9. 9. © All rights reserved. Zend Technologies, Inc.9 Opcode caching •What is it, why virtually every PHP site uses it •Drastic effects of code tracing (Screenshot next slide) •Different opcode caches APC, eaccelerator, xcache Zend Server Optimizer+ •Extra performance boost – check timestamp
    10. 10. © All rights reserved. Zend Technologies, Inc.10 strace with and without O+ activated •10 times less system calls with O+ active
    11. 11. © All rights reserved. Zend Technologies, Inc.11 Static content •Why should we separate static/dynamic content •Techniques for content separation CDN Separate sub-domains Reverse proxying with rules for static content
    12. 12. © All rights reserved. Zend Technologies, Inc.12 Handling large files •Why large files should not be served from PHP •Serve large files from a lightweight web server Lighty, nginx •Securing large files download Modules for web servers – authentication logic, then offload to web server. Usually through headers Zend Download server
    13. 13. © All rights reserved. Zend Technologies, Inc.13 •To achieve an optimal cluster, many different packages •What if one solution existed that could do all this? •Zend server Optimizer + for code caching Full page caching ZSCM for server sync Code tracing/monitoring for app monitoring Zend Download server
    14. 14. © All rights reserved. Zend Technologies, Inc.14 Linux (rpm/web repositories) IBM i (PTF) Windows (MSI) Application Performance Acceleration Optimization Caching Reliability & Management Monitoring Root-Cause Configuration Scale-Out Clustering Job Queue Downloads Business-grade PHP Hot Fixes Support Java Bridge Zend Framework PHP Zend Server ZendStudio(Eclipse-based) CollaborateDebugProfileTest Zend Server1
    15. 15. © All rights reserved. Zend Technologies, Inc.15 Database scaling •Scaling techniques Replication Functional separation Sharding •Schemaless databases eg: MongoDB •For analytics, consider a column-oriented database like Infobright
    16. 16. © All rights reserved. Zend Technologies, Inc.16 Database results caching •Shared memory (APC) •Distributed caching (memcached) •Zend Server data cache •But all of that doesn’t matter if your application is not optimized!
    17. 17. © All rights reserved. Zend Technologies, Inc.17 The application •No cookbook for good application design •Don’t optimize in early development, risk over-optimization •Frameworks Frameworks can make you fall in over-architecting trap Possible mistakes using DBAL or ORM – like lazy joins End up making a lot more queries than necessary
    18. 18. © All rights reserved. Zend Technologies, Inc.18 The application •Write application for what it is intended to be used •(ex: file processing: load entire file v/s one line at a time: first approach works well for a few queries, but under high load 2nd approach better)
    19. 19. © All rights reserved. Zend Technologies, Inc.19 The secrets to application optimization •Using the right tools Xdebug Zend Server Code tracing (demo) Profiling (demo) •Monitor execution time and memory usage •Design intelligently •Know the hardware you’re writing for and how it operates. The more you know about it, the better your app will be
    20. 20. © All rights reserved. Zend Technologies, Inc.20 Database optimizations •Statements tuning •Tables indexing •Monitor all queries to DB Use profiling tools, if using DBAL usually provides one ZF provides Zend_Db_Profiler that allows logging of queries to later study them (demo) Zend_Db_Profiler_Firebug: cool tool that allows displaying all queries on Firebug. Completely independent from page itself, no interference with JSON or XML requests •Use Explain, tune criteria, avoid lazy joins
    21. 21. © All rights reserved. Zend Technologies, Inc.21 How do we fix problems •Found a bottleneck, how do we fix it? Rewrite logic to be less demanding, or more demanding, but get to endpoint faster •Caching File caching Shared mem caching Distributed (memcached) •Adding caching should be easy on a well architected app Domain model •Caching in most cases is NOT a silver bullet.
    22. 22. © All rights reserved. Zend Technologies, Inc.22 High server loads •App is optimized, traffic growing, servers start to cough… •Where is the problem? •Your application can be cpu-bound, io-bound or memory bound. So how do you find out? Use tools like top, vmstat, iostat •Why is this important?
    23. 23. © All rights reserved. Zend Technologies, Inc.23 Recap •Be smart! •Look at the problem, understand it, and solve it. •Using var_dump is NOT the solution, neither is shooting in the dark •Use the right toolset •Wealth of resources (white papers/webinars…) on zend.com
    24. 24. © All rights reserved. Zend Technologies, Inc. Thank you! Maurice Kherlakian maurice.k@zend.com http://framework.zend.com http://www.zend.com