When working on a project, you often discover that you need some functionality that would be useful in other projects, but using or creating a separate library is not desirable in separate workspace. Using an existing library is in many cases impossible since there may not be a library that meets your needs. Creating a completely separate library adds some overhead to the project. You have to create a new version control repository and you have to publish the binaries to an artifact repository.
Have you ever wondered how many concurrent users your application could handle? Since I began writing Scala code I wanted to know how “scalable” it really is. You don’t want to be embarrassed when your awesome product gets some traction and stops working with only a few concurrent users. And when it does stop working you want it to recover. This is where load and stress testing is required. And what better way to do this than with a tool written in Scala? This blog post I will introduce the basic usage of Gatling.
Update 19-04-2013: Updated all examples to Gatling 1.4.7.
Traditionally people have been taught to stay away from multithreading. Unfortunately this poses two problems. The first has been around for a long time: When waiting for I/O the system isn’t free to do meaningful work. The second is that while the clock speed of processors has frozen, the number of cores is ever increasing. Server software can perform much better when making use of all cores instead of just one.
Two weeks ago, I went to visit the Devoxx conference in Antwerp. During the three day conference I got an update on the current state of affairs in the Java world. The event was hosted in one of Europe’s largest movie theatres. I’m waiting for the talks to come online, so I can watch the talks I didn’t get the chance to see. I’m really looking forward to that. But until then, I’ll have to do with the talks I’ve seen in person.