Hybris is a very widely used platform for eCommerce. It is a somewhat complex piece of software, with multiple interacting components.
When trying to obtain optimal performance, there are a few guidelines you’ll need to follow. We’ll review them in this post.
Number of CPU cores for Hybris server
The number of CPU cores will be directly related to the amount of traffic your website will get.
Hybris’ basic performance metric is the Page Views per Second (PVS) which is, as you’ll guess, the number of pages an Hybris installation is capable of delivering every second.
Hybris “Out of the Box” (OOTB) is estimated to be able to deliver 7 to 9 PVS per CPU core. This takes into account the fact that the adding more cores will improve Hybris performance as expected.
This is for Hybris OOTB. Your specific installation might have lots of custom code which will have a direct impact on performance.
This is also for a somewhat “standard CPU”, which might have different performance than what you use.
You will most likely need to compute an adjustment factor by performing a load test on your specific installation and then calculating the adjustment factor based on the result.
Whether the number of core you deem necessary is in one single Server / VM or many is somewhat irrelevant. You might want to spread on multiple load-balanced VMs to make the setup more fault tolerant.
Amount of RAM for Hybris server
Next you’ll need to estimate how much RAM each Hybris server should have.
SAP suggests that you should provision 2 GB of RAM for each core. So if you have a server with 8 cores, it’ll be best set it up with 16 GB of RAM.
This is due to the fact that Java’s JVM garbage collecting mechanism doesn’t scale linerarly with the amount of RAM, and therefore you might degrade performance (by having longer pauses caused by garbage collection) by adding too much RAM.
70 percent of the available RAM should be allocated to the JVM (Xms and Xmx flags), and the rest left to the OS.
It is advised to disable SWAP usage entirely.
Hybris can use SolR for it’s indexing / searching needs. You can use the same SolR server to perform both indexing and searching, but this means that searching performance might be reduced during a catalog indexation.
Therefore it is suggested to have a SolR master to perform indexing jobs, and a SolR slave to perform searches.
As for indexation, SolR will rarely be the bottleneck. A typical Hybris product extraction job will produce around 30 to 40 documents per second, while a SolR server will be able to index documents at a rate around thousands a second.
A typical SolR server will be set up with 8 cores and 16 GB of RAM (both for the master and the slave).
Hybris also supports up to 2 SolR slaves for performing searches, which allows to spread the load and increase fault tolerance.
Hybris supports a few databases engines (Oracle, MySQL, Percona XtraDB Cluster, …), but doesn’t offer much guidelines as to what to setup.
It is however very demanding with respect to the quality of the connection between Hybris and the database. A microcut might require a long restart of the Hybris server.
Also, SAP recommends having a network latency lower than 1 ms between the Hybris server and the database, which might be a challenge if you are considering a multi-datacenter architecture.
One thought on “SAP Hybris platform sizing guidelines”
Can you give more information on why you recommend to disable swap usage on hybris servers?
Comments are closed.