These are the questions that I usually ask during an interview process with an applicant that is in for a technical assessment interview. These questions assumes that you are well rounded and full blown .NET Web Developer. A .NET web developer should at least know ASP.NET, C#/VB.NET and TSQL.

1. What are HttpModules and HttpHandlers, and what is the difference between the two?
   
2. What is the difference between CREATE PROC and CREATE PROCEDURE?
   
3. What is ViewState and what are its advantages and disadvantages?
   
4. What is the name of the method of the DataAdapter that should be invoked to load a DataSet with data.
   
5. What are the validation controls? Name and explain some.
   
6. What are themes?
   
7. What is the difference between Web.Config and Global.asax?
   
8. What is the transport protocol that is used to call a webservice?
   
9. What is WSDL?
   
10. How can you customize the tag prefix of a custom user control globally? So instead of  <uc1:... I want to see <dnc:....
    
11. What happens when you set the "AutoPostBack" property of a dropdownlist control to True?
    
12. Explain the terms boxing and unboxing.
    
13. How do you disable ViewState on a specific page?
    
14. What is the difference between an abstract class and an interface?
    
15. What is the difference between Server.Transfer and Response.Redirect?
    
16. How is a SQL Server trigger similar to a C# event?
    
17. What is IL?
    
18. What is the most recent version of the .Net Framework?
    
19. How is CLI and CLR related?
    
20. What is the meaning of the class "Internal"
    
21. What is stack trace?
    
22. Explain in your own words what you understand of the term "Generics"?
    
23. Explain Garbage Collection.
    
24. What is the difference between using a Destructor and implementing the IDisposable interface?
    
25. What is an Application Domain?
    
26. What does the following statement do - GC.SuppressFinalize();?
    
27. What is serialization?
    
28. What is the relationship between a HashTable and IDictionary?
    
29. What is a Thread?
    
30. Can you pass a parameter to a thread?
    
31. How does the term "Lock" relates to threading?
    
32. Explain the term Inheritance.
    
33. Explain the term singleton.
    
34. What is DLLImport?
    
35. Explain the AppSettings of the web.config file?
    
36. What is a console application and how is it different from a web application?
    
37. What is normalization?
    
38. In SQL Server what do you know about indexing?
    
39. What are the different types of indexes and explain?
    
40. What is the difference from DELETE and TRUNCATE on a table?
    
41. What is a deadlock?
    
42. In TSQL how do you add/remove a column to an existing table?
    
43. Explain the term "Naming convention" and your preference.
    
44. Can SQL Triggers be invoked on demand?
    
45. What is the difference between Int and Int32?
    
46. Explain the SQL Server XML data type.
    
47. What is XQuery?
    
48. How do you specify a global page theme instead of page by page basis?
    
49. What is the difference between the App_Data and App_Code folders.
    
50. Do you love coding? Talk about your passion for development!

We just completed the .NET Framework 3.5 update to the Commonly Used Types and Namespaces poster.

Here's a link to the PDF if you want to grab it now and be the first on your block to get it on your wall. We'll be using it at a variety of places, if you think it would be a cool thing to have at a Microsoft event then please go suggest it to some Microsoft employee that you know.

Let me point out the little additive circles diagram at the bottom right. We've found that this is a great way to explain the additive version releases of the .NET Framework 2.0 – 3.0 – 3.5. The primary reason for updating the .NET Framework this additive way instead of the side-by-side nature of .NET Framework 1.1 – 2.0 is to make it easier for customers to upgrade their apps. Here's that diagram again.

背景讨论

作为一个很典型的设计模式，Singleton模式常常被用来展示设计模式的技巧，并且随着技术的演进，.NET语言和Java都已经把经典《Design Patterns : Elements of Reusable Object-Oriented Software》中所定义的Singleton模式作了完善，例如C#可以通过这样一个非常精简但又很完美的方式实现了一个进程内部线程安全的Singleton模式。

C# 最经典Singleton模式的实现（Lazy构造方式）

---

