Showing posts with label Performance. Show all posts
Showing posts with label Performance. Show all posts

Friday, May 01, 2009

Tuesday, October 14, 2008

* .NET 4.0 will introduce Parallel programming framework

As part of Parallel Computing Initiative, Microsoft recently launched the CTPs of Parallel Extension to .NET framework.

This allows developers to express parallelism in their code to harness the full power of multi-processor and multi-core systems.

with .NET 4.0 and VS 2010, parallel programming framework will be core part of .NET framework.

Read more about Parallel Programming Framework

Read more about What’s New in .NET 4.0 , What’s new in Visual Studio 2010.

Wednesday, June 04, 2008

* Announcing Project Codename 'Velocity'

Microsoft's Project “Velocity” is a distributed in-memory application cache platform for developing scalable, available, and high-performance applications. “Velocity” fuses memory across multiple computers to give a single unified cache view to applications.

Will be ideal for following kind of applications :

  • There is a considerable number of data requests that are mostly read (e.g. product catalogs)
  • Applications that can tolerate some staleness of data
  • Applications that can work with highly partitioned data (e.g. session data, shopping cart)
  • Applications that can work well with eventual consistency

Very true, Its very important that such kind of caching platforms like Enterprise Library Caching Block & Velocity are used after analyzing the requirements of application else you may get all the negative effects while expecting positive ones.

Hope to see EntLib Caching Block integrated with Velocity soon.

Velocity Home Page

Wednesday, May 02, 2007

* Tool : VSProfiler - Analyze Performance of Managed Code

While Visual Studio 2005 has an integrated add-in for profiling managed code, VSProfiler is a stand-alone profiler for managed code.

It can be used to profile production systems or machines where Visual Studio can't be installed.

VSProfiler - vs_profiler.exe can be found on Visual Studio installation disc in wcu\profiler folder.

Executing the vs_profiler.exe installs required tools in Visual Studio installation folder like :

D:\Program Files\Microsoft Visual Studio 8\Team Tools\Performance Tools

VSProfiler supports two kinds of profiling :

  1. Sampling : Where the profiled application is analyzed and data is captured at fixed intervals e.g. after every 5 seconds performance data like CPU usage, memory usage, call graph, etc is gathered.
  2. Instrumentation/Trace : Application is profiled continuously through out the application lifetime. This is definitely more accurate but slows down the application performance during profiling and the size of output data is generally huge.

In this post i will demonstrate the steps to profile pre-built assemblies of asp.net web application using instrumentation.

  • Run VSPerfCLREnv /globaltraceon. This will setup the environment to load profiling infrastructure. Reboot is required after this.
  • Insert the instrumentation code in each of the assemblies you want to profile. Use the following command :

vsinstr <assembly name>    Make sure use the debug build for these assemblies and generate pdb files also.

  • Start the performance monitor using following command :

vsperfmon /TRACE /OUTPUT:[outputfile].vsp /USER:"[ASP.NET worker process user]"

  • An important tip here .. make sure the worker process is already not started else it won't get registered with profiler and no data will be collected.
  • Start using your web application. You will see a message on profiler windows regarding registration of worker process.
  • Once you are through with application navigation, start another command window and execute the following commands:

iisreset /stop

vsperfcmd -SHUTDOWN

  • A vsp file is created which contains all the data for analysis. While Visual Studio is required to view vsp file, following command generates two csv files using vsp file *Header.csv and Function_summary.csv which can be used for analysis without Visual Studio.

vsperfreport [outputfile].vsp /SUMMARY:FUNCTION /PACKSYMBOLS

  • Opening vsp file in VS2005 you will be able to see following :
    • Performance Report Summary showing Most called functions, Functions with most individual work, Functions taking longest.
    • How the various functions performed.
    • functions call graphs.
  • If you are through with profiling make sure to reset the environment for switching off profiling infrastructure by executing following command :

VSPerfCLREnv /globaloff

Reboot is required after this.

Other Posts

Wednesday, April 25, 2007

* Tool : CLRProfiler for .NET 2.0 released

CLR team at Microsoft has released the new version of CLRProfiler for .NET 2.0.

It can be downloaded from following location.

CLRProfiler is mainly used to study the memory usage behavior of managed applications.

Some of the graphs available as an output are :

  • Allocation Graph
  • Assembly Graph
  • Function Graph
  • Class Graph
  • Call Graph

Its an excellent tool for detecting memory leaks in managed code.

Other Posts

Tuesday, April 17, 2007

