Previous time I blogged about the last step of the seven steps, step 7: Share the responsibility for the whole chain, a non-technical but rather a communication and behavior thing which I found crucial for success. We now have reached the end of this series and I’ll sum up the topics we’ve dealt with and draw some conclusions. Read more →

Last time I blogged about performance tuning based on evidence, the tuning cycle and some best practices. This time I’ll blog about the last step of the seven steps: sharing the responsibility for the whole system chain.

When an incident happens in production, this usually means stress. A performance problem in production often leads to finger pointing. Read more →

Last time I blogged about the relevance of monitoring and diagnostics in production to solve incidents quickly and prevent future problems. This time I’ll talk about tuning based on evidence.

If an application turns out to be too slow, tuning can provide a solution. Tuning can take place on multiple levels. Adding hardware can be a cheap solution. However, when you add hardware at a place where the bottleneck is not located, this has little use.
Read more →

Last time I blogged about the importance of continuous performance testing. When you write and run performance tests continuously, just like unit tests, you get early performance insights in new and changed features of your software. This will minimize surprises and be more productive. Now I’ll blog about monitoring and diagnostics.

When a new version of the software is released into the production environment, the question always is: will it actually perform like we saw in testing and acceptance environments? And we keep our fingers crossed.
Read more →

Last time I blogged about the importance of representative performance testing. Having production-like properties for hardware, OS, JVM, app server, database, external systems and simulated user load are essential to prevent bad performance surprises when going live. In addition, I described how cloud computing can be utilized to generate high loads on-demand without having to worry about the infrastructure.

Continuous performance testing
With a representative test as one of the last steps before going live we prevent that expensive bad-performance surprises will pop up in production. However, the same surprises will pop-up, only earlier and with less impact. To save costs and prevent large architectural refactoring, it is crucial to test for performance as soon as possible. This is just like any other software defects and Quality Assurance: the later in the development process defects are detected, the more costly these defects are.

At a popular web shop I had the following challenge: Read more →

Last time I blogged about the importance of benchmarking the architecture and new technology in a Proof of Concept for Performance. This time I’ll deal with the importance of representative performance testing.

Slowness of applications in development environments is often neglected with the rationale that faster hardware in the production environment will solve this problem. However, whether this is really true can only be predicted with a test on a representative environment and in a representative way. In such an environment, there needs to be more representative than just the hardware.
Read more →

Last week I blogged about setting your performance goals: defining your requirements. This time I’ll blog about the importance of a Proof of Concept for performance.

The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
Read more →

Last week I blogged about how performance problems manifest themselves: frustration, loss of revenue and disruption of development; and how adding hardware is a questionable solution. This week I’ll blog about the first step to assure web performance.

It can be a valid choice to run the risk of performance problems in production and deal with them in a re-active manner. However, it is usually wiser to be pro-active and prevent them. This approach brings more certainty, peace of mind and also saves money. It consists of seven steps. Step 1: Define performance requirements.
Read more →

Last week I blogged about the increasing load at web shops and the increasing challenges for developers and operators. The question to be answered was stated as: how can we prevent performance and availability problems; how can we assure that a web site is always quick and available? In this blog I’ll describe some of the forms in which I found performance difficulties to present themselves. Read more →

By Jeroen Borgers

More and more Internet users buy in web shops these days. Research shows that the part of European Internet users that buys on-line has grown from 40% in 2004 to 80% in 2008. Additionally, large web retailers in The Netherlands see their revenue grow just as if the recession has never materialized. Business seems to be flourishing.Read more →