public class Singleton
{
    private static Singleton instance;   // 唯一实例
    protected Singleton() { }   // 封闭客户程序的直接实例化
    public static Singleton Instance    
    {
        get
        {
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

C# 通过Double Check实现的相对线程安全的Singleton模式

---

public class Singleton
{
    protected Singleton() { }
    private static volatile Singleton instance = null;
    /// Lazy方式创建唯一实例的过程
    public static Singleton Instance()
    {
        if (instance == null)           // 外层if
            lock (typeof(Singleton))    // 多线程中共享资源同步
                if (instance == null)   // 内层if
                    instance = new Singleton();
        return instance;
    }
}

C#充分依靠语言特性实现的间接版Singleton模式

---

class Singleton
{
    private Singleton() { }
    public static readonly Singleton Instance = new Singleton();
}

但项目中我们往往需要更粗或者更细颗粒度的Singleton，比如某个线程是长时间运行的后台任务，它本身存在很多模块和中间处理，但每个线程都希望有自己的线程内单独Singleton对象，其他线程也独立操作自己的线程内Singleton，所谓的线程级Singleton其实他的实例总数 = 1（每个线程内部唯一的一个） * N （线程数）= N。

.NET程序可以通过把静态成员标示为System. ThreadStaticAttribute就可以确保它指示静态字段的值对于每个线程都是唯一的。但这对于Windows Form程序很有效，对于Web Form、ASP.NET Web Service等Web类应用不适用，因为他们是在同一个IIS线程下分割的执行区域，客户端调用时传递的对象是在HttpContext中共享的，也就是说它本身不可以简单地通过System. ThreadStaticAttribute实现。不仅如此，使用System. ThreadStaticAttribute也不能很潇洒的套用前面的内容写成：

C#

---

[ThreadStatic]
public static readonly Singleton Instance = new Singleton();

因为按照.NET的设计要求不要为标记为它的字段指定初始值，因为这样的初始化只会发生一次，因此在类构造函数执行时只会影响一个线程。在不指定初始值的情况下，如果它是值类型，可依赖初始化为其默认值的字段，如果它是引用类型，则可依赖初始化为null。也就是说多线程情况下，除了第一个实例外，其他线程虽然也期望通过这个方式获得唯一实例，但其实获得就是一个null，不能用。

解决Windows Form下的细颗粒度Singleton问题

对于Windows Forms下的情况，可以通过System. ThreadStaticAttribute比较容易的高速CLR其中的静态唯一属性Instance仅在本线程内部静态，但麻烦的是怎么构造它，正如上面背景介绍部分所说，不能把它放到整个类的静态构造函数里，也不能直接初始化，那么怎么办？还好，那个很cool的实现这里不适用的话，我们就退回到最经典的那个lazy方式加载Singleton实例的方法。你可能觉得，这线程不安全了吧？那种实现方式确实不是线程安全，但我们这里的Singleton构造本身就已经运行在一个线程里面了，用那种不安全的方式在线程内部实现只有自己“一亩三分地”范围内Singleton的对象反而安全了。新的实现如下：

C#

---

public class Singleton
{
    private Singleton() { }

    [ThreadStatic]  // 说明每个Instance仅在当前线程内静态
    private static Singleton instance;

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
                instance = new Singleton();
            return instance;
        }
    }
}

Unit Test

---

/// 每个线程需要执行的目标对象定义
/// 同时在它内部完成线程内部是否Singleton的情况
class Work
{
    public static IList Log = new List();
    /// 每个线程的执行部分定义
    public void Procedure()
    {
        Singleton s1 = Singleton.Instance;
        Singleton s2 = Singleton.Instance;
        // 证明可以正常构造实例
        Assert.IsNotNull(s1);
        Assert.IsNotNull(s2);
        // 验证当前线程执行体内部两次引用的是否为同一个实例
        Assert.AreEqual(s1.GetHashCode(), s2.GetHashCode());
        //登记当前线程所使用的Singleton对象标识
        Log.Add(s1.GetHashCode());
    }
}

[TestClass]
public class TestSingleton
{
    private const int ThreadCount = 3;
    [TestMethod]
    public void Test()
    {
        // 创建一定数量的线程执行体
        Thread[] threads = new Thread[ThreadCount];
        for (int i = 0; i < ThreadCount; i++)
        {
            ThreadStart work = new ThreadStart((new Work()).Procedure);
            threads[i] = new Thread(work);
        }
        // 执行线程
        foreach (Thread thread in threads) thread.Start();

        // 终止线程并作其他清理工作
        // ... ...

        // 判断是否不同线程内部的Singleton实例是不同的
        for (int i = 0; i < ThreadCount - 1; i++)
            for (int j = i + 1; j < ThreadCount; j++)
                Assert.AreNotEqual(Work.Log[i], Work.Log[j]);
    }
}

下面我们分析一下单元测试代码说明的问题：

• 在Work.Procedure()方法中，两次调用到了Singleton类的Instance静态属性，经过验证是同一个Singleton类实例。同时由于Singleton类的构造函数定义为私有，所以线程（客户程序）无法自己实例化Singleton类，因此同时满足该模式的设计意图；
• 通过对每个线程内部使用的Singleton实例登记并检查，确认不同线程内部其实掌握的是不同实例的引用，因此满足我们需要实现的细颗粒度（线程级）的意图；
• 解决Web Form下细颗粒度Singleton问题。

上面用ThreadStatic虽然解决了Windows Form的问题，但对于Web Form应用而言并不适用，原因是Web Form应用中每个会话的本地全局区域不是线程，而是自己的HttpContext，因此相应的Singleton实例也应该保存在这个位置。实现上我们只需要做少许的修改，就可以完成一个Web Form下的细颗粒度Singleton设计：

C#

---

public class Singleton
{
    /// 足够复杂的一个key值，用于和HttpContext中的其他内容相区别
    private const string Key = "just.complicated..singleton";
    private Singleton() { }

