![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|||
Performance
Investigation
|
![]() |
Increase the performance of key areas of your system ... Introduction
| What is involved? | Why use a system
model? The most common reasons for optimising the performance of a system are:
Response time can be reduced by various techniques, including reductions in the quantity of data transfer, use of caching (and pre-caching) and more efficient resource sharing. However, it is vital that the most effective techniques are employed, rather than adopting an inefficient scattergun approach (i.e. try every method available and get the performance gain by chance). A real life example was implemented by us on an intranet system, where the feature in question had become inefficient as the amount of data increased. The database logs showed the majority of the time to be spent in the data retrieval request. The proposal was to use a stored procedure, which would give a 10-20% performance gain; which was insufficient. However, investigation showed the time to be spent on making the request thousands of times. The request was rewritten, in 10-20 lines of code, passing in at least one hundred identifiers of data at a time (the database could not cope with a larger sql statement). The overall effect was to speed the response up by 10 times; 5 times faster than required. System resources can be better utilised by a variety of techniques, including caching, sharing and duplication. In some cases, just using a faster virtual machine or better compiler can give sufficient performance gains. In others, available memory may need expanding or even reducing. Another real life example applied to the time spent on memory garbage collection, which would be added to the response time of some requests. The task was to determine the optimum size of memory to allocate to the server process. Experimentation showed that as the memory size increased, the collection time also increased (though the time between collections also increased). So, even though less memory is typically worst for performance overall, in this case, a smaller ammount of memory resulted in more frequent garbage collections with less impact on the individual user's requests.
The following performance optimisation methodology is used:
Where each stage is repeated when necessary to cope with changes in the system as optimisation takes place; until the required performance gains have been made. One vital component of optimisation is the focus on a model of the system. Without this focus, many attempts to improve performance concentrate on just the response time, without also focusing on the resource usage. If resources are available (e.g. the database server is lightly loaded), then response time can be gained by greater use of another resource. However, if the resource is heavily loaded, this would be the worst possible option. Development based optimisation tends to concentrate on optimising pieces of code in isolation, without considering the effect on other parts of the system and/or if any significant performance gain is made. Also, the lack of consideration of the 'big picture' means that the system can just become more complex, instead of simpler. If you are interested in performance investigation, please contact us for further information. |
Tel: 0114 2361138 Mobile: 07812 448142 email: Apologies - removed due to spamming |