I've been given the task for creating a performance model for a legacy product. The product is about 10 years old and has never had any performance requirements or performance models before. Generally whats happened in the past is a customer will complain that a particular feature is slow or they are not getting the throughput that they want/need and the developers will investigate and see if any more performance can be squeezed out the code for the feature.

Since the product doesn't have any hard measurements and metrics for past versions I fell all I can do is create baselines for the current version and go from there. Other developers sometimes notice that memory usage is really high and ask why. Also, I am new to the product so I don't know all the feature points (which there are hundreds to thousands) and the performance cost of running each.

The program is an ASP.NET/.NET 2.0 webapp on IIS 6. I've started looking into performance counters and the CLR Profiler to start getting measurements. I've also read the following docs:

Measuring ASP.NET Performance

Improving ASP.NET Performance

So my question is: How can I create a performance model for a legacy product that I am new too and hasn't had a performance model/requirement in the past?

  • 1
    How does the application being 10 years old affect your ability to create a performance profile? Wouldn't you use the same techniques as you would on a (relatively) new application? Sep 1, 2011 at 19:29
  • I think this is talked about in the Metrics book, but I loaned it (along with all of my process textbooks) to the process group temporarily.
    – Thomas Owens
    Sep 1, 2011 at 19:51
  • This is a case where being new is helpful, you will need to measure to identify problem areas and not make assumptions just based on yout gut feelings from knowing the system. Often the new person can see where things need to improve much more easily than those with years invested in the system especially those who did the orginal design.
    – HLGEM
    Sep 1, 2011 at 20:07
  • Good point, the age of the product really doesn't affect my abaility to create a performance model for it. The age really has to deal with what have customers come to expect in term of performance (either implicit or explicit) from the product over the years and what have other developers told customers what level of performance they can expect
    – Spacebob
    Sep 1, 2011 at 21:23
  • 10 years old is hardly "legacy" (it is legacy as much as yesterday's code). The majority of applications I use daily have been in development for more than 10/15 years.
    – Rook
    Sep 3, 2011 at 22:13

3 Answers 3

  1. Start with the web server logs to understand the profile of the load, how many users are using the system on a daily basis and which pages they are going to. Most business processes will have leaf node pages which are distinct enough to allow for direct collection of how often a business process is completed within a given time window and matched to the number of users on the system. If you have the logs for multiple years then by running the same set of queries on a regular sample basis, once every three months as an example, you will be able to show changes in usage patterns over time, including any increases in the user base. These increases are critically important if you will be conducting performance tests so the load can be projected outward a good 12-18 months to see what performance will be like in the future.

  2. Next, speak with product support within your organization. This is an oft overlooked part of the organization which captures user expectations. Check with their management and their logs/call coding to see what people call in on most often from a "slow" perspective. These are your critical timing events. You may have a general response time category for the interface, but these events that people call in on need to have explicit call outs in your performance requirements.

  3. Speak with the business owners about your findings. Use the findings as a framework for additional requirements/prioritization on what you have. Most of the time additional requirements will come out of this discussion.

  4. Incorporate these items into your standard requirements document for the product future revisions

  5. Work with development to implement unit, component assembly and systems integration tests tied to performance as noted in the requirements. It does not hurt here to have a feedback loop so developers can see a build to build difference in performance and also be assigned ownership for fixing performance which declines from build to build.

  6. Measure performance in functional testing. If it does not work for one, then it will never work for many. The earlier you can find a performance defect the better because performance testing is usually the last 100 yards on the track before you ship. The more time you can save up front the better.

  7. Make sure your performance test tool can effectively test your interface and you are measuring against your critical timing points.

  8. Once you make it to production find a way to measure the same elements on a consistent basis in production to see if what you are observing in production matched what you were seeing in test. Modify your next generation requirements based upon your observations

  • Nice answer, covers exposure to the product as well getting data from QC to find out what the norm is
    – Spacebob
    Sep 15, 2011 at 19:45

More than likely a good part of any performance you will want to measure and improve has to do with access to the database and database performance. So your performance plan will need to consider how to measure that and what to look for in terms of pain points.

You don't say what database backend you are using but I suggest you read up on performance tuning for the database you use as your backend. Performance measurement and tuning for databases is often quite specific the the database engine you are using.

For SQL Server this would be a good book to start with: http://www.amazon.com/gp/reader/1430219025/ref=si_aps_sup?p=random&ie=UTF8&qid=1314907292#reader_1430219025

I would also get myself up to speed on using the SQL Server Profiler if that is your back end.

  • For most applications the DB access would be a major bottleneck but for our application I already know that is not the case. Our application is very render heavy on the server side so thats where most of the bottleneck is.
    – Spacebob
    Sep 1, 2011 at 21:18

I'm not entirely sure what your application/system is, and what it's purpose/userbase is, but I'll let you know how I would approach the task.

I would first seek to break the system down into sub-systems, or components, that are relatively self-contained with only a handful, at most, interfaces to the other components. If you can build and run these individually you will be able to better monitor their performance, and associated resource cost. If you find a particularly resource-intensive process or thread it also allows you to manage the 'drill-down' to find the root cause. The scale of these steps is totally dependent on your architecture.

If it's possible for you to isolate and monitor feature chains, all the better. I'm not sure how much effort you have been assigned by management to perform this task, and unfortunately that will always be the primary driver (depending on your upwards influence) of what you can achieve. But I have found a break down into smaller units to be a fantastic approach to most aspects of software engineering - including performance modelling!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.