Disk I/O is responsible for almost all slow websites and desktop applications. It’s true. Watch your CPU use next time you open a program, or your server is under load. CPUs aren’t the bottleneck anymore – your hard drive is. At the hardware level, the hard drive is the slowest component by an incredibly large factor. Today’s memory ranges between 3200 and 10400 MB/s. In contrast, today’s desktop hard drive speeds average about 50 MB/s (Seagate 500GB), with high-end drives getting 85MB/s (WD 640, Seagate 1TB). If you’re looking at bandwidth, hard drives are 200-300 times slower. Bandwidth, though, isn’t the killer – it’s the latency. Few modern hard drives have latencies under 13 milliseconds – while memory latency is usually about 5 nanoseconds – 2,000 times faster.

You’re probably looking at these numbers and thinking, “13ms is quite fast enough for me, and my app is only dealing with small files”. However, I have a question: what other applications are using that drive? If you’re on a shared server, the odds are high that between 25 and 2500 ASP.NET apps are being run on the same drive.

CPU, bandwidth, and memory throttling is becoming more and more common on shared servers and virtualization systems, but practical disk throttling isn’t even on the horizon from what I can tell. Improper I/O usage from any app affects everybody.

Since hard drives are slow, pending operations go into a queue. So even if your app only needs a single byte of data from the hard drive, it still has to wait its turn. It’s quite common for disk operations to take several seconds on a shared server under heavy load. If any application on the server is paging to disk from exessive memory use, it can take several minutes, causing a timeout.

Realistic I/O performance is really hard to simulate in a development environment. On a dedicated development machine, disk queues are short, and response times are usually near the optimal 13ms, which tends to give software developers gravely incrorrect ideas about the performance characteristics of their application.

Load test!

A good way to acid test your code is to run it on a cheap, overloaded shared server. Webhost4life.com has $10/month plans that are excellent for this purpose. I’m actually using Webhost4life.com for this site, and while I/O calls consistently take around 1 second each, page views are decently quick since everything is in memory. I can’t seem to get more than 30-40KB/s bandwidth though, so I’m probably going to switch hosts soon.

Stress testing can also be accomplished with load testing tools like the Web Application Stress Tool. Getting realistic results often means multiplying user load by a factor of 1000 or more, since I/O speeds can vary by that much on a production server. So, if you want to handle 50 concurrent users gracefully, test with 50,000.

One good way to make sure your app can handle high load is to get your per-request time very low. There is an extension for Firefox that provides TTFB (time-to-first-byte) information that will help you measure this. (Trace.axd is an invaluable tool here also). If requests complete in 13 milliseconds, the odds are good that you can handle 100 of those requests per second.

Cache smart

It’s not too hard to cache files in memory. Here’s one approach that uses ASP.NET’s built in caching system:

namespace fbs.Filesystem
{
    /// <summary>
    /// Provides cached read access to small, frequently used files. Use carefully!
    //// Uses HostingEnvironment.Cache (same as app cache).
    /// </summary>
    public static class CachedFileAccess
    {
        /// <summary>
        /// Retrieves the file from the cache, or from disk if neccessary. Exceptions from IO.File.ReadAllText are not caught.
        /// Make sure the file exists and can be accessed before attempting this function.
        /// </summary>
        /// <param name="file">Standard pathname (C:\..</param>
        /// <param name="encoding"></param>
        /// <returns></returns>
        public static string ReadAllText(string file, Encoding encoding)
        {

            if (HostingEnvironment.Cache == null) throw new InvalidOperationException("HostingEnvironment.Cache is null");
            string key = "cached_file(" + encoding.EncodingName + ")_" + file.ToLowerInvariant().GetHashCode();

            string value = HostingEnvironment.Cache[key] as string;
            if (value == null)
            {
                value = System.IO.File.ReadAllText(file, encoding);
                HostingEnvironment.Cache.Add(key, value, new System.Web.Caching.CacheDependency(file),
                    System.Web.Caching.Cache.NoAbsoluteExpiration, System.Web.Caching.Cache.NoSlidingExpiration, System.Web.Caching.CacheItemPriority.Low,null);

            }
            return value;
        }
    }
}

If you must do I/O, File.Exists and File.GetLastWriteTimeUtc are much faster that actually opening a file. The filesystem ‘tables’ are often cached in memory, and therefore have much higher average performance.

