Connecting Composite
In this small note we will look at the process of connecting the Composite site technology in projects on 1C-Bitrix.
Just a couple of links to the description of the technology, just in case:
→ Marketing
→ Technical
')
What we have before the introduction:
It would seem, well, what else?
And then the voice of the Internal Perfectionist is heard: “I want faster, do faster, want, want, do.”
For a while, you can live with this quiet enticing reproach. Composite is not something to rush to do first of all, especially if the project as a whole works without failures.
But once you realize that you can just go and do it. Otherwise, the voice will not calm down. Cookie lumpy, tasteless smoothies, pancake is not a cake.
Let's consider the right option right away - you have a test copy of the project, covered outside. If not, do it. Can not do - work in a living way, God will forgive, the client will not see. Joke. Just make a copy. To begin, go to the admin copy of the test copy in Settings → Product settings → Composite site and with an unwavering hand, turn on AutoComposite strongly and irrevocably. After that, we begin methodically and carefully testing all interfaces of the site, simulating the output for different users. First of all, we pay attention to the behavior of the blocks redrawn by the Ajax, without refreshing the page. With a probability close to 100%, a number of blocks will not work correctly. The reason is simple, it lies in the technology itself. Composite cache is a logical continuation of the old technology of html-caching, without “learning” the cached content is created on the first hit of the first user and then transmitted to all other users. Therefore, it is quite possible, for example, a situation in which all users will see the “first created” by someone small basket - the same for all. Or, for example, everyone will see the “authorization” of some other user. Authorization is here quoted, because, of course, no one really logs in with this user, but an invitation to enter the personal account under it will be displayed, for example (technically speaking, the block html-code generated during authorization of this user, broadcast then everything else).
It is not very difficult to get rid of this effect, although it requires attentiveness and understanding of the platform operation. First, you need to localize the components that give “the same html” to all users, i.e. determine which component templates vote "against" the Composite and require manual intervention. We do not take pages that are initially dynamic (cart, search page, personal account, order page, etc.).
They will help us in debugging: the constant BX_COMPOSITE_DEBUG with a value of true in the file / (bitrix|local)/php_interface/dbconn.php (do not forget to disable it after debugging!) And the extension for Google Chrome Bitrix Composite Notifier . In debug mode, the AddMessage2Log system function is used , which writes an entry to the log if some component template votes “against” (for the function to work, you must set the constant LOG_FILENAME with the value in the form of the full path to the log file). Write the constant, or in a specific page, or globally, set the extension and begin to analyze.
Under the anonymous user we view all the pages of the site, which should be “composite”. In the normal case, the extension icon in the browser should be active (color).
If an icon is inactive on a page (gray) - the technology on this page does not work and you need to figure it out.
This is where the log file will help us. We open it, we look, what templates vote "against", and we adapt them under the composite mode. We continue until the extension indicator “lights up” on all pages of interest. After that, you need to make sure that all the content, which should be unique for each user, is loaded in the background, and not cached along with the static. This is usually a small user basket, an authorization block, the number of products in the favorites, etc. At this stage, we bring all the dynamics to the dynamic part, if necessary, do stubs. Intentionally we do not describe here the adaptation process itself from the point of view of programming, since it is described in detail in the initial letter , and the question in this case is more about the organization of the transition process, rather than about the code of the components.
If everything is good and the pages started to be rendered from the cache, you should make sure that the cache lives long enough and is not overwritten on every hit. This is quite possible if dynamic data are used in stubs or “static” content. For example, in the template designated as static, the output of the function time () is registered in the template. You never know, freaked out someone. To identify such pages is quite simple. When debug mode is enabled (BX_COMPOSITE_DEBUG) in the cache folder / bitrix / html_pages / {domain} /, files are copied into files with the extension * .delete. {Microtime} before overwriting. If there are many such files, it makes sense to go over them, identify the differences and optimize the code that creates these differences. If possible, get rid of such areas in the code or replace them with the JS-version.
After the components are prepared for working with Composite, you can and should transfer the code to the combat version of the site. We do not turn on the combat Composite yet. Again we test the work of all interfaces, if everything is done correctly, the code will be equally efficient for any type of caching. Does it work correctly? Are you convinced? Right? Checked again? Well, ok, we believe, let's press a button. We drop the cache in the settings, turn on AutoComposite and check everything again. Do not forget to specify all the domains of the site in the settings of the composite? Well done. Open the site in incognito mode, press F12 and press F5 a couple of times. Just a couple of times. On the first hit, the page will be given away by the server “as usual”, a composite cache will be created, on the second hit the server will return the created composite cache and receive the directive “now show it”. And on the third hit we will get a page with "full use" of the Composite. If everything works as it should, in the Network tab of the debugger there will be something like this:
As we see, we receive the document with status 304, i.e. the page did not change, and resources are taken from the cache. At the same time, interactive interface elements continue to function here. You can play F5 and enjoy the speed.
And finally, as usual, a small spoonful of tar to all this beauty.
By default, the composite cache is stored in files. If you use BitirxVM, hosting on the basis of this virtual machine, a web-environment package from Bitrix or you have enough direct hands to build the necessary config yourself - the cache will be given to Nginx, without requests to the backend.
Accordingly, the response headers will be: X-Bitrix-Composite: Nginx (file). This is already good and fast. But if you try to do quite right (again this voice ...), it would be logical to "resettle" the composite cache in memcached, i.e. store it in shared memory, which, of course, will give another speed increase, especially if the server is on a regular HDD. And it seems that all this should work out of the box, but alas. At the moment (April 2017), switching storage types in the Composite settings in the admin panel to memcached and then updating the Nginx config via the BitrixVM control panel will not give a full result. If memcached is connected in the usual way, via a port, you will get the X-Bitrix-Composite header: Nginx (memcached), i.e., at first glance, the correct one, but the page will still be sent to the server each time with a status of 200 OK, and not 304 Not modified, i.e. load again. And we wanted to achieve 304 status, so that the document was collected from the browser cache without changes, without wasting time getting the document body from the server. If you try to connect memcached through unix socket, Nginx will not work with it at all, will skip everything through and the standard X-Bitrix-Composite will be in the header: Cache (200). Those. Yes, Composite is turned on, there is a cache, but “you have to go to the backend behind it,” which, say, evasively, somewhat devalues ​​the essence of technology. Bitrix technical support knows about these nuances and promises to fix it, so for now use storage in files in conjunction with Nginx in BitrixVM.
And this, your Inner, do not listen, better feed him with cookies.
Just a couple of links to the description of the technology, just in case:
→ Marketing
→ Technical
')
What we have before the introduction:
- shop on BEADS 17 with a number of areas loaded with ajax-ohm;
- Bitrix VM 7, PHP 7;
- VPS on SSD;
- the cache is stored in memcached;
- configuration is optimal;
- performance monitor pleases;
- customer satisfied.
It would seem, well, what else?
And then the voice of the Internal Perfectionist is heard: “I want faster, do faster, want, want, do.”
For a while, you can live with this quiet enticing reproach. Composite is not something to rush to do first of all, especially if the project as a whole works without failures.
But once you realize that you can just go and do it. Otherwise, the voice will not calm down. Cookie lumpy, tasteless smoothies, pancake is not a cake.
Let's consider the right option right away - you have a test copy of the project, covered outside. If not, do it. Can not do - work in a living way, God will forgive, the client will not see. Joke. Just make a copy. To begin, go to the admin copy of the test copy in Settings → Product settings → Composite site and with an unwavering hand, turn on AutoComposite strongly and irrevocably. After that, we begin methodically and carefully testing all interfaces of the site, simulating the output for different users. First of all, we pay attention to the behavior of the blocks redrawn by the Ajax, without refreshing the page. With a probability close to 100%, a number of blocks will not work correctly. The reason is simple, it lies in the technology itself. Composite cache is a logical continuation of the old technology of html-caching, without “learning” the cached content is created on the first hit of the first user and then transmitted to all other users. Therefore, it is quite possible, for example, a situation in which all users will see the “first created” by someone small basket - the same for all. Or, for example, everyone will see the “authorization” of some other user. Authorization is here quoted, because, of course, no one really logs in with this user, but an invitation to enter the personal account under it will be displayed, for example (technically speaking, the block html-code generated during authorization of this user, broadcast then everything else).
It is not very difficult to get rid of this effect, although it requires attentiveness and understanding of the platform operation. First, you need to localize the components that give “the same html” to all users, i.e. determine which component templates vote "against" the Composite and require manual intervention. We do not take pages that are initially dynamic (cart, search page, personal account, order page, etc.).
They will help us in debugging: the constant BX_COMPOSITE_DEBUG with a value of true in the file / (bitrix|local)/php_interface/dbconn.php (do not forget to disable it after debugging!) And the extension for Google Chrome Bitrix Composite Notifier . In debug mode, the AddMessage2Log system function is used , which writes an entry to the log if some component template votes “against” (for the function to work, you must set the constant LOG_FILENAME with the value in the form of the full path to the log file). Write the constant, or in a specific page, or globally, set the extension and begin to analyze.
Under the anonymous user we view all the pages of the site, which should be “composite”. In the normal case, the extension icon in the browser should be active (color).
If an icon is inactive on a page (gray) - the technology on this page does not work and you need to figure it out.
This is where the log file will help us. We open it, we look, what templates vote "against", and we adapt them under the composite mode. We continue until the extension indicator “lights up” on all pages of interest. After that, you need to make sure that all the content, which should be unique for each user, is loaded in the background, and not cached along with the static. This is usually a small user basket, an authorization block, the number of products in the favorites, etc. At this stage, we bring all the dynamics to the dynamic part, if necessary, do stubs. Intentionally we do not describe here the adaptation process itself from the point of view of programming, since it is described in detail in the initial letter , and the question in this case is more about the organization of the transition process, rather than about the code of the components.
If everything is good and the pages started to be rendered from the cache, you should make sure that the cache lives long enough and is not overwritten on every hit. This is quite possible if dynamic data are used in stubs or “static” content. For example, in the template designated as static, the output of the function time () is registered in the template. You never know, freaked out someone. To identify such pages is quite simple. When debug mode is enabled (BX_COMPOSITE_DEBUG) in the cache folder / bitrix / html_pages / {domain} /, files are copied into files with the extension * .delete. {Microtime} before overwriting. If there are many such files, it makes sense to go over them, identify the differences and optimize the code that creates these differences. If possible, get rid of such areas in the code or replace them with the JS-version.
After the components are prepared for working with Composite, you can and should transfer the code to the combat version of the site. We do not turn on the combat Composite yet. Again we test the work of all interfaces, if everything is done correctly, the code will be equally efficient for any type of caching. Does it work correctly? Are you convinced? Right? Checked again? Well, ok, we believe, let's press a button. We drop the cache in the settings, turn on AutoComposite and check everything again. Do not forget to specify all the domains of the site in the settings of the composite? Well done. Open the site in incognito mode, press F12 and press F5 a couple of times. Just a couple of times. On the first hit, the page will be given away by the server “as usual”, a composite cache will be created, on the second hit the server will return the created composite cache and receive the directive “now show it”. And on the third hit we will get a page with "full use" of the Composite. If everything works as it should, in the Network tab of the debugger there will be something like this:
As we see, we receive the document with status 304, i.e. the page did not change, and resources are taken from the cache. At the same time, interactive interface elements continue to function here. You can play F5 and enjoy the speed.
And finally, as usual, a small spoonful of tar to all this beauty.
By default, the composite cache is stored in files. If you use BitirxVM, hosting on the basis of this virtual machine, a web-environment package from Bitrix or you have enough direct hands to build the necessary config yourself - the cache will be given to Nginx, without requests to the backend.
Accordingly, the response headers will be: X-Bitrix-Composite: Nginx (file). This is already good and fast. But if you try to do quite right (again this voice ...), it would be logical to "resettle" the composite cache in memcached, i.e. store it in shared memory, which, of course, will give another speed increase, especially if the server is on a regular HDD. And it seems that all this should work out of the box, but alas. At the moment (April 2017), switching storage types in the Composite settings in the admin panel to memcached and then updating the Nginx config via the BitrixVM control panel will not give a full result. If memcached is connected in the usual way, via a port, you will get the X-Bitrix-Composite header: Nginx (memcached), i.e., at first glance, the correct one, but the page will still be sent to the server each time with a status of 200 OK, and not 304 Not modified, i.e. load again. And we wanted to achieve 304 status, so that the document was collected from the browser cache without changes, without wasting time getting the document body from the server. If you try to connect memcached through unix socket, Nginx will not work with it at all, will skip everything through and the standard X-Bitrix-Composite will be in the header: Cache (200). Those. Yes, Composite is turned on, there is a cache, but “you have to go to the backend behind it,” which, say, evasively, somewhat devalues ​​the essence of technology. Bitrix technical support knows about these nuances and promises to fix it, so for now use storage in files in conjunction with Nginx in BitrixVM.
And this, your Inner, do not listen, better feed him with cookies.
Source: https://habr.com/ru/post/325926/
All Articles