Recently in JStress Category

I've released a new version of JStress. Many libraries have been updated. Dead code removed. Packaged it into a single jar file, libraries included, so it can simply be pushed to a remote system and run. And lastly, provided R scripts for generating profile plots from a a LinearStepRun.

Below are a few R functions I use to evaluate and tune our Squid caches, which we use in accelerator mode. The functions work by taking a real stream of requests from either an application or squid log. From there the arrival rate can be determined at every second. Or a filter can be applied and the cache hit ratio or arrival rate re-determined. Or better yet, the series can be filtered a number of times with different filter values to determine the best value for a given filter.

This blog entry has inspired me to make a few notes to work out some ideas through this rather meandering essay.

In very simple terms (read convenient simplification, see below), a queue is a serialized list of pending requests. And it is typically used to broker/filter/throttle requests to a naturally concurrent system behind it. What's interesting is that systems are typically compositions of other naturally concurrent (sub)systems. Turtles all the way down, if you will...

In response to 'test driven development', I propose 'stress driven architecture'.

A new version of JStress has just been released along with a sporty new web site.

When developers are asked to load test a system, most will start up a million threads to create a load on the server showing that it will eventually become un-responsive, but they have no numbers that allow them to create a load profile so they can properly plan for peak times in a production environment.