Hybris – bought by SAP – my Hybris Performance Optimisation thoughts

Date: 23rd August 2013
Author: Deri Jones

Hybris is a widely eCommerce platform – a nice example of a European software company doing well.

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
–    cluster.broadcast.senderthreads.maxwait

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

Top