Alternative announcement of the new release of UMI.CMS
I actively follow the market of popular CMS. For some reason, it’s not very popular in the hosting industry to track trends in software that we host. Although lately there is still a tendency towards the display of the interest of colleagues in this matter. Such a historical primer for the appearance of this post was my report Expert evaluation of some CMS as applied to mass hosting . In short, I told there that CMS is heavy, usually inconvenient to operate, that the opinion about their business efficiency is orders of magnitude higher than the deplorable reality. In the same place, I called for a dialogue between CMS developers and exploiter-hosts.
Two years have passed. Something has changed. Something for the better, something for the worse. And the other day I noticed a curious, in terms of operation and needs, release of one of the domestic commercial CMS - UMI.CMS .
')
The first thing that caught my eye was the refusal to use ZendOptimizer in the test version of CMS. It would seem such a small thing, but how many consequences it has. First, it somewhat expands the range of usable hosting sites. Secondly, ZendOptimizer will no longer be released under FreeBSD , which is the leader of “hosting systems” in Russia. UMI.CMS has given itself an injection for the future :) Thirdly, it will allow using coded versions of CMS along with various “accelerators” only with their “glitches”, without imposing features of ZendOptimizer. In particular, this will make it possible to really test hosting with accelerators without attempting to transfer to the already purchased ready-made version of CMS. I understand that UMI is simply trying to occupy a place on the market in all possible ways, including hilling of hosting sites. But this is good, because this is healthy competition in a market economy.
The second, in which I understand only “interlaced”, is integration with 1C-accounting. Judging by the announcement, UMI has slightly tilted 1C-Bitrix in terms of integration with 1C. I deliberately googled - it seems to be true. Particular attention should be paid to the keyword CommerceML. I think such a lunge in the direction of a senior competitor will cause a surge in the “arms race”, which in business is always useful for creating a healthy market atmosphere.
I could not resist and put a new version of UMI.CMS http://umicms.diphost.ru on the downloaded virtual hosting server (I chose not a fresh one). This is just a demo site from the same CMS kit. I specifically disabled in php.ini ZendOptimizer to eliminate the marketing error.
I will immediately note the remaining unshakable thing - UMI.CMS remained picky about the disk subsystem. Any “plug” on the disk gives a direct response to the performance of the CMS.
I noted for myself the possibility of caching intermediate objects in the file cache. At least as long as I can only do this, there is no memcached or APC on the hosting.
We, like some domestic hosts and some foreign (for example webfaction), have a fixed number of apache handlers per user. Therefore, the classic testing of "attendance" is quite difficult to do in the sense of evaluating the results and I was too lazy. I succeeded with caching intermediate objects on the disk to generate pages with goods from 0.5 to 5 seconds. Is it a lot or a little? Pages with static caching can be considered almost static - about 0.01 seconds per generation. I believe that without caching, you can not talk about high loads, because this is all talk in favor of the rich. Just noted the fact that it is different.
Along with caching, there is clearly noticeable optimization in terms of the amount of static “junk” that each site generates, especially CMS. You can see for yourself in the properties of the page in your browser, how much and what is connected there. Nonsense, but "five old women - the ruble," the load on the operational part drops markedly.
Just the other day, my colleagues and I discussed existing wiki engines. There was a small dispute about the meaning of the WYSIWYG editor. I argued that it still only creates the appearance of what the result will look like, and therefore it does not carry much sense, that in the case of visualization, inline editing is required, which almost no one has. Just cited UMI.CMS as an example, since they have it, i.e. edit what we see. There was a question about the list of changes. What was my surprise when I saw the “change” button in the new inline editor, which also works - you can roll back the version of the change. There, of course, without describing the change, you need to guess on the coffee grounds what and when you cheated, but the fact itself.
I would also like to note an important, in my opinion, thing. Software in the history of product development has the property "stagnate." This is the notorious backward compatibility of Windows, and "UTF-8 experimental support" in the XXI century in Twiki, and many other examples. It was very joyful to see how a sophisticated CMS took and changed prototype.js to a more modern jquery. This is a very positive image indicator.
Here is such a fun release. We are looking forward to "retaliatory strikes" with curtsies towards exploitation from commercial CMS competing with UMI :)
Two years have passed. Something has changed. Something for the better, something for the worse. And the other day I noticed a curious, in terms of operation and needs, release of one of the domestic commercial CMS - UMI.CMS .
')
The first thing that caught my eye was the refusal to use ZendOptimizer in the test version of CMS. It would seem such a small thing, but how many consequences it has. First, it somewhat expands the range of usable hosting sites. Secondly, ZendOptimizer will no longer be released under FreeBSD , which is the leader of “hosting systems” in Russia. UMI.CMS has given itself an injection for the future :) Thirdly, it will allow using coded versions of CMS along with various “accelerators” only with their “glitches”, without imposing features of ZendOptimizer. In particular, this will make it possible to really test hosting with accelerators without attempting to transfer to the already purchased ready-made version of CMS. I understand that UMI is simply trying to occupy a place on the market in all possible ways, including hilling of hosting sites. But this is good, because this is healthy competition in a market economy.
The second, in which I understand only “interlaced”, is integration with 1C-accounting. Judging by the announcement, UMI has slightly tilted 1C-Bitrix in terms of integration with 1C. I deliberately googled - it seems to be true. Particular attention should be paid to the keyword CommerceML. I think such a lunge in the direction of a senior competitor will cause a surge in the “arms race”, which in business is always useful for creating a healthy market atmosphere.
I could not resist and put a new version of UMI.CMS http://umicms.diphost.ru on the downloaded virtual hosting server (I chose not a fresh one). This is just a demo site from the same CMS kit. I specifically disabled in php.ini ZendOptimizer to eliminate the marketing error.
I will immediately note the remaining unshakable thing - UMI.CMS remained picky about the disk subsystem. Any “plug” on the disk gives a direct response to the performance of the CMS.
I noted for myself the possibility of caching intermediate objects in the file cache. At least as long as I can only do this, there is no memcached or APC on the hosting.
We, like some domestic hosts and some foreign (for example webfaction), have a fixed number of apache handlers per user. Therefore, the classic testing of "attendance" is quite difficult to do in the sense of evaluating the results and I was too lazy. I succeeded with caching intermediate objects on the disk to generate pages with goods from 0.5 to 5 seconds. Is it a lot or a little? Pages with static caching can be considered almost static - about 0.01 seconds per generation. I believe that without caching, you can not talk about high loads, because this is all talk in favor of the rich. Just noted the fact that it is different.
Along with caching, there is clearly noticeable optimization in terms of the amount of static “junk” that each site generates, especially CMS. You can see for yourself in the properties of the page in your browser, how much and what is connected there. Nonsense, but "five old women - the ruble," the load on the operational part drops markedly.
Just the other day, my colleagues and I discussed existing wiki engines. There was a small dispute about the meaning of the WYSIWYG editor. I argued that it still only creates the appearance of what the result will look like, and therefore it does not carry much sense, that in the case of visualization, inline editing is required, which almost no one has. Just cited UMI.CMS as an example, since they have it, i.e. edit what we see. There was a question about the list of changes. What was my surprise when I saw the “change” button in the new inline editor, which also works - you can roll back the version of the change. There, of course, without describing the change, you need to guess on the coffee grounds what and when you cheated, but the fact itself.
I would also like to note an important, in my opinion, thing. Software in the history of product development has the property "stagnate." This is the notorious backward compatibility of Windows, and "UTF-8 experimental support" in the XXI century in Twiki, and many other examples. It was very joyful to see how a sophisticated CMS took and changed prototype.js to a more modern jquery. This is a very positive image indicator.
Here is such a fun release. We are looking forward to "retaliatory strikes" with curtsies towards exploitation from commercial CMS competing with UMI :)
Source: https://habr.com/ru/post/86815/
All Articles