    public static Singleton Instance
    {
        get
        {
            // 基于HttpContext的Lazy实例化过程
            Singleton instance = (Singleton)HttpContext.Current.Items[Key];
            if (instance == null)
            {
                instance = new Singleton();
                HttpContext.Current.Items[Key] = instance;
            }
            return instance;
        }
    }
}

Unit Test

---

using System;
using System.Web;
using MarvellousWorks.PracticalPattern.SingletonPattern.WebContext;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace SingletonPattern.Test.Web
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            Singleton s1 = Singleton.Instance;
            Singleton s2 = Singleton.Instance;
            // 确认获得的Singleton实例引用确实已经被实例化了
            Assert.IsNotNull(s1);
            Assert.IsNotNull(s2);
            // 确认两个引用调用的是同一个Singleton实例
            Assert.AreEqual(s1.GetHashCode(), s2.GetHashCode());
            // 显示出当前Singleton实例的标识，用于比较与其他
            // HttpContext环境下的Singleton实例其实是不同的实例
            instanceHashCode.Text = s1.GetHashCode().ToString();
        }
    }
}

浏览器效果

---

同上，这段单元测试验证了Web Form下的细颗粒度Singleton，通过将唯一实例的存储位置从当前线程迁移到HttpContext，一样可以实现细颗粒度的Singleton设计意图。

更通用的细颗粒度Singleton

但如果你是一个公共库或者是公共平台的设计者，您很难预料到自己的类库会运行在Windows Form还是Web Form环境下，但Singleton模式作为很多公共机制，最常用的包括技术器、时钟等等又常常会成为其他类库的基础，尤其当涉及到业务领域逻辑的时候，很难在开发过程就约定死运行的模式。怎么办？

这里借助一个工具类，通过它判断当前执行环境是Web Form还是Windows Form，然后作一个2 in 1的细颗粒度Singleton（，听起来有点象早年的任天堂游戏卡），不过就像我们提到的面向对象设计的单一职责原则一样，把两个和在一起会产生一些比较难看的冗余代码，但Singleton与其他设计模式有个很显著的区别——他不太希望被外部机制实例化，因为他要保持实例的唯一性，因此一些常用的依赖倒置技巧在这里又显得不太适用。这里实现一个稍有些冗余的Web Form + Windows Form 2 in 1的细颗粒度Singleton如下：

UML

---

C# 工具类GenericContext

