Application Performance Series- Part 6- Find ways to avoid redirects
This is part 6 of a multiple part series on web performance improvements. The first Introductory blog can be found here. In previous part we discussed benefits of cookie-free domains. In this part we will discuss the negative impact of redirects in web application performance.
Redirect is a phenomenon where user as routed from one URL to another. There can be various reasons for URL redirect, including web site redesign, tracking traffic flow, counting ad impressions, and creating URLs that are easier for users to remember.
There are different kinds of redirects.
- 300: Multiple Choices (based on Content-Type)
- 301: Moved Permanently
- 302: Moved Temporarily (a.k.a. Found)
- 303: See Other (clarification of 302)
- 304: Not Modified- It is not really a redirect—it’s used in response to conditional GET requests to avoid downloading data that is already cached by the browser
- 305: Use Proxy
- 306: No longer used
- 307: Temporary Redirect (clarification of 302)
Out of these 301 and 302 are the most popular. Redirects are usually done for HTML documents, but they may also be used when requesting components in the page (images, scripts, etc). Beside considering, the need to of redirect and their uses, biggest disadvantage of redirects is it makes your pages slower. Sometimes this can be total performance killer.
For example, suppose user request for a URL and receives following response from server then there will be a page redirect.
HTTP/1.1 301 Moved Permanently
Location: http://abc2xyz.com/newuri
Content-Type: text/html
In case of redirects the browser automatically takes the user to the URL specified in the Location field. All the information necessary for a redirect is present in the headers, as shown in above example. The body of the response is typically empty. Despite their names, neither a 301 nor a 302 response is cached in practice unless additional headers, such as Expires or Cache-Control, indicate that it should be.
If the head of the HTML document includes meta refresh tag a page redirect will happen after the number of seconds specified in the content attribute:
- meta http-equiv=”refresh” content=”0; url=http://abc2xyz.com/newuri”
Another way to perform redirects is by setting the document.location to the desired URL using JavaScript. If there is no other option then to perform a redirect, the preferred technique is to use the standard 3xx HTTP status codes. This makes sure that the Back button works correctly.
How Redirects Hurt Performance
Below is an image is a snapshot of a browser request response, using Yslow. It shows how redirects slow down the user experience.
The first HTTP request is the redirect. Redirects delay the delivery of entire HTML document. Nothing is presented to the user until redirect and HTML document requests are completed. Nothing in the page can be rendered and no components can be downloaded until the HTML document has arrived. Inserting a redirect between the user and the HTML document delays everything in the page. The style-sheets are very much important for the page rendering. But due to redirect they are further delayed. In case of no redirect this html request could have been served to user much early.
Redirects are typically used with requests for the HTML document, but sometimes they are used for components in the page. Such redirects further delay the page output. Below figure shows the HTTP requests for Google Toolbar. It contains four redirects.
Avoiding Redirects
There can be various reasons (good ones) for URL redirect like
- Web site redesign
- Tracking traffic flow
- Counting ad impressions
- Creating URLs that are easier for users to remember
Though redirect can fix a number of issues as given above for business it may introduce a lot of issues for the end user. If business demands we cannot avoid many of the above mention situations too. So we need to find some alternative solutions which achieve our intended goal at the same time do not cost us on performance front.
So what options we have…
The following sections discuss some of the typical situations in which redirects are used, and alternatives that we can implement to make the user experience better.
Missing Trailing Slash
This kind of redirect happens when a trailing slash (/) is missing from a URL that should otherwise have one. For example,
when we type http://shine.yahoo.com/horoscope in browser it results in a 301 response containing a redirect to http://shine.yahoo.com/horoscope/. The only difference is the addition of a trailing slash (/).
- GET / HTTP/1.1
Sending a redirect when a trailing slash is missing is the default behaviour for many web servers, including Apache. The Alias directive is an easy workaround. Another alternative is to use the mod_rewrite module, but Alias is simpler. The problem with the Horoscope site could be resolved by adding the following to the Apache configuration:
- Alias /horoscope /usr/local/apache/htdocs/horoscope/index.html
Handler in Apache 2.0 provides cleaner solution in the form of DirectorySlash directive. Assuming there is a handler named horoscopehandler, the use of DirectorySlash would look as follows:
Moving between Web Sites/ pages
Consider a situation where
- The website is under re-engineering process. This may happen due changes in technology or any other reason. The URL’s in new system may be different than the existing system. An easy way to transition users from the old URLs to the new ones is to use redirects.
- Due to certain condition redirect is happening within parts of a web site (type of browser, type of user account, etc.).
Using a redirect to connect two web sites is simple and requires little additional coding. Although redirects reduce the complexity for developers, it degrades the user experience. There are alternatives for integrating two websites without degrading user experience:
- If the two websites reside on the same server, it’s possible the code itself could be linked. For example, the older handler code could call the new handler code programmatically.
- If the domain name changes, a DNS record that creates an alias pointing from one domain name to another (a CNAME) can be used to make both hostnames point to the same server.
- Alias, mod_rewrite, and DirectorySlash are simple solutions to fix this issue.
User Friendly URLs
Redirects are used to make URLs prettier and easier to remember for end users. Suppose the actual URL of the page earlier was:
- http://abc.com/xyz1234hjgjdh12333344
It is not easy for a user to type or remember this URL. But if the URL is converted to:
- http://abc.com/MyPage
then this is a easy to remember for any user. But internally this URL is linked to the previous URL, which this causes a redirect.
The key is to find a way to have these simpler URLs without the redirects. Rather than forcing users to undergo an additional HTTP request, it would be better to avoid the redirect using Alias, mod_rewrite, DirectorySlash, and directly linking code.
Application Performance Series- Part 5- Use Cookie free Domains for Components
This is part 5 of a multiple part series on web performance improvements. The first Introductory blog can be found here. In previous part we discussed about CDN and how they improve the performance of the web application. In this part we will discuss the benefits of cookie-free domains.
When the browser makes a request for a static image it also sends cookies together with the request. The server doesn’t have any use for those cookies. So they only create network traffic for no good reason. We should make sure static components are requested with cookie-free requests.
To achieve this we should create a sub-domain and host all static components there. If the domain is www.example.org, we can host static components on static.example.org. However, if we have already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, we can buy a whole new domain, host static components there, and keep this domain cookie-free.
Application Performance Series- Part 4- Use Content Delivery Network (CDN)
This is part 4 of a multiple part series on web performance improvements. The first Introductory blog can be found here. In previous part we discussed the pro and cons of DSN. In this part we will analyse how CDN’s can help us improve performance.
Whenever user types any URL in the browser, it sends the request to the server. The request travels all the way from client browser to the server. The server prepares the response and sends it back to the user browser.
The response time of request from browser-server and response back depends upon many factors such as:
- Bandwidth
- Network traffic
- No of hubs in network path
- Server load
- Request/response data size
So what is CDN
How CDN Works
CDN Pros
CDN Cons
Where can be used?
Application Performance Series- Part 3- Reduce DNS Lookups
This is part 3 of a multiple part series on web performance improvements. The first Introductory blog can be found here. In previous part we discussed about the performance measurement tools/plugins for a web application. In this part we will study what is DNS lookup and how it affects web application performance.
What is DNS?
DNS Caching
What affects DNS caching
How to reduce DNS Lookups
Application Performance Series- Part 1- Where to start
This is part 1 of a multiple part series on web performance improvements. The Introductory blog can be found here. In introductory post we discussed importance of software development keeping performance performance at center. In this part we will discuss which part affect web application performance the most? Where we can start the performance improvement activity to get maximum output?
Any web application performance improvement activity is a series of calculated tasks. We need to first identify where we can achieve the greatest improvements. There are three main places to consider:
- Frontend
- Backend
- Databases
Though we can group the backend and databases in same group but just for simplicity I have grouped them separately. In case of web applications the performance is always measured with respect to user response time. Whatever performance improvement tasks we do should result in improved user response time. If not then we should re-visit our performance improvement strategy again. Due to many reasons, some of them given below, it is clear that first place to focus is frontend to drastically improve the performance of the web application.
- First and foremost, generally, the time and resources required to implement the frontend changes is less as compared to others. Improving the backend performance may require change in architecture, code, data retrieval logic etc. These tasks may take longer time than expected.
- If we could cut the backend response time by 40-60%, this will reduce the overall end user response time by 10-20%. But if we could improve the frontend performance by 40-60% this could result in reduced end user response time upto 40-50%. Many sites likes Google, MSN, Yahoo, Ask etc has proved this point.
Following figure is a snap-shot of Y-slow recordings for a page in a website.
In coming blogs we will go through a series of steps that will help us understanding the performance pitfalls and how to improve them.
Application Performance Series- Introduction
Developing software applications is not just writing code, but it is much than that. It’s both science and Art when combined together can produce great quality applications. It is an art of writing efficiently working, fast and secure code. This is especially true when we are working on web applications. Developing a fast, scalable and secure application looks very simple at top. Writing an application which is works as per user expectations with speed and security is complex (but not impossible) to design. Many a time we need to find a middle path between security and performance based on a number of factors.
The design and construction of an application involve many-many decisions, each representing a trade-off. Many a time each alternative has significant positive and negative consequences. In such trading off, we hope to obtain a near-optimal good while minimizing the bad. It’s like “I want to go to heaven and meet god, but I don’t want to die”. Any application development there are three major factors that a project triangle.
I will divide this article into following sections:
- Front end or UI Performance
- Code behind
- Database
- Hardware
The “Front end or UI Performance” part will be generic and mostly not based on any technology (.NET, Java, PHP etc). But The “Code behind” part will specifically be related to .NET stake (ASP.NET, C# etc), because this is my core specialization. I am less familiar with Java or PHP, so sorry guys. In the “Database” part we can relate them to any SQL language but all the examples and code here will be based on SQL-Server.
HTTP Overview keeping performance in mind
Introduction
A browser sends an HTTP request for a specific URL, and a server hosting that URL sends back an HTTP response. Like many Internet services, the protocol uses a simple, plain-text format. The types of requests are GET, POST, HEAD, PUT, DELETE, OPTIONS, and TRACE. For this discussion we will focus on GET request, which is the most common.A GET request includes a URL followed by headers. The HTTP response contains a status code, headers, and a body. The following example shows the possible HTTP headers when requesting the script myScript.js.
Compression
How Compression Works
Starting with HTTP/1.1, web clients indicate support for compression with the Accept-Encoding header in the HTTP request.
Accept-Encoding: gzip, deflate
If the web server sees this header in the request, it may compress the response using one of the methods listed by the client. The web server notifies the web client of this via the Content-Encoding header in the response.
Content-Encoding: gzip
Gzip is currently the most popular, effective and free format compression method. The other compression format is deflate, but it’s slightly less effective and less popular. Browsers that support deflate also support gzip, but several browsers that support gzip do not support deflate, so gzip is the preferred method of compression.
What to Compress
Servers choose what to gzip based on file type. For example gzip can compress follwoing types by default.
Cost of compression
Gzipping takes additional CPU cycles on the server to carry out the compression and on the client to decompress the gzipped file. To determine whether the benefits outweigh the costs you would have to consider the size of the response, the connection bandwidth, and the Internet distance between the client and the server. Generally, it’s worth gzipping any file greater than 1 or 2K. The mod_gzip_minimum_file_size directive, which has a default value of 500 bytes, controls the minimum file size that we would like to compress.
Conditional GET Requests
If the component has not been modified since the specified date, the server returns a “304 Not Modified” status code and the body of the response is not sent. This results a smaller and faster response. In HTTP/1.1 the ETag and If-None-Match headers are another way to make conditional GET requests.
ETags (Entity Tags)
When the browser sees an Expires header in the response, it saves the expiration date with the component in its cache. As long as the component hasn’t expired, the browser uses the cached version and avoids making any HTTP requests.
Keep-Alive
Persistent Connections, also known as Keep-Alive in HTTP/1.0, was introduced to solve the inefficiency of opening and closing multiple socket connections to the same server. It lets browsers make multiple requests over a single connection. Browsers and servers use the Connection header to indicate Keep-Alive support. The Connection header looks the same in the server’s response.
Pipelining
SQL Server Functions
Introduction
Some highlights of Functions
- Function must return a value.
- Functions can have only input parameters for it.
- Function allows only SELECT statement in it.
- Function can be embedded in a SELECT statement.
- Functions can be used in the SQL statements anywhere in the WHERE/ HAVING/ SELECT section.
- Functions that return tables can be treated as another row-set. This can be used in JOINs with other tables.
- Inline Function can be thought of as views that take parameters and can be used in JOINs and other Rowset operations.
- Try-catch block cannot be used in a Function.
- Transactions are not allowed in Functions.
- Function should have at least one input parameter.
- Functions can be called from Procedure.
- User Defined Function can call only Extended Stored Procedure.
- Like Stored Procedure, Function can be nested up to 32 levels.
- User Defined Function can have upto 1023 input parameters while a Stored Procedure can have upto 21000 input parameters.
- User Defined Function can’t returns XML Data Type.
- User Defined Function doesn’t support set options like set ROWCOUNT etc.
Where we can use a Function?
Functions can be Deterministic or Nondeterministic
Keeping things safe: functions can be schema-bound
Behavior if case of NULL
Types of Function
System Defined Function
SQL Server has many built in Functions which can be used for carrying out variety of operations and calculations. We have two types of system defined function in Sql Server.
-
Scalar Function
|
Scalar Function
|
Description
|
|
abs(-10.67)
|
This returns absolute number of the given number means 10.67.
|
|
rand(10)
|
This will generate random number of 10 characters.
|
|
round(17.56719,3)
|
This will round off the given number to 3 places of decimal means 17.567
|
|
upper(‘dotnet’)
|
This will returns upper case of given string means ‘DOTNET’
|
|
lower(‘DOTNET’)
|
This will returns lower case of given string means ‘dotnet’
|
|
ltrim(‘ dotnet’)
|
This will remove the spaces from left hand side of ‘dotnet’ string.
|
|
convert(int, 15.56)
|
This will convert the given float value to integer means 15.
|
-
Aggregate Function
|
Aggregate Function
|
Description
|
|
max()
|
This returns maximum value from a collection of values.
|
|
min()
|
This returns minimum value from a collection of values.
|
|
avg()
|
This returns average of all values in a collection.
|
|
count()
|
This returns no of counts from a collection of values.
|
User Defined Functions
-
Scalar Function
-
Table Valued Functions (TVFs)
-
Inline Table-Valued Function
Inline table-valued function returns a table variable as a result of actions performed by the function. The value of table variable should be derived from a single SELECT statement.
— now call the above created function
Select * fromfnGetEmployee()
-
Multi-Statement Table-Valued Function
Within the create function command you must define the table structure that is being returned. After creating this type of user-defined function, I can use it in the FROM clause of a T-SQL command unlike the behaviour found when using a stored procedure which can also return record sets.
What are the benefits of User-Defined Functions?
Drawbacks of Functions
Difference between SQL Server Functions and Stored Procedures
|
Functions
|
Stored Procedures
|
|
Function must return a value.
|
Procedure can return zero or n values.
|
|
Functions can have only input parameters for it.
|
Procedures can have both input and output parameters in it.
|
|
Function allows only SELECT statement in it.
|
Procedure allows SELECT as well as DML(INSERT/UPDATE/DELETE) statement in it.
|
|
Function can be embedded in a SELECT statement.
|
Procedures cannot be utilized in a SELECT statement.
|
|
Functions can be used in the SQL statements anywhere in the WHERE/ HAVING/ SELECT section.
|
Stored Procedures cannot be used in the SQL statements anywhere in the WHERE/ HAVING/ SELECT section.
|
|
Functions that return tables can be treated as another row-set. This can be used in JOINs with other tables.
|
Procedures cannot be used in a JOINs statement.
|
|
Inline Function can be thought of as views that take parameters and can be used in JOINs and other Rowset operations.
|
Procedures cannot be used in a JOINs statement.
|
|
Try-catch block cannot be used in a Function.
|
Exception can be handled by try-catch block in a Procedure.
|
|
Transactions are not allowed in Functions.
|
We can handle Transactions in Procedure.
|
|
Function should have at least one input parameter.
|
Stored Procedure may take 0 to n input parameters.
|
|
Functions can be called from Procedure.
|
Procedures cannot be called from Function.
|