Upthrust

Default distribution of WSO2 BPS comes with embedded H2 database as BPEL engine’s persistence storage and other settings which are suitable for use in development environment. But when you are going to production with WSO2 BPS, there are several configurations you need to change according to your production requirements. These configurations will change based on how much requests BPS is going to handle per second, your auditing and monitoring requirements, performance requirements and nature of your process. Following are the main things you should do before going production with WSO2 BPS.

• Configure external database server like MySQL as your persistence storage instead of embedded H2 database. You may experience slight performance gain for simple BPEL processes with H2 database, but when it comes to multiple concurrent requests and complex processes H2 can’t server your performance needs.
• Configure multi-threaded Http connection manager connection pool settings to suits to your BPEL processes. There are two configurations in Http connection manager. One is max total connections and other is max total connection per host. These settings will depend on number of concurrent requests BPS needs to handle and number of external service calls in involve per process instance.
• Configure BPEL process persistence. If you are implementing process with request-response interaction model use in-memory processes instead of persistence processes. Whether to use in-memory or persisted processes will mainly depends on your business use-case.
• Configure even-filtering at process and scope level. You can save lot of database resources by reducing number of events generated.
• Using process-to-process communication. If you are calling one BPEL process from another BPEL process deployed in the same BPS instance, it’s better to use process-to-process communication to reduce overhead introduce by additional network calls.
• Also make sure to configure process instance cleanup. Large number of process instance data will be accumulated in the BPEL engine persistence storage if you persisted processes, so to reduce performance overhead introduce by database size you should configure instance cleanup.

In addition to above things you should be careful when deploying WSO2 BPS in virtualized environments. We have seen random increase of network latencies and random performance degradations when running on VMs.

Update 1: Above mention configuration optimizations are true for Apache ODE also.

Update 2: Above mention best practices are valid for WSO2 BPS 2.0.2 and upward. You can do the above optimizations to older versions WSO2 BPS, but configurations and configuration mechanisms will be different. All of the above optimizations are supported by Apache ODE, but configuration is very different from WSO2 BPS.