* Performance Analysis/Tuning of ASP.NET Application

These days I am working on analyzing and tuning an asp.net web application.

Its basically a n-tier application based on Front-Controller pattern and very similar to MVC pattern. The communication between web and app tier is using Remoting, where the remote components are hosted on IIS 6.0. Its a session aware application. I am trying various deployment options available and publish the results around next week. I am sure results will guide readers in deciding the deployment scenarios.

Some of the comparison I will be publishing are :

  • Debug & Release Builds
  • InProc & State Server
  • Remoting & No Remoting

Apart from this I will also publish a tutorial about an excellent tool called VSProfiler used for analyzing performance of .NET applications.

Other Posts

Tuesday, April 10, 2007

* Auto Performance Tuning in ASP.NET 2.0

With ASP.NET 2.0, the process model (processModel) section of machine.config comes with default value of autoconfig="true".

This means that the tuning parameters will be set automatically by ASP.NET engine based on machine configuration.

The parameters considered for auto tuning are :

  • The maxWorkerThreads attribute.

  • The maxIoThreads attribute.

  • The minFreeThreads attribute of the httpRuntime element.

  • The minLocalRequestFreeThreads attribute of the httpRuntime element.

  • The maxConnection attribute of the <connectionManagement> Element (Network Settings) element.

    Their values are determined based on logic mentioned at following link.

    Other Posts

  • How to create Project Item Templates
  • Accelerating development using Visual Studio Templates
  • Visual Studio : How to create temporary projects
  • Reading & Writing XML data
  • Overview of XML support in .NET Framework
  • Creating a context menu item for folders
  • Thursday, February 01, 2007

    * Debugging and Profiling .NET Applications

    Debugging or Troubleshooting an application in production environment can become nightmare if the application has not been instrumented well.

    The .NET framework namespace System.Diagnostics provides following classes : Trace, Debug, and TraceSource for tracing and debugging applications.

    The Trace and Debug classes ae identical in the functionality they provide except that Trace is part of Release build by default while Debug statements are removed from Release build.

    Before seeing Tracing into action lets understand some important components of Tracing framework.

    • Listeners : Trace output is collected by objects called listeners which redirect it to the configured device like console, flat file etc.
    • Switches : Switches allow to enable, disable or filter tracing outputs. These can be configured through the .config file. There are basically three types of switches BooleanSwitch, TraceSwitch and SourceSwitch. One of the ways to filter trace output is TraceLevel where it can have values from 0 to 4. 0 means Off and 4 means Verbose Messages.

    So all the tracing data after getting filtered using switches goes to listeners which redirect them to configured output.

    Lets look at an example now :

     

       1:  using System;
       2:  using System.Collections.Generic;
       3:  using System.Text;
       4:  using System.Diagnostics;
       5:   
       6:  namespace TracingSample
       7:  {
       8:      class Program
       9:      {
      10:          static void Main(string[] args)
      11:          {
      12:              TraceSource ts = new TraceSource("TracingSampleSource");
      13:              ts.TraceEvent(TraceEventType.Error,1,"Error message");
      14:              ts.TraceEvent(TraceEventType.Information,2,"Info Message");
      15:              ts.Flush();
      16:              ts.Close();
      17:          }
      18:      }
      19:  }






    The config file for this program looks like this :



     

    <configuration>
    <system.diagnostics>
    <sources>
    <source name="TracingSampleSource"
    switchName="sourceSwitch"
    switchType="System.Diagnostics.SourceSwitch">
    <listeners>
    <add name="myListener"/>
    <add name="console" type="System.Diagnostics.ConsoleTraceListener" />

    </listeners>
    </source>
    </sources>
    <switches>
    <add name="sourceSwitch" value="Information"/>
    </switches>
    <sharedListeners>
    <add name="myListener"
    type="System.Diagnostics.TextWriterTraceListener"
    initializeData="myListener.log">
    <filter type="System.Diagnostics.EventTypeFilter"
    initializeData="Error"/>
    </add>
    </sharedListeners>
    </system.diagnostics>
    </configuration>






     



    The code usage is fairly simple, create an instance of TraceSource, logged two events using it where one is of Error type while other of Info type.



    Its the configuration ability which makes this framework so powerful. The source has been configured to send messages to two listeners 'myListener' which redirects the messages to a log file called myListener.log and console. At source level the messages have been filtered using sourceSwitch switch while at listener level it has been configured for Error messages only.



    The outputs of the two listeners are as follows :



    Log File



    TracingSampleSource Error: 1 : Error message



    Console output :



    TracingSampleSource Error: 1 : Error message
    TracingSampleSource Information: 2 : Info Message



    Other Posts



     

    Friday, December 22, 2006

    * Microsoft.net - Automatic Memory Management

    This post tells all about Garbage Collection in Microsoft.net in points :

    1. Memory management in .NET is automatic which means developer doesn't need to worry about allocation/de-allocation or when to free memory. All this is taken care by Common Language Runtime using a process call Garbage Collector (GC).

    2. All memory requirements are served from a managed heap.

    3. Whenever a new process starts, runtime reserves a contiguous memory space for that process which becomes managed heap for that process.

    4. All the memory requirements for the process are served from this heap.

    5. Whenever there is no more free memory in the heap, the Garbage Collector becomes active and starts scanning the objects in heap which are no more in use.

    6. All the objects are by default created in Generation 0 and if on first GC they are not available for collection, they are promoted to Generation 1. Maximum any object can go upto Generation 2.

    7. As the new objects are more probable candidates for collection than older objects, GC always first scans Generation 0 objects only.

    8. If the object has Finalize() method, it is called before getting collected. Collection of such objects is managed using data structures called Finalization Queue & Freachable Queue.

    9. To optimize memory usage, .NET provides weak references which can be used to free up large memory objects temporarily.

     

    Friday, December 15, 2006

    * Dynamic Binding : Performance Optimization Tip

    Here is a tip to optimize your dynamic binding involving Assembly.Load.

    Instead of executing Assembly.Load every everytime in the loop, if Assembly is loaded globally once and reference is used thereafter there is a huge performance gain.

    The new time taken is 2 min 10 sec for test in my previous post.

    Thursday, December 14, 2006

    * Dynamic Binding : Performance

    All of us know the power of late binding or dynamic binding.

    Using this feature of .NET we can load any assembly at runtime and create an instance of a type in that assembly at runtime.

    Some of the commonly used APIs used for this task are :

    Assembly.Load

    Type.InvokeMember

    Today i decided to see the performance impact of dynamic binding and the results which i got are really scary.

    Here are the test details :

    Created an class library with following code:

    namespace VikasGoyal
    {
    public class MathLibrary
    {
    public double increment(double value)
    {
    return value + 1;
    }
    }
    }






    A simple class with a method which increments the input value by 1 and returns the incremented value.



    Created a console application which creates instance of MathLibrary and calls increment method in a for loop. The loop count is 9,000,000.



    The console application utilizes library in three different ways :



    1. Static linking



    MathLibrary was added as a reference, instance created and method called.





    VikasGoyal.MathLibrary ml = new VikasGoyal.MathLibrary();
    value = ml.increment(value);

    2. Creating type dynamically

    MathLibrary was added as a reference but type instance created dynamically.

    className = typeof(VikasGoyal.MathLibrary);



    System.Object target = Activator.CreateInstance(className);
    value = (double)className.InvokeMember("increment", System.Reflection.BindingFlags.InvokeMethod, null, target, new object[] { value });



    3. Assembly Loaded dynamically

    No reference of MathLibrary was added at build time to Console application.

    Library was loaded at runtime and instances created at runtime



    Assembly asm = Assembly.Load("MathLibrary");
    className = asm.GetType("VikasGoyal.MathLibrary");

    Following is time taken to complete the above mentioned loops by various methods:

    1. Static Linking : 0.38 secs

    2. Creating type dynamically : 47.7 secs

    3. Assembly Loaded dynamically : 6 min 10 sec.

    The performance difference seems to be huge. Multiple tests were done to ensure consistency of results.

    Soon i will publish the results with asp.net as calling application to verify if asp.net does some optimizations for assembly loading.


    Other Posts


    Tuesday, December 12, 2006

    * Visual Studio Performance Wizard

    While looking for some alternatives to VTune from Intel, I came to know that Visual Studio 2005 Team system comes with a built in Performance Wizard where any type of managed code like standalone application or web application etc. can be profiled.

    The Performance Wizard can be accessed using following path in Visual Studio:

    Tools -> Performance Tools -> Performance Wizard.

    This wizard provides two types of profiling :

    1. Sampling : Where the target application is profiles at various events/intervals. The state of the application is recorded at that moment and report is generated out of it. This is a quick way of profiling application. The main output is memory related where report gives information about object instances and memory utilized with some information on call flow.

    2. Instrumentation : This is more exhaustive profiling where the application state is recorded right from start till end. This is more useful for determining the complete call flows and the execution times of methods.