Sarquol Limited

When drawing a graph of the response time performance of a system with increasing load it will usually follow a standard profile, namely:

• A very low load increasing the load will actually improve the performance of the system slightly. This is because most systems use various caching mechanisms and if there is too little load none of the caches will have data in.
• As the load increases a near flat region will be experienced, where all requests act as if they have near dedicated resources available to them. Continue reading ‘The generic system performance profile’ »

 Last year (in this article) I asserted that monitoring of all user operations on an on-going basis was highly valuable. At the time I was not aware of any automated tools to do this task, meaning that solutions would need to be implemented on a per-application basis. In the worst case, this could mean laboriously adding logging statements into application code and then providing analysis mechanism to extract meaningful information from this logging. Continue reading ‘Monitoring all user interactions’ »

The level of performance proof required of projects can fall on both sides of an optimal “cost – benefit” line for a system. If a project spends too little effort on proving performance then the result will be problems and complaints in production. If a project has overly stringent performance criteria, the result will be high costs and long delivery delays for the project. Continue reading ‘How much should be spent on ensuring system performance?’ »