Don’t do memory leaks. In-memory caching is good, but if you have a memory leak the app’s memory space will get moved to disk, effectively slowing all memory access down the hard disk speeds. Not good. And you’re going to kill everyone else on the same disk. Make sure there is a finite and reasonable limit to what will be cached (especially if you’re using static variables instead of the ASP.NET cache object).

Asynchronous=good, synchronous=evil.

In any application, asynchronous IO calls should be used whenever possible. There’s a reason that I/O and web service calls in well-built applcations are async – it is impossible to predict how long I/O operations will take. Any hard drive operation can take seconds to minutes – and there is no way to insure a responsive experience to users unless you make sure all I/O calls are out-of-band.

One nice thing about the web is that HTTP request are by nature async – so if you have any I/O calls that *must* be made, you can do them with AJAX later instead of holding up the entire page while they execute.

Databases are a Good Thing

Databases are Good. Build the right indexes, and queries will be quick. Most engines cache as much data as possible in memory (usually indexes get priority caching), so a well-designed database will almost alwasy beat standard I/O.

Hybrid approaches can get the best of both worlds

Being able to edit your files on disk is really nice – it tempts people away from database-driven websites all the time. But – you can have both ease-of-use and performance. nathanaeljones.com can be completely managed through an FTP connection and Notepad, if needed. It’s nice to drag-and drop files when I need to upload a bunch. It’s nice to use VS when I want to do some tricky coding.

Every few minutes, a ~1.5 second syncronization routine does a quick GetLastWriteTimeUTC check on the .aspx files that start with an ID, and pushes any changes to the database. The database is read only – basically a cache of the filesystem. But it allows instant, flexible querying/searching of all the articles, and provides the best of both worlds.

I don’t edit files manually much anymore, although it does come in handy. Right now I’m using the web-based article editor to write this – most of my work occurs through my online ASP.NET markup editor. But for those who like the comfort of Dreamweaver or VS, they can edit their articles in WYSIWYWYG mode all day long

It can be difficult to write a filesystem to database synchronization system properly – there are a lot of wrong ways to go about it. Done properly, it can scale up to at least 50,000 articles. The routine must be located on a separate thread, and must use a ReaderWriterLock to prevent reads while database is build batch updated with SqlBulkCopy calls. A single call is used to get the listing of .aspx files: System.IO.Directory.GetFiles(appRoot, “*.aspx”, System.IO.SearchOption.AllDirectories); A database call downloads the paths and last-modified dates from the database, and the two are cross-referenced to compile a list of created, moved, changed, and deleted files. These changes are then commited to the database using SqlBulkCopy, as well as being logged. Changed files are compared with the SQL copy to generate a Diff report for the log.

Filesystem state

Another factor in disk performance is the state of the filesystem. While filesystems are usually built using very smart algorithms, all algorithms slow down as they have to crunch more data. The more files you get on a disk, the slower file lookup and access becomes. I’ve compared identical 15k disks with no difference except the number of files, and the response time difference would almost make you suspect the one with 500,000 files to be a floppy drive.

In conclusion

Disk performance slightly increases each year and SSDs are promising, but physical disks never seem to catch up to our need for space and speed. I/O operations on shared or highly-active servers will probably be slow for many years to come.

Think carefully before you use System.IO, and make sure there aren’t any alternatives. Pretend you’re calling a web service each time you use the File class, and be kind to your users.

Say NO to IO

For the query string to be parsed correctly, the delimiters ?, &, and = cannot be percent-encoded. Both names and values in the Request.QueryString collection go through exactly one URLDecode pass. Other properties in the Request class include the querystring in its original, URLEncoded form (if they were originally URL (percent) encoded).

Also, any strings that aren’t parsed correctly are added to Request.QueryString[null] in comma-delimited format. (You can also access them as a string[] array using Request.QueryString.GetValues(null)). The NameValueCollection class isn’t a string-to-string dictionary. It’s more like an informal string-to-string[] dictionary. When you set a value like nvc["thiskey"]=”thisvalue” , you are in overwrite mode. When you use nvc.add(“thiskey”,”thisvalue”), you are in append mode. Calling nvc.add(“thiskey”,”firstvalue”), then nvc.add(“thiskey”,”lastvalue”) will leave nvc["thiskey"] == “firstvalue,lastvalue”.

Related links

• URI Design
• Wikipedia: Uniform Resource Identifier
• Wikipedia: URL Normalization
• Wikipedia: Percent encoding

ASP.NET is essentially an advanced request-processing framework.
Naturally, the URI is the most important part of any request (or should be).
URIs should be well designed, and should represent the requested content accurately and succinctly.
Unfortunately, they are frequently misused, which causes browsers, users,
and search engines no end of trouble.