---

/// 判断当前应用是否为Web 应用的Helper 方法（非官方方法）
private static bool CheckWhetherIsWeb()
{
    bool result = false;
    AppDomain domain = AppDomain.CurrentDomain;
    try
    {
        if (domain.ShadowCopyFiles)
            result = (HttpContext.Current.GetType() != null);
    }
    catch (System.Exception){}
    return result;
}

C# 2in 1的细颗粒度Singleton模式实现

---

using System;
using System.Web;
using MarvellousWorks.PracticalPattern.Common;
namespace MarvellousWorks.PracticalPattern.SingletonPattern.Combined
{
    public class Singleton
    {
        private const string Key = "marvellousWorks.practical.singleton";
        private Singleton() { }     // 对外封闭构造
        [ThreadStatic]
        private static Singleton instance;

        public static Singleton Instance
        {
            get
            {
                // 通过之前准备的GenericContext中非官方的方法
                // 判断当前执行模式是Web Form还是非Web Form
                // 本方法没有在 .NET 的 CF 和 MF 上验证过
                if (GenericContext.CheckWhetherIsWeb())     // Web Form
                {
                    // 基于HttpContext的Lazy实例化过程
                    Singleton instance = (Singleton)HttpContext.Current.Items[Key];
                    if (instance == null)
                    {
                        instance = new Singleton();
                        HttpContext.Current.Items[Key] = instance;
                    }
                    return instance;
                }
                else  // 非Web Form方式
                {
                    if (instance == null)
                        instance = new Singleton();
                    return instance;
                }
            }
        }
    }
}

小结

设计模式中很多意图部分表述的要求其实也都是有语意范围 的，比如说“唯一”、“所有相关”、“一系列相互依赖的”等，但项目中往往有自己定制化的要求，可能的话建议尽量用语言、语言运行环境的特性完成这些工作。

A web server handles HTTP (Hypertext Transfer Protocol) requests sent to it by web browsers. When you type in a URL —http://www.digital-web.com, for example—your computer sends out a request to look up the servers needed to handle requests and send responses back quickly. The technique for determining how to route requests to the cluster of web servers efficiently is called load balancing.

Load Balancing Web Applications

It is easier to make the client code and resources highly available and scalable than to do so for the servers—serving non-dynamic content requires fewer server resources.

Load balancing increases the reliability of a web site by routing requests to other servers in the cluster when one of the servers is too busy or fails. There are many techniques for achieving load balancing, but generally they should meet the following requirements:

1. Distribute loads among a cluster of application servers.
2. Handle failover of an application server gracefully.
3. Ensure the cluster of servers appears as a single server to the end user.

A popular yet simple approach to balancing web requests is called round-robin DNS. This approach involves creating multiple DNS entries in the DNS record for the domain. For example, let’s say we want to balance the load on www.myloadbalancedwebsite.com, and we have two web servers with IP addresses of 64.13.192.120 and 64.13.192.121, respectively. To create a round-robin DNS to distribute requests, we simply create the following DNS entry:

www.myloadbalancedwebsite.com    64.13.192.120
www.myloadbalancedwebsite.com    64.13.192.121

As the end user’s web browser sends a request for the DNS record for www.myloadbalancedwebsite.com, the entry that is returned first will alternate. Since your browser uses the first entry returned, the requests are distributed evenly among our two servers. Unfortunately, the key drawback to round-robin DNS is that it fails the second requirement mentioned above—if one of the two servers fail, the DNS server will continue to send requests to it, and half of your end users will experience downtime.

Another popular load balancing technique involves handling requests with a single server or router dedicated to load balancing. Dedicated hardware equipment and software-based solutions such as F5 BIG-IP and Linux Virtual Server Project are examples of this type of solution. The dedicated load balancer takes requests and distributes them among a cluster of web servers. The load balancer detects if a server has failed, and routes requests to other servers. Also, to ensure that there is no single point of failure, a backup dedicated load balancer is available to take over in case the primary one fails.

The downsides to this approach are:

