The following story I find really interesting.
Bhaskar Sunkara, VP Product Experience at AppDynamics, presents “Performance on Amazon AWS”.
Among other things, AppDynamics is known to be used by NetFlix to monitor thousands of JVMs on Amazon AWS.

The presentation tells you about how Netflix partnered with App Dynamics to monitor their systems in a (more than) dynamic cloud infrastructure by AWS.
A large part of the presentation explains about what the important design principles are to be aware of when developing for the cloud.

Main message: machines will come and go, systems will go down. Application availability is in the hands of the developer. Develop for availability.

In my current role as application performance specialist I see a lot of different frameworks that are used to develop applications faster, to make a more reactive frontend application or just a framework that is the latest and greatest from a development point of view.

One of these frameworks is Google Web Toolkit. Frameworks like this are a good thing for development… but for performance testing they might be a problem.

For performance testing the best practice is to use a proxy server recording all traffic between a browser and the application. In most cases this is just plain http with html or xml as a protocol. So it is easy to replay the recorded test and parameterize it with different values. Read more

A number of my colleagues and myself recently decided to share our knowledge regarding “performance” on this medium. You are now reading the first blog in a series in which I present a test-driven approach to ensuring proper performance when we deliver our project.

Test driven

First of all note that “test-driven” is (or should be common in the java coding world. It is, however, applied to the unit-test level only: one writes a unit test that shows a particular feature is not (properly) implemented yet. The test result is “red”. Then one writes the code that “fixes” the test, so now the test succeeds and shows “green”. Finally, one looks at the code and “refactors” the code to ensure aspects like maintainability and readability are met. This software development approach is known as “test driven development” and is sometimes also referred to as “red-green-refactor”. Read more

A number of my colleagues and myself recently decided to share our knowledge regarding “performance” on this medium. You are now reading the first blog in a series in which I present a test-driven approach to ensuring proper performance when we deliver our project.

Test driven

First of all note that “test-driven” is (or should be common in the java coding world. It is, however, applied to the unit-test level only: one writes a unit test that shows a particular feature is not (properly) implemented yet. The test result is “red”. Then one writes the code that “fixes” the test, so now the test succeeds and shows “green”. Finally, one looks at the code and “refactors” the code to ensure aspects like maintainability and readability are met. This software development approach is known as “test driven development” and is sometimes also referred to as “red-green-refactor”. Read more

Browsing through the log files of any production system, you will be amazed on how many messages are logged on the Error level. It is not uncommon to find hundreds to thousands of error messages per day! When you point these out to developers or system administrators, the usual reply I get is: “Oh, that is normal”. Let me tell you: it is not normal. Any diagnostics message that is logged on the Error level, is an indication of a failure in the system. When a error log message references a situation that is not erroneous, that is an error in itself and they may  blind you for any real errors that are logged.

The fun part is that the application log is a very good indicator of the system’s maturity.
 Read more

Browsing through the log files of any production system, you will be amazed on how many messages are logged on the Error level. It is not uncommon to find hundreds to thousands of error messages per day! When you point these out to developers or system administrators, the usual reply I get is: “Oh, that is normal”. Let me tell you: it is not normal. Any diagnostics message that is logged on the Error level, is an indication of a failure in the system. When a error log message references a situation that is not erroneous, that is an error in itself and they may  blind you for any real errors that are logged.

The fun part is that the application log is a very good indicator of the system’s maturity.
 Read more

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 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