The Broadleaf Microservices Architecture not only provides implementers the flexibility to start simple, but also provides you the power to scale when you need to. A big component to this revolves around the Flex Package Composition architecture described here: Deployment Flexibility
We’ve put Broadleaf to the test simulating real world commerce scenarios from flows demonstrating industry standard Black Friday and Cyber Moday metrics to more extreme transactional use cases in the "thousands per second". We highly recommend digesting the information in our scalability white paper that describes our approach to achieving these results. We also recommend using this report as a baseline guide for infrastructure sizing and planning exercises.
Sign up to download our scalability white paper here: https://www.broadleafcommerce.com/resources/broadleaf-scalability-study
Broadleaf has the ability to scale horizontally with microservices and is ideal for cloud-based environments, especially those leveraging Kubernetes.
We provide a lot of support for deployments on a Kubernetes cluster including baseline sizing guides and comparative performance testing results on different sized clusters.
The scalability white paper introduces a naming scheme that combines application
and infrastructure sizing into a shortened name like
Given that many of our clients use our framework to support a variety of different commerce needs, the variety of services being used differ from implementation to implementation, and the level of customizations and external integrations can highly influence performance metrics - it’s not feasible for us to give a "one-size-fits-all" sizing or tuning recommendation that will work for everybody. With that said, we do have general guidance and strategies that should aid when conducting your own performance and load tests.
Determine your initial hardware footprint based on the particular throughput you expect to achieve for your implementation. Use
Appendix B in the Scalability White Paper as a reference for Node Pool sizing and and Database specifications.
The performance of the system will be most sensitive to adjustments in CPU core request configuration
In general, we’ve found that the most efficient sizing when using the
Balanced Flex Package utilizes
Cart Flex Package replicas, and
Browse Flex Package replicas.
When determining how to optimize resources in your cluster based on your implementation you will want to conduct your own load test. When doing this, start with liberal node sizes and do not define pod constraints to begin with. Run the load test and review
kubectl top pod results to see where resources are naturally allocated. Use this as your guideline and use
replicaCount to scale to meet your objective and create baseline constraints.
When your looking to scale the Node Pool (e.g. going from a
BM3 to a
BM5 configuration), here are two strategies to consider:
Scale the nodes in your your current cluster (just increase the node count).
Vertically scale the existing nodes (e.g. 4 CPU to 8 CPU) - which in most cases will require a new node pool to be provisioned with the new node sizes. Both node pools can be used or you can move all traffic to the new node pool using native Kubernetes facilities.
Much more detail around these recommendations can be found in the Scalability White Paper, particularly in