Some misuse URIs by making them too generic;
some sites have everything on the home page.
Flash, AJAX, and frames are the biggest culprits here,
as they are capable of making big changes to the current content of the page without affecting the address bar.
Users of this type of site are frustrated because if they bookmark a buried page in the site,
it only records the address of the home page.
The back button also betrays them – it doesn’t undo their actions anymore,
but plops them completely off the site.

Search engines dislike these sites because either (1) they can’t access buried content due to its form
(JavaScript or Flash) or (2) they can access it, but all keywords are diluted from the massive amount
of content available on one page.

Some developers take the misuse to the opposite end.
The feel that the address bar is the perfect place to store all variables, interface state data,
and user preferences. They, too, cause problems for both users and search engines.
Users bookmarking or e-mailing such links often find that they no longer work after their session has expired,
or after a change was made on the site.
Their length and lack of simplicity also makes them hard to understand,
as many users depend on the address bar to understand where they are located on the site. URLs longer than 80 characters are also a pain to e-mail. Many e-mail clients will break the URL in half, making it unusable.

Search engines find these type confusing, because they see (and rank) each unique URI as a separate page, and dilute ranking accordingly.

So, you ask, what makes a good URI?

• It should be as short as possible. Don’t sacrifice consistency or obviousness, but be brief.
• Organize and name things logically. ASP.NET isn’t always helpful in keeping a clean structure,
  so I highly recommend that you use a URL rewriting module. URIs should be ‘hackable’.
• URIs should be deterministic.
  • No two URIs should ever display the same page
  • The same URI should always display the same content.
• The query string should only contain data that AFFECTS THE QUERY.
  If it doesn’t describe the content, it doesn’t belong. Keep the query string for queries, please.
• Tip: Don’t try to spam URLs with keywords.
  Density algorithms are applied here, also. As with page titles, pick 1 keyword and stick with it.

  The URI path should not rely on cryptic or numerical identifiers.
  If it does, it should also provide a human-readable title.
  It’s really nice to be able to look at a URL and guess what it contains -
  especially when you have a long list of them.
  As a bonus, search engines absolutely love URIs that match keywords.

Further reading (by Tim Berners-Lee):
http://www.w3.org/Provider/Style/URI.

I strongly suggest that all ASP.NET projects use some kind of URL rewriting library, such as UrlRewritingNet. Even if you only need a single rewrite, I still recommend using a library instead of trying to do it yourself. UrlRewritingNet helps you overcome the bugs in the framework seamlessly.

Bad examples:

• /Default.aspx?tabid=3
• /Products/ShowProduct.aspx?prodid=4982
• /showblog.aspx?articleid=98

Better examples:

• /Default.aspx?tabid=3&title=ContactUs
• /Products/ShowProduct.aspx?id=4982&product=Nokia_Wall_Adpater_12V
• /showblog.aspx?articleid=98&title= Why_you_should_never_concatenate_SQL_commands

Even better:

• /contact/
• /products/4982_Nokia_Wall_Adapter_12v
• /blog/98_Why_you_should_never_concatenate_SQL_commands

WWW

The famous “www” prefix is actually pointless. You can still have ftp, mail, and smtp subdomains without forcing your website to use www. The www convention came into being since servers were typically named after their role, and HTTP was just starting out.

Since web browsers only speak HTTP, you should really point your second-level domain (example.com) directly to your web server. Realize that some search engines will index www.example.com and example.com separately, since they are different locations. To prevent SSL cert and cross-domain flakiness in Flash, you should standardize on one or the other. You can force this by checking for www in Global.asax, and calling Response.Redirect() with the “fixed” version of the requested URI.

URIs in the HTTP protocol

Let’s look at how URI is sent to the server using HTTP Here is a basic GET request. The first line consists of the HTTP method,
followed by a root-relative path, then the protocol version. The subsequent lines contain the header collection,
in the form of simple name-colon-value pairs.
The two parts of the URI here are the path (/blog?page=2), and the HOST-header (youngfoundations.org).
We know that the scheme is probably “http” since we are communication using the HTTP protocol.
IIS tells us which port the request arrived on, so between the pieces we can reconstruct the original URI somewhat accurately.

The path and the query are divided by the first question mark.

GET Request

The client can send content with any request, although it is typically sent with the POST method.
The header collection is separated from the request body by the character sequence [CRLF][CRLF] (2 newlines).
The content in the request body is described by the content-type and content-length HTTP headers.

