You can get a lot of information from XHProf traces. If you use the default XHProf UI, you will get a list of all function calls, their inclusive and exclusive wall time, call count and optionally memory and real CPU in one big sortable list with no additional filtering or analysis.
Hidden in this vast amount of data however are bits of information that are much more interesting, for example:
- How many database queries were executed? How long did they take? How many database connections were opened?
- How many calls to the cache (Redis, Memcache, ..) were made?
- Are all my libraries using their respective production caches? If not, how can I fix it?
- What is the framework overhead of my requests spent in bootstrapping and various subsystems?
- How much time is spent in rendering templates?
- How much is spent in I/O operations?
- Very specific library details such as how many Doctrine Proxy objects were lazy loaded.
For Tideways we introduced "Packages", which are descriptions of third party libraries or your own applications. These packages will analyze the XHProf traces for you and help you to quickly find answers to performance related questions. Gone are the times where you had to sort through hundrets of function calls to find the information you are interested in.
After collecting your first XHProf trace, you can have Tideways analyze which pre-defined packages can be used in your application or select the pacakges yourself.
For every XHProf trace you can then see additional information. First, a report on significant functions, that help you get an overview of the slow and fast parts of the codebase:
Secondly, a report for counters such as Database, Cache and other calls and hints how to optimize those calls:
The package definitions are written in XML and you can add your own for all the libraries you use. We have a repository on Github where you can create a pull request for missing open-source libraries.
We are also working on a feature to allow you adding private packages to your organization, analyzing inhouse frameworks or specific applications.
Using this pre-analyzed data you can find performance problems much easier on a first glance. From there you can either directly fix the problem or start diving into the details of the Xhprof Trace like you are used to with the default UI.