To start with, A web performance means different to different stakeholders (client, Business Analyst, Architect, Manager, Developer and testers). Overall, in the current scenario, a web's performance is analyzed by the response time (or page response time, or transaction response time).
The response time is the time taken by a HTTP page to appear to the end user (a person who actaully is browsing the web applciation).
This is obvious that for a layman the above definition is appropriate, but when we come to the broader one, we cannot set a gamut for it. For instance, an architect would be looking for the design pattern bottlenecks, the topology and network bottlenecks. A DBA would be interested to analyze the performance related to database parameters like- Long running queries or stored procedures, blockings (lockings), deadlocks, indices etc... A developer would be interested in finding out the bottlenecks in his own module/group of modules for the response time point of view (irrespective of the background processing in the environment)....A client would only like to know wheter his applciation is able to handle the specified number of user load and all the benchmarking parameters are as per the Service Level Agreement (SLA).
Whereas a tester has to look upon from bottom to top view of performance parameters... Unlike other stakeholders, he has to see all the covering parameters cater to the performance of application...
This was just an introduction on what actually a web performance means for a layman...and how its definition varies from person to person.
The response time is the time taken by a HTTP page to appear to the end user (a person who actaully is browsing the web applciation).
This is obvious that for a layman the above definition is appropriate, but when we come to the broader one, we cannot set a gamut for it. For instance, an architect would be looking for the design pattern bottlenecks, the topology and network bottlenecks. A DBA would be interested to analyze the performance related to database parameters like- Long running queries or stored procedures, blockings (lockings), deadlocks, indices etc... A developer would be interested in finding out the bottlenecks in his own module/group of modules for the response time point of view (irrespective of the background processing in the environment)....A client would only like to know wheter his applciation is able to handle the specified number of user load and all the benchmarking parameters are as per the Service Level Agreement (SLA).
Whereas a tester has to look upon from bottom to top view of performance parameters... Unlike other stakeholders, he has to see all the covering parameters cater to the performance of application...
This was just an introduction on what actually a web performance means for a layman...and how its definition varies from person to person.
Posts
No comments:
Post a Comment