Make sure you do not only verify your page speed in a single user or small testing department. Make sure you run some load against your servers as this will show how well your application server code scales. The typical observation is that with growing load we see a shift in response time from Transfer Time to Server Time as being the main contributor.
It is typically easier to scale static content such as images, css or js as web servers and load-balancers are doing a good job with this. But requests to the application server that need to query information from the database or fetch data from other resources face new scalability and performance challenges under increasing load. That is why it is important to focus on server-side requests and analyze the response under certain load.
What are Server-Side Requests?
If you know the application I am sure you have a good understanding about which requests are served by the app server, your web server or your CDN (Content Delivery Network). You can also check the HTTP Response Headers to see whether the application adds some appserver-specific headers.
The dynaTrace AJAX Edition provides a table on the Server-Side tab on the Performance Report that lists all requests that match the following criteria which are very likely to be handled by the application server
- First request on the page -> usually returns the initial HTML
- Requests that return HTML -> generated content (this also may include static HTML pages)
- Requests on URL's ending with aspx, jsp, php
- Requests that send GET or POST parameters data to the server
- All XHR/AJAX Requests
Server Side Time
The Server-Column shows the Time to First Byte. This is as close to server-side processing time as we can get by analyzing the network requests that are sent by the browser. So - this is the time from the last byte sent from the HTTP Request until the first byte received. This also includes some network latency - but as I said, this is very close to the actual server-side processing time. When we want to get more accurate numbers we have to analyze the actual processing time on the application server itself. Either analyze server log files or use an APM Solution such as dynaTrace that allows us to get a full end-to-end view of each individual request.
Server-Side Problem Patterns
We recently published a blog about the Top Server-Side Performance Problems and Patterns which includes detailed best practices on identifying problems such as Too Many Database Calls, Synchronized to Death, Too chatty on the remoting channel or Wrong usage of O/R-Mappers
With it’s PurePath Technology, dynaTrace provides an Application Performance Management Solution that enables you to proactively prevent these problem patterns as well as solve these problems faster when identified in testing or production:
Besides the technical patterns there are business and process impacts of Performance Problems. Alois Reitbauer writes a great 2010 Performance Almanac that gives a technical overview of common problems but also ties in the business aspect of slow performance and how to manage it throughout the IT Organization.
Performance Savings, Recommendations and Rank Calculation
Recommendations and Savings
Follow the Best Practices, make yourself familiar with common problem patterns and use performance management solutions on your servers to identify performance problems early on.
Based on our experience with our clients performance can be increased 3-fold by following the server-side performance best practices. You have to have the appropriate tools for a detailed analysis and you should start with your performance optimization efforts early on in the project - don't start in production :-) - Listen in to some Best Practices of our clients such as Zappos, Insight, Monster or SmithMicro
dynaTrace AJAX Edition calculates a rank based on the number of requests to the application server as well as the Server Time. The more requests the lower the ranking as we assume that requests can be merged into fewer. Up to 6 Server-Side requests are fine. Every additional request gets penalized by 1 Rank.
The slower the Server Time the more performance improvements are possible. Every request that takes more than 200ms Server time has potential of being improved. We reduce the Rank by 1 having a Server Time from 200ms to 400ms. We reduce it by 2 between 400ms and 1000s and reduce it by 4 when having times longer than 1s.
Note: 6 requests on the server-side is a good average value of web sites we have analyzed. If you work on a highly interactive single URL page you end up adding more server-side requests as you interact with the page impacting your rank. Therefore handle this rank with caution depending on the type of website you are testing.
Take a page that has a total of 10 requests that match the criteria described above. This reduces the Rank by 4. 2 Requests take between 400ms and 1000ms which reduces the rank by 4 and we have one request that takes more than 1s which reduces the Rank by additional 4.
The total Rank of this page is therefore is 88 which correspond to a Grade B.
Here are further reads and detailed explanation on Cache Settings