Ask a questionAsk a question
 

QuestionProfiling an application

  • Friday, October 23, 2009 9:03 PMmarkoueis Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    I have a .NET windows service that does a lot of network magic (WMI, Ping, etc - the list is very long). I would like to profile, with as much ease and detail as possible, how much bandwidth the application uses in total as well each part in the code. I was pointed to microsoft network monitor.

    The first big blow was that using the API or the nmcap, you cannot monitor by process. I worked arround that by trying to list the protocols that my app uses. The second problem i've hit is a performance problem. Whether i use the API or nmcap, after about half an hour of monitoring network monitor falls about 10 min behind in the parsing and has parsed arround 15 thousand frames. If i use nmcap, i then i have to reparse the file which seems to take just as much time (so if i profile for 10 hours I need 10 hours to get through the parsing). If i use the API so I just parse once, after running it for 4 hours it crashes (i guess it might be something in my code).

    Is there any way to reduce the time it takes to parse? I'd be willing to sacrifice the infomration I get for performance. I'm only after a few tidbits of information, i think network monitor might be doing too much

All Replies

  • Tuesday, October 27, 2009 5:14 PMPaul E LongMSFT, OwnerUsers MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    One way around teh process monitoring is that you can do it your self by calling the APIs directly to determine the ports a process is using.  To start with look at http://msdn.microsoft.com/en-us/library/aa365928(VS.85).aspx.

    As for performance, any filtering you do will affect performance.  You will get the fastest performance with no filtering.  In a live capturing scenario this is important so you don't lose frames.  If you are not dropping frames, which actually can only be indicated by NMCap and the UI, then you don't gain anything by doing the filtering later as you mentioned above.

    You can increase the performance of filtering by narrowing down the parser set you use.  So for instance, if you only need TCP to be parsed, you could remove all other referneces in TCP to upper level protocols.  This will increase your parsing speed, but obvoiusly there is a limit based on your CPUs throughput and load.  To perform this protocol "pruning" you'll have to experiement to find a parser set that compiles with out errors.  But if you need help here, let us know.

    Paul