If you are developing some app/project or supporting a code that was written previously or an existing project, probably you have already used a profiler or debugger to find out “bottlenecks”, which caused an unobvious load. The decision or the problem, which are described below, may be related not only to the developer but also to the owners of the projects.
There are many different ways to debug the code and each is suitable for solving the specific task. In our case, the search of “ridges” in the code is often taken place in the running project when it starts to function incorrectly. Usually, the most common errors appear at the moment, when the number of the project’s users is increasing in hundreds or even thousands times. That’s why new project architecture should be built up according to current and future requirements. Probably, I should write a separate article on this subject.
What’s a Blackfire?
Blackfire is the project performance management tool that debugs code in all life stages (development, testing, or production).
Why Blackfire?
Because there is 0% of the server load. Blackfire starts only on the request and only for the current session. This is very important, especially when you need to test and debug a function or a page of the working project that is currently under the load (production).
Blackfire has comfortable tools to run the test from the command line, as well as through a plug-in in the browser. Additional bonus is SDK for integration into the application’s code where you can debug everything you need (the following example is on debugging the work of checkout). There are a lot of extra functions: autorun of the tests, integration with Gitlab, GitHub, Bitbucket, Newrelic, Slack, Hipchat, and other options that help to debug, test, respond, and improve your code.
What is debugging of the code for?
If you’re a developer, except the application architecture, you are still interested in its performance, whether the code is designed correctly, and what happens at all stages of the code under the load in specific or spontaneous conditions.
What important parameters measure the performance of the code?
I/O Wait – time spent on the work of HDD. If your application is working with the file system than the metric of the reading, writing, searching files or content in the files will be very useful. If you take an example of working Magento 1 or 2, you can see the load of the HDD when the XML-files are assembled. The obvious conclusion is to use the SSD.
CPU Time – processor’s time.
Memory – the amount of RAM that the application consumes. This option can increase or decrease for a variety of reasons. Functions that most often are in TOP – devouring of the memory: unserialize, array_value, base64_decode etc. The list is not complete and varies depending on the tasks which application has to decide.
Network – is an amount of information transmitted/received over the Internet.
HTTP – requests. If an application uses external services like SOAP, REST or other, it helps to identify slow requests. One of the common problems of the “slow” code is the use of third-party services that cannot be controlled. Some of them just stop working or are very slow and as result, your app too.
SQL Queries – is probably one of the most vulnerable places in your code, especially when you need to analyze each query in detail and its impact on the application and the system as a whole. You have to decide whether to optimize the query and the function that processes data or to avoid using the request/function.
Example of the SDK connection for debugging the checkout functions in Magento
Full documentation and options for using are here.
We’ll skip an installation of the SDK, because this information is available in the documentation, see above. The only thing we’re going to write about is that all the external libraries that we use for Magento 1, are copied and removed to the vendor folder. So, in this example, the library path will pass through this folder.
In more than 90% of the cases, on-line stores on Magento prefer to use checkout (an order page) of third-party plug-ins for this platform. This is not related to the limited functionality of “native” checkout, but to better usability and friendly interface for the client’s third-party plug-ins.
An example of a simple report and recommendations for an item page.
The example below is for checkout used in the Magento by default. You can use this approach for any module and class.
At the top of the class we connect the Blackfire’s library, and then the profiler is configured in the function. Instead of “client-id” and “client-token”, you need to enter your data that Blackfire will give to the customers (you need to subscribe fee-paying or use a trial version).
The beginning of the profile $probe = $blackfire-> createProbe();
The end of the profile $profile = $blackfire-> endProbe ($probe);
Conclusions and afterword
Blackfire helps you to identify “bottlenecks” in your code. The using of it in the production-server is the primary advantage. The using xDebug is not possible because of the very large overhead, as well as the lack of UI to identify, search and analyze the used functions. There are free tools in the net, but they are “a drop in the sea” of information that we have to deal with. It takes a lot of time to find a problem and you have to realize that the server will be paralyzed during this time.
There are also Newrelic and Tideways services, but they are more used for monitoring rather than for debugging. We should write about its advantages and differences in the next article.
In general, it’s important to distinguish such notions as debugging, monitoring and testing.
We need to know that there are passive and active methods of error detection. There are tools for each task which have their advantages and lacks.
If you are interested in the debugging and testing of the code, contact us using the contact form on the site.
