Contents
Metrics are used to define quantitative measurements for the quality of your website - they are basically a definition of the performance goals that you want to achieve.
Many metrics can be defined, but often cover your goals for performance and concurrency. In particular, factors which can be difficult to quantify, and are often prone to emotional assessment:
“our website is much too slow today” - when does slow qualify?
“everything grinds to a halt when my colleague logs in” - how many concurrent users can the system support?
“when I search, the system grinds to a halt” - which sort of search requests are impacting the system?
“it takes ages to download the file” - what are acceptable download times (under normal network conditions)?
Target Metrics are defined at the start of a project to:
indicate the expected dimensions of the website you will offer
indicate the minimum quality which you want to achieve
define how these factors will actually be measured
During development of the project they can be updated and tuned as appropriate. After the project has been successfully implemented, they can be used to help you control your installation and monitor / maintain the required levels of service for ongoing operation.
As always care must be taken when defining the target metrics:
if set too high they may be completely unattainable
if set too low fluctuations may not be highlighted
to ensure that they can be repeatedly and consistently measured
to provide a balance across the different factors being measured
certain metrics will relate to a test environment, but some should reflect real-life scenarios as they must be measurable, and reproducible, on your production website
prioritize the metrics according to their significance to the website
limit the metrics to a set that can be realistically monitored
When used properly these metrics can provide a useful tool; when used irresponsibly they can be a time-wasting distraction. As always, you need to understand what you are measuring, how you are measuring it and why.
![[Important]](../resources/important.png) | Important |
|---|---|
This section will deal with the basic principles and issues to be considered. Each installation is different, so the actual values to be measured will differ. |
All metrics to be measured will, in some way, be affected by the design of your project. Conversely, many issues will be best solved by design changes.
Therefore, you should define your target metrics before your design has been finally decided. This allows you to optimize your design based on these factors. Once your project has been developed, it will be difficult to make any changes to the basic design principles.
When you create the structure for the website, follow the recommended structure for CQ5 websites. Make sure you understand the following issues and/or principles:
How to structure website content.
How templates and components work.
How caching works.
The impacts of personalized content.
How the search function works.
How you can use CSS and related technologies to create compact, non-redundant HTML code.
If you feel that your design does not follow the guidelines, or if you are unsure about some of the implications, clarify these issues before you start either the programming phase or filling in the content.
To define or assess the infrastructure it will help to define target values such as:
visitors/day; both average and peak
hits/day; both average and peak
number of web-pages being made available
volume of web-content
Depending on your situation, and the strategic significance of the website this will help you to assess, or choose, your infrastructure:
number of servers
number of CQ5 instances (author and publish)
There are several performance factors which can be evaluated:
response times for individual pages, taking into account:
response times on an author environment
response times on the publish environment
response times for search requests
![[Note]](../resources/note.png) | Note |
|---|---|
This section can be read in conjunction with How to Monitor Performance, which expands the technical details of actually measuring the performance. |
A key issue is the time your website takes to respond to visitor requests.
Although this value will vary for each request, an average target value can be defined. Once this value is proven to be both achievable and maintainable, it can be used to monitor the performance of the website and indicate the development of potential problems
The response times you will be aiming for will be different on the author and publish environments, reflecting the target audience:
- Author Environment
This environment is used by authors entering, and updating content, so it must:
cater for a small number of users who generate a high number of requests when updating content pages and the individual elements on those pages
be as fast as possible to maximize their productivity for getting your content onto your website
- Publish Environment
This environment contains content which you make available to your users:
speed is still vital, but is often slower than an author environment
additional performance enhancing mechanisms are often applied:
the content is cached
load-balancing is applied
So how can you decide on achievable (average) response times?
This is often a matter of experience:
past experience on your website
experience with CQ5
recognizing complex pages which have above average response times (these should be individually optimized if possible)
However, (under controlled circumstances - see Note) the following guidelines can be applied:
70% of the requests for pages should respond in less than 100ms.
25% of the requests for pages should respond in less than 100ms-300ms.
4% of the requests for pages should respond in less than 300ms-500ms.
1% of the requests for pages should respond in less than 500ms-1000ms.
No pages should respond slower than 1 second.
A good starting point for performance analysis is the request log. Amongst other information, you can use this to see the response times of individual requests. See How to Monitor Performance for more details.
Search requests can have a significant impact on your website, in terms of both the:
- Response time of the actual search
A fast search function is a quality goal for your website
- Impact on general performance
As a search function must scan (potentially large) sections of the content, or a specially extracted index, this can impact the performance of the entire system if not optimized
Again it is a matter of experience depending on:
experience of CQ5
an assessment of how often search will be used in comparison to other goals
your persistence manager
your search index
the complexity of your search function; a basic search function which only allows 1 search term to be input will be quicker than an advanced search allowing the user to build up complex search statements using AND / OR / NOT.
Again the request.log can be used to monitor the response times for search requests; see How to Monitor Performance for more details.
To customize the information you collect about search requests, and their performance, it is recommended to include information collection in your project source code; see How To Monitor Performance for more details.
This should be planned and integrated from the very start of your project.
Your website will be made available to a number of users. Often more than you used when testing, but also fluctuating and difficult to predict. Your website will need to be designed for an average number of concurrent users who can work without noticing a negative performance impact.
Targets for the number of concurrent users, are dependent on the environment type:
- Author Environment
Usually the number of concurrent users can be accurately estimated. You will know how many authors you have in total, though (probably) not all will be active at the same time.
- Publish Environment
This is more difficult to predict, so you must select a target value. Again this should be based on experience of your current website together with realistic expectations of your new website.
Special events (e.g. when you publish new, very popular content) may exceed expectations - or even capabilities (as sometimes reported in the press when tickets for certain events are made available for sale).
Again the request.log can be used to make concurrency tests; see How To Monitor Performance for more details.
Before discussing the metrics, a quick definition of the 2 terms:
- Volume
the amount of output that is processed and delivered by the system.
- Capacity
the system’s ability to deliver the volume.
At each step, capacity and volume are measured differently, as shown in Table 1, “Capacity and Volume”. For best performance, make sure that the capacity matches the volume at each step, and that both capacity and volume are shared across all steps. For example, you may be able to compute the navigation on the client computer, or put it in the cache, instead of computing it on the server for every request.
Table 1. Capacity and Volume
| What / Where | Capacity | Volume |
|---|---|---|
| Client | Computational power of the user’s computer. | Complexity of the page layout. |
| Network | Network bandwidth. | Size of the page (code, images and so on). |
| Dispatcher cache | Server memory of the Web server (main memory and hard drive). | Web server (main memory and hard drive). Number and size of the cached pages. |
| Output cache | Server memory of the Communiqué server (main memory and hard drive). | Number and size of the pages in the output cache, the number of dependencies per page. The dispatcher cache lowers this volume. |
| Web Server | Computational power of the Web server. | Amount of requests. Caching lowers this volume. |
| Template | Computational power of the Web server. | Complexity of the templates. |
| Repository | Performance of the repository. | Number of pages loaded from the repository. |
The preceding sections detail the main metrics to be defined.
Depending on your specific requirements it might be useful for you to define additional metrics, either in isolation, or taking the above classifications into account.
However, it is preferable to have a small set of accurate, core metrics that function easily and reliably, rather than try to measure and define every aspect of your website. By its sheer nature, your website will start to change and evolve as soon as it is handed over to your users.