AJAX and performance
It is no secret that asynchronous requests to the server can significantly simplify the work of users with the site. It is also not a secret that asynchronous requests can improve the performance of sites. It’s so tempting to download the main styles, js-scripts, images and fonts, etc., only once, and then use AJAX to load only the necessary content.
If you want to get maximum performance on the site using AJAX, then you need only one idea.
Write for AJAX an individual code.
Yes, like this, it would seem something simpler.
')
But most programmers are lazy (including me) and do not like writing extra code. Due to this, it is possible to find the following structure in the controller (or in a certain script) for the output of a site page, news or blog article:
Almost all systems built on the principle of a single entry point, and work. From popular systems, Drupal, ShopScript (versions with WebAsyst), CodeIgniter and many more can be attributed to such.
For systems with multiple entry points, one system initialization script is usually written. For example, at the beginning of each entry point you can meet something like this:
According to this principle: osCommerce, DokuWiki, WordPress, Joomla, Bitrix and others.
In general, there is nothing bad in such behavior and in the overwhelming majority it is better to work this way. However, to get the necessary part of the content, you need to load the entire system. And this may initially be less productive.
A good solution to improving performance may not be loading the entire system as a whole, but only its basic part, plus the components necessary for solving the problem. For example, why load the blog functionality if you are viewing static pages on the site.
Many systems work in this way: PrestaShop, ShopScript, Bitrix, etc.
But we must understand that the basic part of the system can be quite heavy. In this case, if the performance comes first, then you can try to do without booting the system.
In my practice there is one very illustrative example on Bitrix. I want to make a reservation right away that this is not a stone in the Bitrix developers garden. Who often works with this system knows about its problems and ways to circumvent these problems. And here I will tell about one of these ways.
So, given:
There is a certain online store on Bitrix. In the catalog of the store more than 22,000 products. Products are distributed in more than 400 categories. Each product has about 70 properties. Each product has its own set of suppliers and information on the balances in the warehouses of these suppliers.
Required: write a script for the formation of YML for Yandex with a nontrivial logic for the inclusion of goods into it. The standard module of Bitrix does not cope with this logic.
It is clear that it is not possible to process such an array of data in one sitting and it is necessary to beat the process at iteration. It is here that AJAX comes to the rescue.
We write a module for the user agent, which sends requests to the AJAX server to process a part of the goods.
The server side script accepts the request, connects the system, processes the necessary block of goods and forms part of the YML file. Everything is very standard.
Everything is beautiful, it works according to official documentation. Yes, only this volume of data works for about 25 minutes. This time is due to the loading of the system at each iteration (440 iterations of 50 products), plus the internal costs of samples from the database.
I must say that the solution in my understanding is not beautiful (outside the platform used), but it provided a huge increase in performance.
In the script on the server side, we remove the Bitrix loading and instead connect the system configuration file. Using the standard PDO directly obtain the necessary data about the goods.
Yes, the code works outside the main framework, but the same amount of data is processed in 40 seconds. This is a very significant example of the fact that an individual code for processing requests can work much faster than conventional methods of implementation.
I understand that on a different system and / or other amount of data, the difference in performance may not be significant. And it’s not a fact that one should sacrifice the convenience of maintenance, planting a zoo for the sake of performance, where it is not so critical. But if performance suddenly plays a decisive role, then it is worth thinking of individually writing code for handling AJAX requests.
If you want to get maximum performance on the site using AJAX, then you need only one idea.
Write for AJAX an individual code.
Yes, like this, it would seem something simpler.
')
But most programmers are lazy (including me) and do not like writing extra code. Due to this, it is possible to find the following structure in the controller (or in a certain script) for the output of a site page, news or blog article:
// // if(isset($_POST['ajax'])) { // // AJAX exit(); } else { // // } Almost all systems built on the principle of a single entry point, and work. From popular systems, Drupal, ShopScript (versions with WebAsyst), CodeIgniter and many more can be attributed to such.
For systems with multiple entry points, one system initialization script is usually written. For example, at the beginning of each entry point you can meet something like this:
<?php require_once('includes/application_top.php'); // According to this principle: osCommerce, DokuWiki, WordPress, Joomla, Bitrix and others.
In general, there is nothing bad in such behavior and in the overwhelming majority it is better to work this way. However, to get the necessary part of the content, you need to load the entire system. And this may initially be less productive.
A good solution to improving performance may not be loading the entire system as a whole, but only its basic part, plus the components necessary for solving the problem. For example, why load the blog functionality if you are viewing static pages on the site.
Many systems work in this way: PrestaShop, ShopScript, Bitrix, etc.
But we must understand that the basic part of the system can be quite heavy. In this case, if the performance comes first, then you can try to do without booting the system.
In my practice there is one very illustrative example on Bitrix. I want to make a reservation right away that this is not a stone in the Bitrix developers garden. Who often works with this system knows about its problems and ways to circumvent these problems. And here I will tell about one of these ways.
So, given:
There is a certain online store on Bitrix. In the catalog of the store more than 22,000 products. Products are distributed in more than 400 categories. Each product has about 70 properties. Each product has its own set of suppliers and information on the balances in the warehouses of these suppliers.
Required: write a script for the formation of YML for Yandex with a nontrivial logic for the inclusion of goods into it. The standard module of Bitrix does not cope with this logic.
It is clear that it is not possible to process such an array of data in one sitting and it is necessary to beat the process at iteration. It is here that AJAX comes to the rescue.
Solution 1, standard
We write a module for the user agent, which sends requests to the AJAX server to process a part of the goods.
The server side script accepts the request, connects the system, processes the necessary block of goods and forms part of the YML file. Everything is very standard.
Everything is beautiful, it works according to official documentation. Yes, only this volume of data works for about 25 minutes. This time is due to the loading of the system at each iteration (440 iterations of 50 products), plus the internal costs of samples from the database.
Solution 2, write an individual code for processing requests
I must say that the solution in my understanding is not beautiful (outside the platform used), but it provided a huge increase in performance.
In the script on the server side, we remove the Bitrix loading and instead connect the system configuration file. Using the standard PDO directly obtain the necessary data about the goods.
Yes, the code works outside the main framework, but the same amount of data is processed in 40 seconds. This is a very significant example of the fact that an individual code for processing requests can work much faster than conventional methods of implementation.
I understand that on a different system and / or other amount of data, the difference in performance may not be significant. And it’s not a fact that one should sacrifice the convenience of maintenance, planting a zoo for the sake of performance, where it is not so critical. But if performance suddenly plays a decisive role, then it is worth thinking of individually writing code for handling AJAX requests.
Source: https://habr.com/ru/post/260719/
All Articles