ultra-fast asp.net can give you strong idea to build the super fast website
Recently, I've read ultra-fast asp.net from the apress, I think it's the best asp.net book I've ever read. I'm sure it will give you a lot help to build the super fast asp.net web application, it contains many best topics to build the fast web. It's easy to read and so I think it's necessary to share with you about the main ideas of this book as following:
Principles and Method
Focus on perceived performance.
Minimize blocking calls.
Reduce round-trips.
Cache at all tiers.
Optimize disk I/O management.
Client Performance
Put one or more requests for resources in the first 500 bytes of your HTML.
Move requests for resources form the <head> section into the <body> of your HTML, subject to rendering restrictions.
Make the position of objects on the page independent of download order, with early adn late-loading techniques (load large objects as late as you can).
Use lowercase for all your URLs.
Use a single, consistent URL for each resource, with matched case and a single domain name.
Use from two to four subdomains to optimize parallel loading of your static files.
Try to start a request for one image or CSS file before loading a script file from the same domain so that the requests happen in parallel.
Minimize the number of different script files you're using. If you can't avoid having multiple files, combine them into a small number of files on the server.
If you don't avoid document.write(), use absolute positioning to invoke the script late in the file or use the hidden <div> technique.
Create browser-specific pages on the server rather that with script.
Use the page onload handler to request objects that aren't needed until after everything else on the page, such as rollover images or images below the fold.
Replace spacer GIFs and text images with CSS.
Merge multiple CSS files to one.
Hide, remove, or filter comments from your HTML, CSS, and Javascript.
Install the Web Deployment Projects add-in for Visual Studio, and use it to run a JavaScript minifier such as jsmin to reduce the size of your JavaScript and to build a precomplied site for easy and fast deployment.
Use lowercase HTML tags and property names.
Consider using CSS instead of images for transparency, borders, color, and so on.
Consider varying CSS transparency instead of using separate rollover images.
Use image tilling to keep your images sizes to the bare minimum, such as for backgrounds.
Crop or resize images to the minimum size.
Use the smaller of GIF or PNG format for lossless images, and use JPEG for complex images without sharp edges in them (such as photos).
Enable progressive rendering on large PNG and JPEG images, to improve perceived performance.
Increase the level of compression on JPEG images to the maximum that's reasonable for your application.
Use the lowest bit depth on your images that you can (8-bit images are smaller that 24-bit images).
Use image slicing to improve the perceived performance of large images.
Consider using image maps instead of multiple images for things like menus (although a text and CSS-based menu is even better).
Specify and image's native size or larger in an <img> tag. If you need to use a size that's smaller that native, you should resize the source image instead.
Instead of modifying image sizes to adjust fill and spacing on a page, use CSS.
Set a relatively near-term expiration date on your favicon.ico file(such as 30 days).
Consider running your HTML and CSS through an optimizer, such as the one available in Expression Web.
Remove unused and duplicate CSS classes.
Remove unused JavaScript.
Move style definitions into your CSS file.
Consider generating inline CSS the first time a user requests a page on your site, followed by precaching the CSS file to reduce the load time for subsequent pages.
Validate form fields on the client before submitting them to the server.
Don't enable submit buttons until all from fields are valid.
Use script or Silverlight to generate repetitive HTML, which reduces HTML size.
Use script or Silverlight to add repetitive strings to property values in you HTML.
Minimize the total size of your cookies by using short names, optimized encoding, merging multiple cookies into one, and so on.
Set and explicit path for all coolies, and avoid using the root path(/) as much as possible.
Group pages and other content that need cookies into a common folder hierarchy, to help optimize the cookie path setting.
Reference your static content from subdomains that never use cookies.
Optimize your CSS by merging and sharing class definitions, leveraging property inheritance, eliminating whitespace, using short speifiers, property cascading, and so on.
Combine multiple images used on one page into a single file, and use CSS image sprites to display them.
Leverage DHTML to avoid a server round-trip for things like showing and hiding part of the page, updating the current time, changing fonts and colors, and event-based actions.
Use Ajax to make partial-page updates.
Use Silverlight as a supplement to JavaScript for things like cross-domain web services and for more complex logic, because it uses type-safe .net languages.
Consider Silverlight as an alternative to HTML for forms, chart, graphs, animation, grids or tables with client-side sorting, and so on.
Use Silverlight to manage data in isolated storage that can be used by the client from one page to another.
Prefer CSS to <table>.
When you can't avoid <table>, consider using <col>, and make sure to set the size properties of any images the <table> contains.
Include a <!DOCTYPE> tag at the top of your HTML.
If you can anticipate the next page that a user will request, use script to precache the content and DNS entries that page will use.
Optimize the performance of your JavaScript.
Caching
Enable Cache-Control: max-age for your static content, with a far-future expiration date.
Review all pages of your dynamic content, and establish an appropriate caching location and duration for them: client-only, proxies, server-side, cache disabled, and so on.
Use cache profiles in web.config to help ensure consistent policies.
Disable ViewState by default at the page level. Only enable it on pages that postback and where you explicitly need the functionality it provides.
Create and use a custom template in Visual Studio that disables ViewState, disables AutoEventWireup, and sets a base class for your page, if you're using one.
Use ViewState or ControlState to cache page-specific state.
Prefer using cookies or Silverlight isolated storage to cache state that's referenced by multiple pages, subject to size and security constrains.
Send a privacy policy HTTP header (P3P) whenever you set cookies.
Use Cache.SetVaryByCustom() for pages that vary their content based on HTTP headers such as Accept-language.
If your site has a large quantity of static content, consider using a CDN to offload some of it.
Change the name of your static files (or the folders they're in) when you version them, instead of using query strings, so that they remain cacheable by http.sys.
Enable output caching for your use controls, where appropriate.
If you have pages that you can't configure to use the output cache, consider either moving some of the code on the pages into a cacheable user control or using substitution caching.
Avoid caching content that is unique per user.
Avoid caching content that is accessed infrequently.
Configure cached pages that depend on certain database queries to drop themselves from the cache based on a notification that the data has changed.
Use the VaryByCustom function to cache multiple versions of a page based on customizable aspects of the request such as cookies, role, theme, browsers, and so on.
Use a cache validation callback if you need to determine programmatically whether a cached page is still valid.
Use HttpApplicationState, Cache, and Context. Items to cache objects that have permanent, temporary, and per-request lifetimes, respectively.
Associate data that you store in Cache with a dependency object to receive a notification that flushes the cache entry if the source data changed.
Consider using a WeakReferecne object to cache objects temporarily in a lightweight way compared the Cache object, but with less control over cache lifetime and related events.
Use the 64-bit versions of Windows Server and SQL Server.
Make sure your database server has plenty of RAM, which can help improve caching.
Consider precaching SQL Server data pages into RAM by issuing appropriate queries from a background thread when you can anticipate the user's next request.
For dynamic content that changes frequently, consider using a short cache-expiration time rather than disabling caching.
IIS7
Partition your application into one or more AppPools, using the Integrated pipeline mode.
Configure AppPool recycling to happen at a specific time each day when your servers aren't busy.
Consider using a web garden (particularly if your site is LG_3+ but you are temporarily using LG_2).
If you're using multiple AppPools, consider using WSRM to help ensure optimal resource allocation between them when your system is under load.
Use Log Parser to check your IIS logs for HTTP 404 Not Found errors and other similar errors that may be wasting server resources.
Configure IIS to remove the X-Powered-By HTTP header.
Install an HttpModule to remove the Server and ETag HTTP headers.
Modify your web.config to remove the X-Aspnet-Version HTTP header.
Enable site-wide static file compression.
Add support for the deflate compression option to applicationHost.config.
Specify staticCompressionLevl="10" and dynamicCompressionLevl="5" in applicaionHost.config.
Trun off the feature that disables compression if the server's CPU use exceeds a certain threshold.
Modify applicationHost.config to allow the <urlCompression> tag to be specified in web.config.
Use the <urlCompression> tag in web.config to selectively enable dynamic compression.
Enable dynamicCompressionBeforeCache so that your content is cached after it's compressed rather than before.
Keep your URLs short and your folder hierarchies flat, rather that deep.
Consider using virtual directories to help flatten existing hierarchies.
Consider using URL rewriting to help shorten URLs and make them more meaningful for search engines.
Use Failed Request Tracing to validate caching behavior and to find pages that fail or run too slowly.
Consider using IIS bandwidth throttling to help smooth the load on your servers, particularly during peak periods.
ASP.NET Threads and Sessions
Use asynchronous pages for all pages that do I/O, including accessing the database, web service calls, filesystem access, and so on.
Modify the <applicationPool> section in your Aspnet.config file to reflect the load on a remote system is an issue, such as with some web services.
Use a code rather than the runtime to enforce concurrency limits where the load on a remote system is an issue, such as with some web services.
If you have an existing site that uses asynchronous calls, you're seeing low CPU use and high request latencies, and your code is compatible with load balancing, consider temporarily using multiple worker processes while you migrate to async pages.
Add a background worker thread to your application, and use it for tasks that don't have to be executed in-line with page requests, such as logging.
Avoid session state if you can; use cookies or Silverlight isolated storage instead whenever possible.
If you do need session state, configure the runtime to store it in SQL Server.
When using session state, disable it by default in web.config, and enable it only on the pages that need it.
Configure ReadOnly session state for pages that don't need to write it.
If your site makes heavy use of session state, maximize the performance of the supporting hardware, and consider using partitioning for added scalability.
When you choose which objects to store in the Session dictionary, prefer basic data types to custom objects.
Using ASP.NET to Implement and Manage Optimization Techniques
Use master pages as a dynamic page template system.
Use custom user controls to factor out code that you use on several different pages.
Consider applying output caching to your user controls.
Use short strings for control IDs, because the strings can appear in your HTML.
Use IDs only when you need to reference on object from your code-behind.
Use ASP.NET themes to help group and manage your style-related assets. Prefer styleSheetThemes to standard themes.
Use ASP.NET skins to help define default or often-used user control properties.
If you need in-depth support for mobile devices, download and install the Mobile
Device Browser File.
Use the Request Browser object and browsers prefixes to specify brower-specific logic.
Use an optimized GetVaryByCustomString() to limit the number of different versions of browser-specific pages or controls that the runtime caches.
Consider using control adapters to help optimize generated HTML.
Consider generating CSS and JavaScript dynamically, particularly for things like browser dependencies.
Use custom user controls or control adapters to automatically assign your static files to multiple subdomains and to implement other techniques.
If you have many images that are larger on the server that the client needs them to be, consider using a dynamic image-resizing control that resizes and caches them on the server before sending the smaller files to the client.
Managing ASP.NET Application Policies
Consider using one or more HttpModules to enforce things like site-wide cookie policies, centralized monitoring and logging, custom session handling, and custom authorization and authentication.
Because HttpModules run in-line with every request, try to offload long-running tasks (such as logging to a database) onto a background worker thread when you can.
Consider using a custom HttpHandler for dynamic content that doesn't include a markup file, such as dynamic images and charts.
Use an async HttpModule or HttpHandler if your code needs to access the database or do any other I/O.
Create a page base class, and use it with all your pages.
Disalbe AutoEventWireup in the Page directive, and override the OnLoad() style methods instead of using the default Page_Load() style.
Identify client requests that are page refreshes, and limit or minimize the processing to create a new page when appropriate.
Consider using programmatic URL rewriting to help shorten the URLs of your dynamic content.
Minimize the use of redirects. Use Server.Transfer() instead when you can.
When you use redirects, be sure to end page processing after issuing the redirect.
Regularly review the HTTP requests and responses that your pages make, using the Fiddler web proxy debugger.
For pages with long-running tasks and where Ajax wouldn't be appropriates, consider flushing the response buffer early to help improve perceived page-load time.
Use whitespace filtering to minimize the size of your HTML (although you must disable dynamticCompressionBeforeCache if you do).
Check Page.IsPostBack to see whether you can avoid repeating work that is already reflected on the page or stored in ViewState.
Before performing any time-consuming operations on a page, check the Response.IsClientConnected flag to make sure the client still has an active network connection.
Disable debug mode for the version of your site that runs in production.
SQL Server Relational Database
Make sure your database data and log files are on separate disks from one another.
To increase database write performance, add more spindles to your log volumes.
Optimize your volumes for read performance (IOPS) by adding more spindles.
Make sure your have enough RAM, and add more if you don't(helps improve read performance).
Use stored procedures as your primary interface to the database.
Use dynamic SQL, triggers, or cursors only when there is no other way to solve a particular problem.
When you have to use dynamic SQL, always use it with parameterized queries.
Structure your stored procedures to help minimize database round-trips.
Use command batching, table-valued parameters, and multiple result sets to help minimize database round-trips.
Group multiple INSERT, UPDATE, and DELETE operations into transactions to help minimize database log I/O pressure.
If you can anticipate the next database-related action a user will take, consider using a background thread to issue a query that precaches the data you need at the database tier.
Optimize the data types you choose for your table; prefer narrow, always increasing keys to wide or randomly orders ones.
Optimize the indexes for your tables, including clustered vs. noclustered indexes and including extra columns to allow the indexes to cover queries.
Try to structure your queries and indexes to avoid table and index scans.
Make frequent use of SQL Profile to observe the activity on your database, including the queries that your application is issuing and how long they take to run.
To prevent deadlocks, ensure that you access lockable database objects consistently in the same order.
Use SET NOCOUNT ON at the top of your stored procedures, except in cases where the results are associated with SqlDependency.
Use data paging to help limit rows displayed on a page to a reasonable number.
Due to its support for native async commands, command batching, multiple result sets, and table-valued parameters, you should prefer ADO.NET to ORM systems such LINQ to SQL and the Entity Framework or Nhibernate, particularly for large projects.
ORM systems maybe acceptable for LG-1 or LG-2 sites or for rapid prototyping that won’t evolve into production code.
Consider using XML columns as an alternative to having many sparse columns when you have properties that are difficult to represent in relational form, when you have XML documents that you need to query, as an alternative to adding new columns dynamically to your tables, or as an alternative to many-to-many mappings.
Avoid using wildcards in your XML queries.
For sites that require consistent performance and 24*7 uptime, consider using table partitioning to ease ongoing maintenance issues; doing so requires SQL Server Enterprise.
Prefer full-text search to wildcard searches using the T_SQL LIKE clause.
Enable Service Broker in your database.
Use Service Broker to offload or time-shift long-running tasks to a background thread(LG-1 to LG-3) or to Windows Service(LG-3+).
Use Service Broker to queue requests to send e-mails, rather than sending them in-line.
Associate SqlDependency or SqlCacheDependency objects with database queries that return cacheable results (requires Service Broker).
Use Resource Governor to help maintain the relative priorities of certain types of database traffic, such as low-priority logging compared to your VIP users or purchase transactions; this requires SQL Server Enterprise(LG-5+).
Prefer scaling up your database servers first, before scaling out.
For read-heavy workloads, consider using several load-balanced read-only database servers (LG-6+).
Monitor the relevant Windows and SQL Server performance counters to help identify bottlenecks early and for long-term trend analysis and capacity planning.
Be sure to take into account the time for a failover to happen when designing your high-availability architecture. Prefer clustering when a fail-over time of 30 seconds or more is acceptable, and prefer mirroring when a shorter time is required(LG-5+).
Set a large enough file size for your database data and log files that they should never have to autogrow.
Don't shrink or autoshrink your database files.
Minimize the number of different databases you need.
Consider SQL CLR for functions, types, or stored procedures that contain a large amount of procedural code or to share constants or code between your web and data tiers.
SQL Server Analysis Services
Avoid using the relational database for aggregation queries such as sums and counts; whenever possible, use SSAS for that instead (LG-2+).
Download and install ADOMD.NET so that you can query your cubes from your web site (LG-2+).
Use SSMS to test your MDX queries.
Use both Visual Studio and Excel to peruse your cube and to make sure the data is organized as you intended.
As with relational queries, be sure to cache the results of MDX queries when it makes sense to do so. Keep in mind that cubes are updated less often than your tables.
For sites with SQL Server Standard, use SSIS and SQL Agent to automate the process of updating your cubes (LG-2+).
For sites with SQL Server Enterprise, configure proactive caching to update your cubes when the relational data changes (LG-5+).
Consider using a staging database in between your OLTP database and SSAS. Populate the staging database with SSIS, and allow it to be used for certain types of read-only queries (LG-6+).
Infrastructure and Operations
Use custom performance counters to instrument and monitor your application.
Minimize the different types of web and application servers that you use in your production environment. If necessary, use WSRM to help balance the load among different AppPools.
Test your servers to determine how they behave under heavy load, including determining their maximum CPU use. Use that information in your capacity planning analysis.
Optimize your disk subsystem by using disks with a high rotation speed, narrow partitions, an appropriate RAID type, matching controller capacities with the achievable throughput, having enough drives, using a battery-backed write cache, and so on.
Minimize NTFS fragmentation by putting your database files on fresh filesystems by themselves.
For filesystems where you add and delete files regularly, periodically run a disk or file defragmentation tool and use a cluster size that reflects your average file size.
Prefer SAS or SCSI drives to SATA when maximizing throughput or data reliability are important.
Keep an eye on SSD technology; SSDs are much faster than rotating disks and may soon be stable enough to deploy in production environments.
Consider using a SAN in environments where building and maintaining your own disk arrays isn't practical, or where data reliability is paramount.
Use a high-speed back-end network: at least 1Gbps, and 10Gbps if you can (LG-3+).
Configure the network from your database servers to the local switch to use link aggregation (LACP)(LG-4+).
Enable Windows Firewall on all your servers.
For LG-1 to LG-3 sites where users can upload files onto your web server, consider using server-side antivirus software as an alternative to a hardware firewall (LG-4+ sites shouldn't store any upload files on the web servers).
If you have access to your router, configure it to do port filtering and to protect against things like SYN floods and other DDOS attacks (LG-4+).
For sites with up to eight web servers, consider using NLB for load balancing. For more than eight servers, use a hardware load balancer (LG-4+).
Consider running your own DNS server or subscribing to a commercial service that provides high-speed DNS.
Prefer DNS A records to CNAME records whenever possible.
If you aren't using DNS as part of a failover scheme (LG-7),set your default TTL to around 24 hours.
Establish staging environments for testing both in development and in preproduction.
Establish a deployment procedure that allows you to complete deployments quickly. It may be manual for smaller sites or automated using WDS for larger sites.
Establish a procedure for upgrading your data tier.
Deploy your web site in precompiled form.
Warm up the cache after a restart on both your web and database servers.
Consider deploying a system to monitor your servers proactively, such as System Center Operations Manager (LG-4+).
League Definitions
LG-1 Shared hosting. You don’t have direct control of the server, and you share it with other sites.
LG-2 Dedicated server, single machine. You have full control over the server. The web site, database, and optionally SSAS run on the same machine, possibly along with other applications.
LG-3 Two servers. Your web site runs on one, and your database and SSAS run on the other.
LG-4 Two or more web servers, with one database server. The web servers run in a load-balanced configuration, using either NLB or a hardware load balancer.
LG-5 Two or more web servers, with one high-availability database, using either clustering or mirroring.
LG-6 Two or more web servers, with multiple partitioned databases, some or all of which are highly available. The partitioned databases may include support for things like logging or read-only databases.
LG-7 Two or more web servers, with multiple partitioned high-availability databases and multiple physical locations that you manage. The multiple locations may be for disaster failover, global load balancing, and so on.