Scaling and Performance

1. Scaling and Performance What a PHP programmer should know. by: Rock Mutchler

2. Scaling and Performance • In this presentation • Common problems • System Tuning • System Considerations • Coding Considerations • Coding Examples that scale

3. Common Problems The Issues • Large connection overhead • Network latency for inline calls • Bad SQL and DB design • Improper web server usage • Large complex PHP which is expensive to execute • Heavy disk I/O

4. Improper use of connections • Connection overhead • Only make connections to database servers, IMAP servers and such when necessary • When possible cache items you are retrieving from these systems locally. • If caching the whole page or a version of a whole page is possible do so. • By removing these connections you may free up your web server to handle other incoming requests instead of having a process waiting on a connection to be made.

5. Network Latency • Remote System Calls • NFS file systems being over used. • Need to ask yourself if there is another solution for sharing the data being stored on a NFS or NFS like system. If not ask if you can minimize the items being stored on this system. • Feeds • 9 times out of 10 remote feeds do not need to be read in on every call. So cache them locally and only retrieve them on an interval when you need up to date data. • Direct web requests to other servers for items. • Images, content; think of pulling this data locally.

6. Bad SQL and DB design • MySQL • Bad SQL • Sometimes it is more beneficial to break out items into 2 queries rather than one more complex query. • Or – sometimes the or statement can be very expensive • Joins – make sure you need the join, and it can’t be done with 2 queries as most times this can be much faster. • Watch items that have create temporary tables or have to scan the whole table. (sorts and groups) • DB design • Wrong table type used • MyISAM (storage table type) being used where INNODB would be a much better fit with it’s row locking instead of table locking features.

7. Improper Web Server Usage • Apache • Apache was not designed well for handling large file downloads. Thought of an alternative should be strongly considered as offsetting this will free up apache to serve more web pages. • Proxy server (Squid, mod proxy) • Zend Download Server

8. Large Expensive PHP • Large complex PHP which is expensive to execute • PHP scripts with a lot of “meat” can benefit greatly from code acceleration. • Zend Accelerator. • Usually requiring no configuration or application changes of any kind, Code Acceleration involves both caching and optimization techniques performed on compiled PHP code, resulting typically, in a 3 times increase in performance.

9. Heavy disk I/O • Beating up your drives • Extra drives on the system can fix this issue. • Move high traffic write/read directories on to these other drives • This will free up the drives and spread out the work load making response time much faster and better use of disk cache. • Items commonly moved • Sessions directory • Highly used database tables

10. System Tuning • This will go over the LAMP stack • Linux • Apache • MySQL • PHP

11. Linux • File System • A (access) time • Turn this off if it is not being used by your system

12. Apache • Httpd.conf • Know the foot print of an apache process on your system. • Set max clients accordingly • Have plenty of spare servers laying around to handle requests. Spawning a new process is expensive, so just have them ready. • Max Child Request – set this high, 10000 or so. • Keep Alive, most systems will want this off, but if you have large pages with lots of images you may want to keep this on. • Only load in what you need. • Compile from source and only use what you need

13. MySQL • Compile from Source for system • MySQL offers binaries which are great for small systems but don’t use them on any system that is supposed to scale. • Use buffer cache, query cache, table cache in MySQL • Set these settings as high as you possibly can get away with on a given system.

14. PHP • Limit the number of Extensions • When compiling limit the number of extensions that are used • Good example of what is bad, is using the version of PHP that comes with some Linux distributions. (RedHat, SUSE, Debian, etc…) • Set the memory limit • Set the memory limit as low as you can get away with and still execute your code • Good Starting Point • The optimized version of the php.ini that comes in the distribution

15. System Considerations • More Hardware • Redundancy, Redundancy, Redundancy • Backups

16. More Hardware • Know when you’ve reached your systems limit • If when programming you’ve made considerations to scale out parts of your system. Know what your limits are for the software. This is key in knowing when you’ll need to add more hardware. • Single Item Per Server • Segment your servers to handle one important task. • Don’t run MySQL, apache, or other processes on the same box, as they’ll be competing with one another

17. Redundancy • Scale • You can not scale an application w/out redundancy. • MySQL • Master – Slave servers • 2 read slave boxes for every master if high reads are done. • Data Federation • Split up you high insert tables to multiple master servers which then write to multiple slaves. • Apache • More than one machine for all web operations • No single point of failure.

18. Backups • Never say, we lost the data. • Always have backups • Build your system in such a way that you can back up off of slave servers (MySQL) or an apache server that can be taken offline with out service interruption • Push backups off site

19. Coding Considerations • Small Single Operation Code • Profile Your Code

20. Small Single Operation Code • OO is not always the way • OO programming style while is wonderful and great for large systems. If you have only a single task to operate on a give system, procedural code may prove to be much faster. • Write code explicitly for the operation at hand, with no worries of others using the code or the having to perform other operations.

21. Profile Your Code • Know where your bottle necks are. • Profiling your pages can show you slow items which while programming you never even considered would be slow • Profile existing systems as well. This can give you a good starting point when trying to scale a system that is already in place. • Zend Studio

22. Coding Examples that Scale • Offline Processing • Batching Systems

23. Offline Processing • For Example • Image Processing • Using GD to resize images can be a very expensive process, you will not what to do this inline, nor will you want to do this on the server that is providing web pages to users. • Instead a queue system will need to be built, file system queue recommended, that will then move the files via cron to an offline server. • The offline server will then run the resize operation. • Processed images are then moved to the web servers where they can then be requested and cached by the proxy servers or served by Zend Download Server.

24. Batching Systems • Removing Inline Inserts • When real time data isn’t absolutely a must a batching system can be used to greatly reduce the number of inserts on a system. • Write a file to the local file system (always available) • When doing this you want to make sure you have enough apache servers to handle this. 1k – 25k files is ok but 200k and up you will end up with other issues with the file system. • Move files to processing system • Process the files, consolidating inserts (if there is a count, just adjust the number (reduce the updates)) • Mass insert to MySQL – much faster than single insert operations

25. Thank you - Zend Consulting Services • Zend offers an array of Consulting Services to support the development and deployment of your business-critical PHP applications. Zend Technologies, Inc. 19200 Stevens Creek Blvd. Cupertino, CA 95014 Tel: 1-888-PHP-ZEND (1-888-747-9363) Fax: 1-408-253-8801