1. There is a limit to the number of requests the load balancer itself can handle. However, this problem can be resolved with the combination of round-robin DNS and dedicated load balancers.
2. There is an extra cost related to operating a dedicated load balancer, which can run into tens of thousands of dollars. The backup load balancer generally does nothing other than wait for the primary to fail.

Client Side Load Balancing

There is an approach to load balancing modern web applications that does not require any load-balancing hardware, and handles failure of servers more gracefully than round-robin DNS. Before delving into the details, let us consider a desktop application that needs to connect to servers on the internet to retrieve data. If our theoretical desktop application generates more requests to the remote server than it can handle using a single server, we will need a load balancing solution. Could we use the round-robin DNS and/or dedicated load balancer approach describe above? Of course, but there are other approaches that are more robust and less costly.

Instead of letting the client know of only one server domain from which to retrieve data, we can provide many servers—s1.myloadbalancedsite.com, s2.myloadbalancedsite.com, and so on. The desktop client randomly selects a server and attempts to retrieve data. If the server is not available, or does not respond in a preset time period, the client can select another server until the data is retrieved. Unlike web applications—which store the client code (JavaScript code or Flash SWF) on the same server that provides data and resource—the desktop client is independent of the server and able to load balance servers from the client side to achieve scalability for the application.

So, can we apply the same technique to web applications? Before we can answer this question, we need to establish what makes up a web application.

Web applications have inherently blurred the boundary between the client component and the server component of a typical application. Web applications written in PHP may often have the server code entwined with the client code. Even if an MVC (model-view-controller) pattern framework is applied, and good practice is followed by separating code that generates the presentation layer (HTML) from code used for backend logic, it is still the server that is generating and serving the presentation. In addition, resources such as images are served by the server as well—but with new web technologies, the boundaries have shifted. Many applications today only make AJAX or Flash remoting calls—in fact, there is a lot of similarity in the ways a standard desktop application and web applications make remote calls.

For the purposes of client-side load balancing, there are three main components to a modern web application:

1. Client-side code: JavaScript and/or SWF (for flash clients)
2. Resources: images, CSS (Cascading Style Sheets), audio, video, and HTML documents
3. Server-side code: backend logic that generates data requested by the client

It is easier to make the client code and resources highly available and scalable than to do so for the servers—serving non-dynamic content requires fewer server resources. In addition, it is possible to put the client code on a highly reliable distribution service such as Amazon Web Services’s S3 service. Once we have client code and resources served from a highly reliable location, let us take a look at how we can load balance server clusters.

Just like the desktop client above, we can embed our list of application servers into the client code. The web client contains a file called “servers.xml”, which has a list of available servers. The client tries to communicate (whether via AJAX or Flash) with every server in the list until it finds one that responds. Our client-side process is therefore:

1. Load the file www.myloadbalancedwebsite.com/servers.xml, which is stored with the client code and other resources, and contains the list of available servers, e.g.:
   

   <servers>
     <server>s1.myloadbalancedwebsite.com</server>
     <server>s2.myloadbalancedwebsite.com</server>
     <server>s3.myloadbalancedwebsite.com</server>
     <server>s4.myloadbalancedwebsite.com</server>
   </servers>

2. The client code randomly selects servers to call until one responds. All subsequent calls use that server.
3. The client has a preset timeout for each call. If the call takes greater than the preset time, the client randomly selects another server until it finds one that responds, and uses that server for all subsequent calls.

Making Cross-Domain Calls

If you’ve been working with AJAX for any length of time, you’re probably thinking, “This won’t work, because of cross-domain browser security,” so let’s address that.

For security reasons, web browsers and Flash clients will block calls to a different domain—for example, if the client wants to talk to the server s1.myloadbalancedwebsite.com, the client code must be loaded from the same domain, s1.myloadbalancedwebsite.com. Requests from clients loaded from any other domain will be blocked. In order for the load-balancing scheme described above to work, the client code at www.myloadbalancedwebsite.com needs to be able to call services running on other sub-domains (such as s1.myloadbalancedwebsite.com).

For Flash clients, we can simply set the “crossdomain.xml” file to allow requests from *.myloadbalancedwebsite.com:

