The Profiler allows you to observe the time spent by each service call in the different processing steps. The idea is to help you better understand how your server performs live, and to give you easy access to the information you need to eliminate bottlenecks and fine-tune performance. The default view shows average durations for all your calls. The profiler shows Amfphp times, but it is also possible to add your own times.
The Profiler showing all your services
You can get more details on a call by clicking on its name.
The Profiler showing the details of one service
Understanding the data and using it to optimize your system
Amfphp by default provides the following durations. Some are always shown, some are shown only if the relevant plugin is activated.
Deserialization and serialization
Deserialization is the conversion of the HTTP request to PHP objects. Serialization is the conversion of your Service Call response from PHP objects to an HTTP response. No matter your configuration, this pair is aways part of the process.
If either serialization or deserialization is taking too long it can be sped up by using an alternative deserializer/serializer such as Baguette AMF.
Value Object Conversion
This the step where the anonymous objects in the deserialized request are converted to typed objects, and the objects in the response are processed to see what type should be sent back to the client for them. This step only takes time for protocols such as JSON where objects can not be processed during serialization/deserialization. With AMF objects are processed directly during serialization/deserialization, so this step shall always be marked as 0.
If this is taking too long, consider using AMF, or not using typed objects and deactivating the AmfphpVoConverter plugin.
This is the step where strings are converted between the client’s charset and the server’s charset. Usually this is not necessary as both the server and the client should use the same charset, usually UTF8. So the functionality shall appear in the graph only if 2 different charsets are used.
If this is taking too long, try to use the same charset on your client and your server, so that you can eliminate this step.
This is the step where your service is called.
As this part is purely dependent on your code, it is difficult to make recommendations to make it faster. One possibility though is to gather more data on the various parts of your call. See ‘Gathering more data‘ below for details.
Gathering more data
It is possible to define your own markers, if your service code is complex and you wish to analyze the performance of various parts of your code.
In that case just call the AmfphpMonitor::addTime method. It is advised to check that the AmfphpMonitor class is available before using it.
Be warned though that the charting system expects all service calls to have the same time markers. So before adding markers, you are advised to empty the log file (use the ‘flush’ button).
Furthermore, monitoring doesn’t measure the beginning and end of a step, but just the end. The values are then calculated based on the other marker values. So if you add steps, this shall affect the markers and you should read the data accordingly. For example, if your service call takes 200ms, and you add a marker at 100ms, you shall see 100ms for your custom marker, and 100ms for your service call. This does not mean that your service call is taking less time.
The Profiler With Custom Markers
You don’t have any data
The data used by the profiler is gathered during your calls by the AmfphpMonitor plugin. This plugin is included in Amfphp, and enabled by default.
Unless configured otherwise, the data by is written to [AmfphpMonitor plugin folder]/log.txt.php. Monitoring will only work if your web server has permission to write to this file! If it does not, the plugin shall simply not log anything.
So, to enable monitoring, check that your web server has permission to write to the log file( most likely [AmfphpMonitor plugin folder]/log.txt.php )
The data you see is not up to date
Logging is by default limited to a log of 1 Mega Byte. This is meant as a safeguard for when logging stays enabled by mistake on a production system. To get fresh data, push the « flush » button, make a new call, then push the « refresh » button.
Please note that the Back Office relies on the AmfphpAuthentication, AmfphpJson, AmfphpDiscovery, and AmfphpMonitor plugins, so it won’t fully work without them. AmfphpMonitor is only for the Profiler. AmfphpAuthentication is needed only to control access. AmfphpJson and AmfphpDiscovery are needed by the Service Browser and the Client Generator. These plugins are all enabled by default, so you should not need to edit their configuration to get things working.