Let’s say you get 1000 hits per second on your website’s home page, you want user to feel that the site is as real time as possible without overloading your database. These hits on your site display some data from the database and are mostly reads; for every 10 reads there is one write.

Yes you can cache it for 1 minute and the database won’t be hit that much. By doing this it will look like your site doesn’t update so often. Now what will happen if you do a 1 second cache? You will eliminate most of the reads and your site will still look like it is updating real time. If a user hits F5/CTRL + R every couple of seconds he will see new content. Does this make sense? I am interested in your opinion.

[edit]I am talking about database results caching here. For example take a page like the new submission page on digg, a lot of stuff gets submitted every second, a lot more gets read of course. If you cache this for one second you eliminate a lot of the reads[/edit]

If you have done windows forms development in the past and now you are using Windows Presentation Foundation, then you cannot help but notice that Windows Presentation Foundation uses more resources.

This is why you need Performance Profiling Tools for WPF. Below is a list of 5 five performance profiling tools that are included in the Windows SDK tool, WPFPerf:

Perforator
Use for analyzing rendering behavior.

Visual Profiler
Use for profiling the use of WPF services, such as layout and event handling, by elements in the visual tree.

Working Set Analyzer
Use for analyzing the working set characteristics of your application.

Event Trace
Use for analyzing events and generating event log files.

ETW Trace Viewer
Record, display, and browse Event Tracing for Windows (ETW) log files in a WPF user-interface format.

To get more details about these tools visit this link: http://msdn.microsoft.com/en-us/library/aa969767.aspx

Adam Machanic created an item on connect explaining how LINQ to SQL queries involving strings cause SQL Server procedure cache bloat

If an application is using LINQ to SQL and the queries involve the use of strings that can be highly variable in length, the SQL Server procedure cache will become bloated with one version of the query for every possible string length. For example, consider the following very simple queries created against the Person.AddressTypes table in the AdventureWorks2008 database:

If both of these queries are run, we will see two entries in the SQL Server procedure cache: One bound with an NVARCHAR(7), and the other with an NVARCHAR(11). Now imagine if there were hundreds or thousands of different input strings, all with different lengths. The procedure cache would become unnecessarily filled with all sorts of different plans for the exact same query. Even worse, imagine if a query used two or three different string parameters. The procedure cache could end up with hundreds of thousands or even millions of entries, the only differences being the variable lengths

Wow that is bad indeed, please go to the connect site and vote for this so that Microsoft ‘fixes’ this. Here is the URL: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Dinesh wrote a blogpost about .NET Framework 3.5 SP1: LINQ perf improvements (LINQ to Objects and LINQ to SQL). There are three perf improvements in the just released SP1

Specialized enumerable: The new implementation recognizes queries that apply Where and/or Select to arrays or List<T>s and fold pipelines of multiple enumerable objects into single specialized enumerables. This produces substantial improvement in base overhead of common LINQ to Objects queries (at times 30+%).

Make sure to check it out!