We’ve seen it in use at a number of our clients, and in the course of Hybris load testing at a few websites, have seen some of the ways it can be used well, or not so well – in terms of delivering a fast user. error free experience – (with or without the Hybris High Performance Module !)
Now that the sale of Hyrbis has completed: after the earlier announcement that Hybris is to be bought by the an other software company with European roots, the giant SAP: we’ll be interested to see if the new management can keep developing the platform without comprising the web user experience, or slowing Hybris speed overall.
So far SAP are making strong noises about the future of Hybris: in omni-commerce. But of course it’s not uncommon for divergent voices in feature development to cause a good product to become complex and lose it’s edge over time.
We’ll get an interesting angle from the 24/7 Hybris performance monitoring perspective I guess from some of the live User Journeys we’re running, so time will tell.
Appendix – some Hybris performance choices that get discussed:
Cluster broad casting thread max wait setting
UDP vs TCP as a broadcasting method.
Tomcat connector maxThread setting
Cache sizes too big wastes memory, don’t set too big without some analysis / load testing in your specific situation
Lucene Indexing versus search engine solr or etc
Virtualisation : may perform better on a Physical machine
Cluster size + configuration
Are threads lasting too long – ideally sub-second.
Generic issues such as:
Media / static content serving – keep off your Hybris servers – consider CDN