<cross-domain-policy>
  <allow-access-from domain="*.myloadbalancedwebsite.com"/>
</cross-domain-policy>

For AJAX-based client code, the restriction depends on the transport we use to make server calls. If we use the Dynamic script Tag method to transport calls, there is no security issue, because we can make server calls without cross-domain security constraint issues. (However, it is generally a good idea to check the referrer header to make sure it is definitely your client that is making the server requests, for the sake of your site’s security.)

What if the application uses XMLHttpRequest? XHR strictly forbids client calls from a different domain to the server. Luckily, a workaround exists if the client and server have the same parent domain—as in our example, www.myloadbalancedwebsite.com and s1.myloadbalancedsite.com. We can make all AJAX calls to the server using an iframe loaded from the server; since browsers allow communication between scripts in an iframe, it is possible to access data received from the server calls made in the iframe if the scripts are loaded from the same parent domain. Problem solved.

Advantages of Client-Side Load Balancing

Now that we can make cross-domain calls, let us see how well our load-balancing technique meets the requirements outlined at the start of the article.

1. Distribute loads among a cluster of application servers. Since the client randomly selects the server it connects to, the loads should be distributed evenly among the servers.
2. Handle failover of an application server gracefully. The client has the ability to failover to another server when the chosen server does not respond within a preset period of time. The application server connection seamlessly fails over to another server.
3. Ensure the cluster of servers appears to the end user as a single server. In the example, the user simply points a browser to http://www.myloadbalancedwebsite.com/. The actual server used is transparent to the user.

So what are the advantages of using client-side load balancing over server-side load balancing? The obvious advantage is that a special load-balancing device is unnecessary—there is no need to configure load-balancing hardware, or to make sure that the backup functions the same as the primary load balancer. If a server is unavailable, simply remove it from the “servers.xml” file.

Another advantage is that servers do not have to be housed in the same location; since the client is selecting servers instead of having a fixed load balancer redirecting traffic, the locations of the servers are unrestricted. Servers can be in multiple datacenters in case one datacenter is not accessible. If the application requires a database on the local network, the other datacenter can still be used as a backup in case your primary one is unavailable. Changing to another datacenter is as simple as making an update to the “servers.xml” file, instead of waiting for DNS changes to propagate.

Voxlite, a Client-Side Load Balanced Web Application

Voxlite, a web-2.0 application that lets users send video messages to one another with just a browser and a webcam, is an application that uses client-side load balancing to achieve high availability and scalability. In addition, Voxlite uses the Simple Storage Service (S3) and Elastic Computing Cloud (EC2) services from Amazon Web Services.

From very early on, the S3 service presented an attractive option for storing and serving the video messages, and EC2 was naturally designed to work with the S3 service. It provides an easy and cost-effective way for Voxlite to scale to support more users. EC2 instances can be allocated at any time by simply starting a virtual machine image—each EC2 instance costs ten cents per hour, or seventy-two dollars per month. But what makes EC2 even more attractive is the computing resource is elastic; EC2 instances can be de-allocated when they are not being used. For example, if Voxlite gets more traffic during the day than in the evening, it is possible to only allocate more servers during the day, and thus, greatly increase the cost-effectiveness of the hosting solution. Unfortunately, one major drawback with EC2 is that it is not possible to architect a server-side load balancing solution that doesn’t have a single point of failure. Many web applications hosted on EC2 use a single EC2 instance with dynamic DNS to load-balance requests to a particular domain. If the instance that provides the load balancing fails, the whole system can become unavailable until the dynamic DNS maps the domain to another EC2 instance.

Using the client-side load balancing technique described above, it is possible to have a load-balanced solution with EC2 servers that has no single point of failure. To build a cluster of EC2 instances supporting client-side load balancing, Voxlite’s client code and other web resources is stored on, and served from, S3. An EC2 image with the server code is created so that whenever an EC2 instance starts, it is properly configured and ready to handle client requests. Voxlite then uses a clever technique to make the client aware of the available servers.

