Performance always matters
An application and its environment should be designed with performance in mind. The application, the server it runs on, the database it communicates with, the network it communicates over: all of these elements should be performant. Creating an efficient, elegant mechanism is not only important for a business, but a matter of skill and pride for engineers.
Although true, perhaps that is not the answer one is looking for. When does performance matter? is too broad. The following discussion helps clarify the question, how to answer it, and what to do about it.
Good applications and protocols should work well on a variety of systems. By contrast, performance testing and tuning have system-dependent components. For instance, an application can be tuned to balance throughput versus response time in ways that are mutually exclusive. So out-of-the-box settings may not strike the perfect balance that yields optimal performance for a given use case.
The figure depicts a relatively simple environment. A user’s node interacts with a Mule ESB node, which is also connected to a database. Each node runs a salient application: Mule ESB, perhaps Firefox for the user, and MySQL. Those applications are running on operating systems. Each node’s software in turn runs on particular hardware. And then there is the network connection. Observe that even this simple system has many components that can affect important performance metrics.
Consider an example from the engineers’ standpoint. Deb develops an application. Before deploying the application to production, she asks Percy to assess the application’s performance. Percy tests the application, finding that it can handle up to 1000 concurrent users before hitting a bottleneck. Percy’s official report should specify his testing environment. Performance statistics can always be changed by adjusting the run-time environment.
When is performance tuning worthwhile for a particular use case?
For deploying an application on Mule ESB, the best question is whether or not a particular case warrants extra calibration. Here, “particular case” refers to the application running in a given production environment. Are higher throughput or lower response time important? Is it infeasible, unhelpful, or uncouth to throw more hardware at the problem? If so, then performance tuning is the way to go.
Returning to the example above, assume Percy finds that the application hits a bottleneck at 500 concurrent users. Percy’s testing environment is analogous to the production environment. The system needs to handle at least 1000 concurrent users. What should Deb and Percy do?
If Deb created an application on Mule ESB, she and Percy can use MuleSoft’s Performance Tuning Guide. The Guide can help them reach their performance goals through adjustments at both the application and environment levels. More specifically, Deb and Percy can tailor the application, Mule ESB settings, and other aspects of the system to meet their needs. Mule does not know, for instance, that Deb and Percy want to prioritize throughput over response time. Fortunately, adjusting Mule’s behavior is easy. Check out the Performance Tuning Guide here: Performance Tuning Guide.
