CPU
- top -> for diagnosys – must be less than the number of processors
- profiling -> xDebug
Can’t involve just one page (unless you use a very simple one, not xDebug for sure) but the all site. Maybe you don’t want to do it on the production server (because of the loss in performance). Then you have to replicate the live environment on a profiling machine and generate some synthetic traffic - opcode caching -> APC
- smarty -> for even better performance, compile_check off on production because we are not supposed to modify files on production apart from scheduled deploys
Disk
- most limiting factor: speed of the hard disk
- iostat for diagnostic
Network
- It’s rarely a problem in a local cluster of server because they have gigabits interfaces
- diagnostic: netstat
Memory
diagnosis: top, vmstat, ps aux, pstree
Database
- Supposing we have a common method to send execute queries in the database, we can always include a part of the debug backtrace in the query as comment. That way, it is easier to identify the location in the code when you read the processlist or a log
- Query profiling – in MySQL it’s possible to log all the executed queries. You can enable it temporary to spot out some performance issue. Unfortunately it requires the server to be restarted
- To improve performance:
- indexes
- caching
- memcached is a great example
- very good results if the application performes a lot of reads and few writes
- very important to remember to invalidate the cache when data is updated
- denormalization
- to avoid joins
- at a certain scale, it becomes more and more essential
- you can use some tools to check data is in sync (even overnight)
