Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

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



ZendCon 2010 session on performance optimization tips and best practices

ZendCon 2010 session on performance optimization tips and best practices



Total Views
Views on SlideShare
Embed Views



2 Embeds 70

http://blog.jensihnow.de 67
http://blog.jensihnow.he-webpack.de 3



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Public facing, router – then into network. LB cand do natting.Examples of hardware appliances Coyote point, BarraccudaTalk 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 Drupalbencchmark 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 wayApplication 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 optimizeTrade-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?
  • AZend Consultant’s secret weapon: Code tracing. -> DEMOKnow 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_ProfilerAdd 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 outputImportant 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 High performance PHP: Scaling and getting the most out of your infrastructure Presentation Transcript

  • High performance PHP: How do I make it go faster?
    Maurice Kherlakian
    Professional Services Consultant
  • 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
  • The network
    Entry point into your system
    Needs to be secured
    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
    Nginx, Apache with balancer modules
  • 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
  • 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
  • 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
  • Deployment strategies
    SVN as a deployment tool
    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
  • Web servers session clustering
    What is session clustering
    Failing over to other servers
    Mechanisms for session clustering
    Lightweight key/value server
    Zend Server SC
  • 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
  • strace with and without O+ activated
    10 times less system calls with O+ active
  • Static content
    Why should we separate static/dynamic content
    Techniques for content separation
    Separate sub-domains
    Reverse proxying with rules for static content
  • 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
  • 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
  • Zend Framework
    Zend Server
    Reliability &
    Hot Fixes
    Job Queue
    Java Bridge
    Zend Studio (Eclipse-based)
    (rpm/web repositories)
    IBM i
    Zend Server
  • Database scaling
    Scaling techniques
    Functional separation
    Schemaless databases eg: MongoDB
    For analytics, consider a column-oriented database like Infobright
  • 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!
  • The application
    No cookbook for good application design
    Don’t optimize in early development, risk over-optimization
    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
  • 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)
  • The secrets to application optimization
    Using the right tools
    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
  • 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
  • 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
    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.
  • 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?
  • 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
  • Thank you!
    Maurice Kherlakian