The Mind of a Performance Hacker

I had an unusual eureka moment in my car this evening. I get them now and then. Well actually according to Confluence, I’ve had 5 other “eureka” blogs since 2007. Apparently I had none this year. I had (3) in 2007 which must have been a good year for the team. One each in 2008 and 2009. So I was definitely due…

Within the last few months I have had the opportunity to reframe my technology perspective with the addition of Stephanie Tan on our team. Stephanie runs our Security practice. As I attempt my hardest to provide her with modest leadership and direction, I’ve found myself engaged like a mad man trying to minimize my learning curve in software security. I’ve re-read some old books that I had on the shelf. I’ve subscribed to a few periodicals. I’ve found myself at times scouring Google for hours upon hours researching new terms and concepts so that I have more context when I talk with Stephanie and others about security.

While I’ve been doing this, it finally hit me that security engineering (the safe kind we want to practice) is just a clandestine form of performance engineering. Now before you challenge me or turn the page, hear me out. If we say the platform of a security engineer is to engineer or construct solutions with the intent of penetrating, breaking or dismantling a software system, then I think it’s safe to say that a performance engineer has an almost identical focus. The performance engineer should be intent on breaking the system to affect responsiveness and/or scalability. In my mind they are one and one the same…both are trying to break the system. We are trying to break the system from a fairly positive perspective. We want to determine when users will abandon, when processes become unbearable and when the system shuts down.

 

Is that what we are doing today? “Not really“…says my inner voice. I don’t think we ask the question or questions about breaking a use case, component or system. I think deep in the back of our mind we want to ask this question. Our intention during our SPE exercises is to ask questions that should or could lead us to that ultimate question or question set about breaking a system. Unfortunately we don’t ask the question. The reason I know we don’t ask the question is that we don’t build experiments with the intention of breaking the use case, component or system. Lately we have been building experiments that tell us how fast or how slow something is. That something is usually a microscopic view into the use case, component or system. It typically interacts with “realistic” data attributes under “realistic” or normal behavioral characteristics.

 

Should we stop doing that? Well, not really. We need to take a step back and lead from the alternative. I say alternative because today our comfort zone is asking questions about “normal”, “realistic” and “common” attributes and characteristics tied to what we are building. It’s OK to ask those questions as they are essential to giving us better context on our product. The alternative questions have to be skewed toward “performance hacking”, meaning how can break the user experience from a responsiveness and scalability perspective. We don’t care about making a motherboard fry or burning a CPU to the ground (figuratively speaking). We do care about use cases that can single handedly bring a system to its knees. We care about processes that aren’t predictable and run from undisclosed periods of time. We need answers about how we can literally make a page unresponsive or a process die midstream. We need to see if we can force out of memory exceptions, deadlock a row or table or even cause a thread to lock. We should look at a scheduled task meant to run ever hour and try to figure out if we can make each iteration run for 65 minutes, then what?

 

We need to put our performance hacker hats on and figure out our performance and scalability vulnerabilities…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s