<body><p> </p><p>Reminder - If you are reading this post before reading my previous ones I kindly ask you to go back and read the first ones first... I'm trying to lead you through a process. Thanks :)) </p><p>So by now everything looks a little brighter - the browser is set, you have a browser tracing tool and you have seen how things looks like from your end. Hopefully (or not...) you spotted some problems and fixed them already. Never thought there is so much action behind the scenes? We are just getting started. </p><p>Today we will dive deeper into the http traces and learn some more about the client-server dialog, as well as some tuning tips on the server side that might save you some time.</p>h3. Into the deep water
<p>The http spec defines many different header names that can be used, most of them were defined in http spec version 1.0 but some are only introduced in http 1.1 spec. To add to the confusion, some of the headers are explicit (meaning you specifically define what behavior you want) and some of them have implicit meaning (you get some behavior as result of other header you defined). Add to the equation the browser version factor and you get a nice cocktail that will certainly give you a headache. You think you are bigger than that? You will be knocked down when proxy servers joins the party. Don't tempt me. </p><p>Unfortunately (and luckily for you) I won't be able to cover all headers or different combinations, the spec is unbelievably long and far from being easy to read or understand. I will refer to the common scenarios and naïve interpretation of the spec, I know there are always exceptions and special cases - want to share one? this is why we have the "comments" section at the bottom. <br />Let's take an example and analyze it.</p><p>You know by now how to take HTTP traces, I will continue to use HTTPWatch for the demonstration - to see the headers of the request and response you should click the URL and navigate to the "Headers" tab. See image below.</p><p> </p><p><img />//weblogs.sdn.sap.com/weblogs/images/59389/httpwatch_headers_tab.JPG|height=384|alt=httpwatch headers tab|width=598|src=https://weblogs.sdn.sap.com/weblogs/images/59389/httpwatch_headers_tab.JPG|border=1!</p><p> </p><p>Usually the headers are separated by line breaks and looks like <header name>: <header value> but in this tab they are displayed more conveniently (for raw data go to "Stream" tab).<br />The spec defines which values are possible for every header name.</p><p> So let's review the more important headers.</p><p>Consider the below headers, this is the Login post:
POST /irj/servlet/prt/portal/prteventname/Navigate/../.. HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, /
Referer: http://localhost:53000/irj/portal?...
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Host: localhost:53000
Content-Length: 298
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: PortalAlias=portal; saplb_*=(ilperf125_F37_30)303540750; ...
POST /irj/servlet/prt/portal/prteventname/Navigate/../.. HTTP/1.1<br />First line says POST or GET, which is the http method we use, following by the requested URL and then HTTP/Referer: http://localhost:53000/irj/portal (http://localhost:53000/irj/portal)?...<br />Who triggered this request; this is useful in case you want to trace which file caused this request to be sent.
Accept-Encoding: gzip, deflate<br />the browser explicitly specifies that it support gzip data compression, so the server can compress the response body. Just to clear things out - a) it is up to the server to decide if it wants to compress or not, b) the http headers themselves can't be compressed; you need the headers to tell the browser that the body is actually compressed.
Cache-Control: no-cache<br />in this case the browser requests that the request-response will not be cached. This is normal for POST since it involves with submitting parameters that needs to be processed on the server.
Connection: Keep-Alive<br />this means that the browser will reuse the connection after it receives the response, unless the response specifies otherwise (like Connection: close).
+Cookie: PortalAlias=portal; saplb_=(ilperf125_F37_30)303540750; ...
+On every request the browser sends the complete list of cookies that are relevant to that domain. Remember I said that the headers can't be compressed? This is a major downside for cookies since they can be very long (and could have been easily compressed since they are textual).</p><p>And now let's go the server response (headers received by the browser):*
HTTP/1.1 200 OK
Server: SAP J2EE Engine/7.00
Content-Type: text/html; charset=UTF-8
Content-Language: en-US
Content-Encoding: gzip
Date: Mon, 21 Jan 2008 15:29:24 GMT
Transfer-Encoding: chunked
HTTP/1.1 200 OK<br />The server responds* with the response code (talked about it last time) and the http version it supports.</p><p>Content-Type: text/html; charset=UTF-8<br />the content type of the returned body, In our case this is html file. </p><p>Content-Encoding: gzip<br />the content is compressed. In httpwatch under the "stream" tab you can see the raw request and response. If you look below the headers you will see gibberish - this is the actual compressed content (binary data). Go to the "content" tab and you will see the body after it was decompressed.</p><p>Date: Mon, 21 Jan 2008 15:29:24 GMT
The date and time this message was originated.</p><p>Transfer-Encoding: chunked<br />the server does not provide total response length.
</p><p>Let's see another example - this is a response of resources that should be cached:*
HTTP/1.1 200 OK
Server: SAP J2EE Engine/7.00
Content-Type: application/x-javascript
Last-Modified: Tue, 01 Jan 2008 09:40:19 GMT
Cache-Control: max-age=86400
Content-Length: 69729
Date: Wed, 23 Jan 2008 15:44:59 GMT
What is the difference here?<br />You can see the content type header that indicates this is a javascript file, and the cache control returns with a "max-age=86400" value. This means that the server tells the browser it should cache it for 86,400 seconds, which are 24 hours. From now on, for the next 24 hours the browser can load this file from cache whenever it is requested with no need to request it from the server again.
What happens when the 24 hours are over?
The server sent an additional header "Last-Modified", this is the date when the requested resource was last modified on the server. The browser saves this date together with the cache definitions of the file and when the cache period times-out it sends a conditional request to the server asking if the resource was modified or not. If the resource was modified the server will send the updated resource file and replace the cached version, if not - the browser will send a short response that indicates the browser to continue using the cached file (and continue to cache it for the next 24 hours).
What can you do to improve performance?
The http server allows you to configure many parameters, you should check what is configured and make sure to have the best matching configuration for your needs.
How?
Use the VisualAdmin tool. Go to Server_abc -> services -> HTTP Provider service
On the Runtime tab you see the following 4 options, make sure they are properly configured.
*
2 Comments
