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
11/16/2018

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
These are the Issues that we will tackle in this presentation.
11/16/2018

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.
11/16/2018

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.
11/16/2018

6. Bad SQL and DB design MySQL Bad SQL DB design
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.
11/16/2018

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
11/16/2018

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.
11/16/2018

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
11/16/2018

10. System Tuning This will go over the LAMP stack Linux Apache MySQL PHP
11/16/2018

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

12. Apache Httpd.conf Only load in what you need.
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, 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
11/16/2018

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.
11/16/2018

14. PHP Limit the number of Extensions Set the memory limit
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
11/16/2018

15. System Considerations
More Hardware
Redundancy, Redundancy, Redundancy
Backups
11/16/2018

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
11/16/2018

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.
11/16/2018

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
11/16/2018

19. Coding Considerations
Small Single Operation Code
Profile Your Code
11/16/2018

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.
11/16/2018

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
11/16/2018

22. Coding Examples that Scale
Offline Processing
Batching Systems
11/16/2018

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.
11/16/2018

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
11/16/2018

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: PHP-ZEND
( )
Fax:
11/16/2018