Alternative announcement of a new release of UMI.CMS
I am actively following the market for 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 manifestation of the interest of colleagues in this matter. Such a historical seed for the appearance of this post was my report Expert evaluation of some CMS as applied to mass hosting . In short, I talked about the fact that CMSs are heavy, usually inconvenient to operate, that the opinion of their business efficiency is orders of magnitude higher than the deplorable reality. I also called for a dialogue between CMS developers and host exploiters.
Two years have passed. Something has changed. Something for the better, something for the worse. And the other day I noted for myself a curious release from the point of view of operation and needs 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 that such a small thing, but how many consequences it has. Firstly, this 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 made an injection for the future :) Thirdly, it will allow using encoded versions of CMS along with all kinds of “accelerators” only with their “glitches”, without imposing ZendOptimizer features. In particular, this will allow you to really test hosting with accelerators without trying to transfer the already purchased finished version of CMS there. I understand that UMI is simply trying to take its place in the market in all possible ways, including hosting hosting. But this is good, because that is what is healthy competition in a market economy.
The second thing I can only understand interlaced is integration with 1C accounting. Judging by the announcement, UMI slightly “tipped” 1C-Bitrix in terms of integration with 1C. I specifically googled - it seems to be true. You should especially pay attention to the CommerceML keyword. I think such an attack on the side of a senior competitor will cause a surge in the “arms race”, which is always useful in business to create a healthy atmosphere in the market.
I could not resist and put a new version of UMI.CMS http://umicms.diphost.ru on a shared virtual hosting server (I specially chose not fresh) . This is just a demo site from the same CMS kit. I specifically turned off ZendOptimizer in php.ini to eliminate a marketing error.
Immediately I note the remaining unshakable thing - UMI.CMS remained demanding on the disk subsystem. Any "plug" on the disk gives a direct reaction to the performance of the CMS.
Noted for himself the ability to cache intermediate objects in the file cache. At least for now, I can only do this, on the hosting there is neither memcached, nor APC.
We, like some domestic hosters and some foreign ones (for example webfaction), have fixed the number of apache handlers per user. Therefore, the classic testing of "attendance" is quite difficult to do in terms of evaluating the results, and I was too lazy. I was able to generate pages with goods from 0.5 to 5 seconds with caching of intermediate objects on the disk. Is it a lot or a little? Pages with static caching can be considered almost static - about 0.01 seconds to generate. 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 all different.
Along with caching, optimization is clearly noticeable in terms of the amount of static "junk" that each site gives out, and especially CMS. You can see for yourself in the page properties in your browser how many 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 were discussing existing wiki engines. There was a little debate about the semantic load of the WYSIWYG editor. I argued that it all the same only creates the appearance of how the result will look, and therefore does not carry much semantic load, that in the case of visualization, inline editing is required, which almost no one has. I 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 a description of the change, you need to guess on the coffee grounds what and when you changed, 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 tendency to “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 nice to see how a fairly sophisticated CMS took and changed prototype.js to a more modern jquery. This is a very positive image indicator.
Here is such a funny release. We look forward to "retaliatory strikes" with curtsies in the direction of operation from competing with UMI commercial CMS :)
Two years have passed. Something has changed. Something for the better, something for the worse. And the other day I noted for myself a curious release from the point of view of operation and needs 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 that such a small thing, but how many consequences it has. Firstly, this 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 made an injection for the future :) Thirdly, it will allow using encoded versions of CMS along with all kinds of “accelerators” only with their “glitches”, without imposing ZendOptimizer features. In particular, this will allow you to really test hosting with accelerators without trying to transfer the already purchased finished version of CMS there. I understand that UMI is simply trying to take its place in the market in all possible ways, including hosting hosting. But this is good, because that is what is healthy competition in a market economy.
The second thing I can only understand interlaced is integration with 1C accounting. Judging by the announcement, UMI slightly “tipped” 1C-Bitrix in terms of integration with 1C. I specifically googled - it seems to be true. You should especially pay attention to the CommerceML keyword. I think such an attack on the side of a senior competitor will cause a surge in the “arms race”, which is always useful in business to create a healthy atmosphere in the market.
I could not resist and put a new version of UMI.CMS http://umicms.diphost.ru on a shared virtual hosting server (I specially chose not fresh) . This is just a demo site from the same CMS kit. I specifically turned off ZendOptimizer in php.ini to eliminate a marketing error.
Immediately I note the remaining unshakable thing - UMI.CMS remained demanding on the disk subsystem. Any "plug" on the disk gives a direct reaction to the performance of the CMS.
Noted for himself the ability to cache intermediate objects in the file cache. At least for now, I can only do this, on the hosting there is neither memcached, nor APC.
We, like some domestic hosters and some foreign ones (for example webfaction), have fixed the number of apache handlers per user. Therefore, the classic testing of "attendance" is quite difficult to do in terms of evaluating the results, and I was too lazy. I was able to generate pages with goods from 0.5 to 5 seconds with caching of intermediate objects on the disk. Is it a lot or a little? Pages with static caching can be considered almost static - about 0.01 seconds to generate. 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 all different.
Along with caching, optimization is clearly noticeable in terms of the amount of static "junk" that each site gives out, and especially CMS. You can see for yourself in the page properties in your browser how many 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 were discussing existing wiki engines. There was a little debate about the semantic load of the WYSIWYG editor. I argued that it all the same only creates the appearance of how the result will look, and therefore does not carry much semantic load, that in the case of visualization, inline editing is required, which almost no one has. I 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 a description of the change, you need to guess on the coffee grounds what and when you changed, 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 tendency to “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 nice to see how a fairly sophisticated CMS took and changed prototype.js to a more modern jquery. This is a very positive image indicator.
Here is such a funny release. We look forward to "retaliatory strikes" with curtsies in the direction of operation from competing with UMI commercial CMS :)