Posted by Jarl Meijer in the early evening: November 24th, 2011
Imagine you are playing a game of rugby against some blacksuited guys who are doing some odd dancing and screaming exercise before you finally get to start playing. You win the game 27 – 3. You can imagine it wasn’t just one beer at the big party after the match and you did not see home before early morning. A year later your team finds itself in the same stadium against the same guys, doing the same little piece of folk dancing, just a little louder than last year. This time you win 27 – 6, only. The coach and the crowd are going mad: your team lost half of its performance in just a year time! You take a shower, no beers, go home and go to bed early. Measuring the improvement in performance is easy! How about Scrum teams? ….
Posted by Erwin van der Koogh mid-afternoon: June 24th, 2011
To celebrate my move to the Agile Consulting and Training division of Xebia I thought it would be very appropriate to start playing with some hip new technologies.
From their homepages:
Node.js: Evented I/O for V8 JavaScript. (A framework for building completely non-blocking servers in Javascript)
NPM: A package manager for node.
CoffeeScript: A little language that compiles into JavaScript
Express: High performance, high class web development for Node.js
Jade: Node Template Engine
Redis: An open source, advanced key-value store
In this guide I will take very small steps so that you can verify that you are check whether you are still on track.
The result is an extremely performant, scalable and lightweight alternative for web development.
Posted by Mark Bakker at around evening time: June 22nd, 2011
In my current position as Performance Engineer and in my past position as a Middleware Architect I did quite some work with closed source performance monitoring and analysis tools (i.g. CA Wily and later AppDynamics).
These tools are both expensive but also do quite a good job most of the times. In the same field there are more tools, but all in the same price range for as far as I know.
To name some: Foglight, Dynatrace, Newrelic, JXInsight, Tivoli Performance Viewer, Compuware Gomez.
Around 2006 several initiatives to create open source performance monitoring tools for java production environments started to appear.
This was mainly because AOP (Aspect Oriented Programming), the technology used in most of these products, was getting attention in the market and there were quite some developments in that area at the time.
I am interested to see how the open source community around these kind of products is evolving. The outcome is quite surprising…
Posted by Jarl Meijer in the early evening: January 6th, 2011
2010 has ended and a new year has begun. 2010 offered us a lot of learning opportunities. It was a good year for the Agile community in the Netherlands and in the world. We saw more and more big corporations embrace Agile methodologies and put serious effort into making it work for them, mostly as a project methodology. ‘Agile adoption’ was THE 2010 word, maybe on par with ‘Wikileak’. So what do we think will be hot in 2011?
(more…)
Posted by Jeroen Borgers at around evening time: January 20th, 2010
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. (more…)
Posted by Jeroen Borgers in the late evening: November 18th, 2009
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. (more…)
Posted by Jeroen Borgers in the late evening: November 2nd, 2009
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.
(more…)
Posted by Jeroen Borgers late at night: August 31st, 2009
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.
(more…)
Posted by Jeroen Borgers at around evening time: July 22nd, 2009
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: (more…)
Posted by Jeroen Borgers at around evening time: June 29th, 2009
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.
(more…)