POST Request

Response

The HTTP response generated by your ASP.NET application looks slightly different that the request that prompted it.
The general format remains, but the first line is now [HTTP Version] [Status-code] [Status code description].
Http status codes are very important, but are beyond the scope of this article.

Important note: If you have multiple domains pointing to one website,
make sure they are all 301 redirected to precisely one host name.
Otherwise you will sabotage your search engine placement by (1) diluting your page rank, and
(2) being penalized for duplicate content.

URIs versus URLs

The term URL (Uniform Resource Locator) has been considered obsolete by w3c for a long time.
In its place stands the URI (the Uniform Resource Identifier).
Strictly speaking, a URL must provide all of the information required to located and retrieve a resource,
while a URI is only required to identify it in relation to the current context.
Thus, a URL is a URI that “in addition to identifying a resource, [provides] a means of locating the resource
by describing its primary access mechanism (e.g., its network ‘location’).”. Most people aren’t aware of the difference, and use them interchangeably.

For example, the following URI is also a URL:

• http://www.mysite.com:54321/ folder/virtualfolder/default.aspx? param1=thisisatest&param2=test2

However, these are not:

• ../css/shared.css [URI relative to the location of the parent document]
• /images/banner.jpg [URI relative to the current network location (usually termed 'absolute')]
• Logo.gif [URI relative to the location of the parent document.]
• #requirements [URI fragment relative to current document.]

Fragments

Fragments describe a section, place, or entity in the current document.
In HTML, they usually refer to a certain anchor tag (by name or ID).
The window is usually scrolled to the location of the anchor tag.
Fragments are never sent to the server computer, and only function as a display instruction to the client.
If a fragment isn’t understood, it is ignored.
Fragments are pretty much free-form.

If the current document is http://mysite.com/home.html and a link to
http://mysite.com/home.html#part3 is clicked, the browser (or user-agent),
is not supposed to ask the server for http://mysite.com/home.html again, but older clients may.
Relative fragments like #part3 are handled more reliably.

Now let us dissect the following URL:

http://www.mysite.com:54321/folder/virtualfolder/default.aspx? param1=thisisatest&param2=test2

http The scheme (protocol). The protocol determines how the client should talk to the server (basically the language, or grammar).

www.mysite.com The computer the resource is located on (DNS, WINS, or IP Address)

:54321 The port number to communicate with on the computer.

Instead of trying to sort out incoming packets and route them to the right application on the server computer, ports are used.
Certain default ports are assumed for some protocols.
Http requests are sent to port 80 by default.
Https requests are sent to port 443, and FTP requests are sent to port 21.
If an application is not listening on that port (or the request packets are blocked by a firewall), no response will be given.

Additional sorting is sometimes performed, as in the case of WCF (.NET 3.0) port sharing,
or when multiple sites are hosted on a single server. When an HTTP request is sent to a server,
it is accompanied by the original hostname from the address bar. An unlimited number of DNS (Domain Name System)
addresses can point to a single computer, which is convenient for web hosting providers. IIS (Internet Information Services)
can be configured to look at this host header, and forward the request to whichever site is configured to receive requests for
that particular hostname (DNS address).

For information about DNS, read http://en.wikipedia.org/wiki/Domain_name_system.

Super-simplified view of DNS

DNS addresses are hierarchical, and levels (domains) are separated by a period.
Domains progress from most specific to least specific.

For example, in resolving www.mysite.com, the following steps would be taken:

• Ask computer ‘COM’ where computer ‘MYSITE’ is at (what its IP address is).
• Ask computer MYSITE where computer ‘WWW’ is at.

DNS is used for a whole lot more that just web browsing,
so the company at mysite.com might have a whole bunch of computers, such as ftp.mysite.com, mail.mysite.com, pop.mysite.com,
telnet.mysite.com, as well as www.mysite.com.
WWW usually points to the web server for the company.
Please note, however that the WWW part is completely unnecessary,
and is just a commonly followed convention.

Note: In www.mysite.com, “com” is a TLD (Top-level domain),
and “mysite” is a SLD (Second-level domain)

SLDs usually cost a registration fee, as the poor owner of the “COM” computer has tremendous bandwidth bills.
Third-level domains can be freely created if the parent SLD is under your control.

One of the most critical steps in designing a web site is choosing your URI structure for the site. Clean, friendly URIs make visitors more comfortable and help them keep track of where they are on the site. Short URLs don’t get wrapped as badly, are easier to type, and just look nicer.