In a recent Aberdeen Research study, 70% of organizations are worried that adding new applications will increase the consumption of network capacity.

My first reaction was, "Duh. New apps always bring new traffic."

That seems obvious to me as a web developer. It would seem undeniable by anyone - even point haired Dilbert managers.

Fear the User

But then it hit me: consumption of network capacity shouldn't be the biggest fear.

When a new application is released, there are so many potential points of failure that everyone involved should be scared sleepless. Even the best QA teams miss some bugs. The most skilled web developers don't anticipate all of the issues.

Functional testing for defects has always been and always will be a top priority. Developers write code; developers run code; developers see bugs; developers fix code; developers call it done. That's how I did it when I first started.

Bugs are identifiable. You can put them in a database. You can watch them get checked off the list. It's rewarding to see the defect list shrink.

Fewer developers have a check list for performance issues. Not many developers are concerned with consumption of network capacity. Developers that load test their web apps are not as common as I once thought.

Why are web performance issues ignored until some users complain?

Often developers ignore performance testing because it is too hard. It takes too much time. We don't have the server capacity to generate load. We don't have a tool.

Many times it is too expensive. There is no budget for load testing, so we can't pay any consultants to do it, nor can I buy what I need.

Perhaps there is no time in the project plan. How many times have you heard a project manager say something like, "The deadline is Monday. There's no time to load test it. Let's put it in production and watch our traffic levels. We can all get on the system then and see how it responds to us."

Some developers just assume that their app is written "well" so it will perform well.

Some developers stick their head in the sand because they have no performance engineering experience. They simply don't know how, so don't mention it (maybe nobody will notice).

Some developers don't care. "It's not my job. I am paid to write good code that contains all the features requested. There aren't any performance definitions in the requirements doc."

Network Capacity Isn't the Problem

While there are some companies throttled with bandwidth in their data center, most web applications today are hosted in an environment with excessive pipe to the Internet.

There are many reasons for poor response times or errors returned to users. We need to focus on the smaller components - examine all the moving parts of the application environment.

For example, NIC cards can be a bottleneck in web performance, but that really isn't the network capacity. Getting data in and out of your application through the NIC can be a significant challenge, so anyone concerned with performance should analyze this potential point of failure.

Beyond the data center issues, web developers need to pay attention to how they write their code. How many times have you found an inefficient loop in your program that iterates through a list just fine when there are 100 records in your data set, but it grinds performance to a crawl when there are 100,000 records? As a young programmer, I overlooked these scale issues several times. I was prone to make too many assumptions.

What are the built-in bottlenecks of the architecture? If you haven't it learned it yet, you will inevitably become aware that the database is always a potential performance problem. Web servers and load balancers are also prime candidates for tuning.

It's Never Simple, but It's Important

I guess my point is that new applications should always be load tested. Performance is too important to overlook. Network capacity is the least of our worries when thinking about adding a new app to the portfolio. Implementing a new app correctly should always have time, money, expertise, and tools for performance engineering allocated as a part of the project plan.

Even on a limited budget, do the best you can with open source tools or something like LoadStorm. It will be worth it.