Earlier, I described the use of a “servers.xml” file to let the client know the list of available servers—but, with the S3 service available, there is a better way. When accessing an S3 bucket (a bucket is a term used by S3 for storing a group of files; the idea is similar to file folders) without any keys, the S3 service will simply list all the keys matching the given prefix—so, in each of Voxlite’s EC2 instances, a cron job is created that runs periodically and registers the server as a cluster member by writing an empty file with the key servers/{AWS IP address} to a publicly readable S3 bucket.

For example, if I go to the URL http://s3.amazonaws.com/voxlite/?prefix=servers, I get the following response:

<ListBucketResult>
  <Name>voxlite</Name>
  <Prefix>servers</Prefix>
  <Marker/>
  <MaxKeys>1000</MaxKeys>
  <IsTruncated>false</IsTruncated>
  <Contents>
    <Key>servers/216.255.255.1</Key>
    <LastModified>2007-07-18T02:01:25.000Z</LastModified>
    <ETag>"d41d8cd98f00b204e9800998ecf8427e"</ETag>
    <Size>0</Size>
    <StorageClass>STANDARD</StorageClass>
  </Contents>
  <Contents>
    <Key>servers/216.255.255.2</Key>
    <LastModified>2007-07-20T16:32:22.000Z</LastModified>
    <ETag>"d41d8cd98f00b204e9800998ecf8427e"</ETag>
    <Size>0</Size>
    <StorageClass>STANDARD</StorageClass>
  </Contents>
</ListBucketResult>

In this example, there are two EC2 instances in the cluster, with IP addresses of 216.255.255.1 and 216.255.255.2 respectively.

The logic for the cron job is:

1. Load and parse http://s3.amazonaws.com/voxlite/?prefix=servers.
2. If the current running instance is not listed, write an empty file to the bucket with the key servers/{IP address of EC2 instances}.
3. Verify if other servers listed in the bucket are running properly by testing the connection using the internal AWS IP address. If a connection cannot be established, remove the server key from the bucket.

Once this cron job is a part of the EC2 image, each running instance is automatically registered as an available server in the cluster. The client code (AJAX or Flash) parses the list of keys in the bucket and extracts the external AWS host name, allowing it to then randomly select a server to connect to, as described above when using the “servers.xml” file. If an EC2 instance shuts down or happens to crash, the other instances in the cluster would automatically remove its key from the bucket—the bucket would be left with only available instances. In addition, the client can select another EC2 instance in the bucket if a request does not get a response in the preset time. If the web site is getting more traffic, simply start more EC2 instances. If the load decreases, simply shut down the extra instances. By using client-side load balancing with S3 and EC2, it is easy to build an elastic, scalable and robust web application.

References and Additional Readings

• More detailed information on how to make cross domain XMLHttpRequest using iframe.
• An introduction on the dynamic script tag method and comparison to XmlHttpRequest.
• An article with detailed information on round-robin DNS and server side load balancing of web applications.
• Linux Virtual Server is a popular open source project frequently used to achieve server side load balancing for web applications.
• Amazon Web Services web site and blog has interesting information about S3 and EC2 and how companies are using them.
• A white paper on performance tuning of front end presentation layer, containing some discussions on how to efficiently serve web 2.0 client code and resources。

　　现在的技术人员，很多时候，不管三七二十一，把一个个实体丢到缓存中，然后在用的时候，就从缓存中去找这个实体。而不会考虑缓存的其他方面因素。所以他们在提到缓存时，想到的才只能是一个个的缓存实现的方法，而不是缓存的思想。

　　那么，肯定就有人问，蝈蝈俊，那你理解的缓存思想是如何的呢？下面我就一一来说出我理解的缓存。

Q：什么样的缓存才是好缓存？

　　能解决问题的缓存就是好缓存。这句话简直就是废话，相当于白猫、黑猫，抓住老鼠的就是好猫。

　　那在解决问题前提下，哪个缓存才是好缓存呢？ 这个问题我的答案是：缓存命中率高的缓存是好缓存。

　　在解决问题前提下，命中率高的缓存比命中率低的缓存，在硬件投入上可能会比较小，同时缓存的数量比命中率低的缓存数量也可能少，这样寻址的速度肯定比较快。所以命中率高的缓存是好缓存。