Guy kolbis

There are several ways to cache HTTP responses and ETag is one of them. ETag is a nice feature that can sometimes help boosting the performance for a web application. Basically the idea behind ETag is to prevent redownloading and processing a page that has not been modified.

The origin server specifies the ETag using the response header:

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195

 The browser will check for the expiration:

GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
HTTP/1.1 304 Not Modified

Wikipedia, describes it very well:

"An ETag (entity tag) is an HTTP response header returned by an HTTP/1.1 compliant web server used to determine change in content at a given URL. When a new HTTP response contains the same ETag as an older HTTP response, the contents are determined to be the same without further downloading. The header is useful for intermediary devices that perform caching, as well as client web browsers that cache results. One method of generating the ETag is based on the last modified time of the file and the size of the file."

However, one thing to note is that when using a load balancer or a web farm, the ETag does not really works! The reason for this is the fact that the ETag generates a "key" to identify the expiration for the response that is unique to a specific machine! Thus when given a "key" from one machine is will be invalid in the second machine and the response will not be supplied from the cache...

Here is a question I here often:

"We want to load test our application, what do we need?"

My answer is "very simple":

"What are the goals for our load test?"

That is when I usually here the sentence:

"I want to see how my application operates under load..."

Well, this is not a very good answer, or at least not satisfying one.

"Why?"

When we load test the application we can check several aspects that require deferent preparations. Usually we would like to validate our application in terms of:

1. Concurrency.
2. Critical Resources Utilizations.
3. Latency & Response Times.
4. Throughput.
5. Application related errors.

But really, the place to start is to understand the goals for you performance load testing.

Ask yourself: "What do I want to answer on?". For example, Can I support 100 concurrent users? Will one 1.6GHz CPU be sufficient for my application?

By asking yourself these QAs you will understand the goals for your load testing.

One more quick note:

Performance should be addressed at the requirements process and should be part of the SLA, that means that the QAs above should be asked before the actual need to load test.

If you require more info on how to start this process, check out this article from Microsoft:

Performance Modeling.

Microsoft had released an Alpha 0.2 for supporting LINQ To XSD.

The LINQ to XSD technology provides .NET developers with support for typed XML programming.

LINQ to XSD contributes to the LINQ project (.NET Language Integrated Query).

What does it look like?

To get an idea, consider the following C#3.0 fragment for a LINQ to XML query that computes the total over the items in a XML tree for a purchase order:

(
    from   item in purchaseOrder.Elements("Item")
    select (double)item.Element("Price")
    *      (int)item.Element("Quantity")
).Sum();

Using LINQ to XSD, .NET developers may instead write `typed’ code as follows:

(
    from item in purchaseOrder.Item
    select item.Price * item.Quantity
 ).Sum();

Hit me with more info please...

LINQ to XSD is the code name of an incubation project that aims to provide .NET developers with support for typed XML programming on top of LINQ to XML. While the LINQ to XML programmer operates on generic XML trees, the LINQ to XSD programmer operates on typed XML trees -- instances of .NET types that model the XML types of a specific XML schema (XSD).

LINQ to XSD can be used whenever you have an XML schema available, or you are willing to infer a schema from the XML data at hand.

LINQ to XSD is integrated into Visual Studio; so you just tag an XML schema as an ‘LINQ to XSD schema’, build your project, and the automatically derived object model is then part of your solution -- just as if XML schemas were .NET types. The derived object model enforces various validation constraints imposed by the underlying XML schema.

Let me try it...

You can download the Alpha 0.2 here.