Archive for category Performance
If broken it is, fix it you should
Posted by Martin in Development, Performance on February 24, 2010
A while ago I was looking for an easy way to explain developers how to find and fix memory leaks. During my research I’ve found this really interesting blog by a Microsoft Engineer, Tess Ferrandez.
She is constantly posting new tips and guides on .NET development and troubleshooting. I really like the “.NET Debugging Labs”, step by step guides on how to fix common issues, such as Memory Leaks, CPU Hangs, Crashes and so on.
If broken it is, fix it you should:
http://blogs.msdn.com/tess/
How To Convert a Windows Performance Monitor (PerfMon) Log
Posted by Martin in Performance on February 22, 2010
This is a very useful tip if you use PerfMon logs to monitor your applications. In my case, I have a few tools that require the logs to be in binary format and I also like to analyze a few counters manually, opening the logs on Excel. Converting the logs, I can set up only one set of counters and then convert it later.
It is also useful if you can’t set up the counters and have to work with previously generated logs or logs provided by a third party.
Windows 2003 and XP provide a number of command-line tools to monitor performance. These are the logman utility (logman.exe), the relog utility (relog.exe), and the typeperf utility (typeperf.exe).
The relog.exe utility can create new performance logs from existing performance logs. You can use the Relog.exe tool to:
- Convert a log from one type to another, such as a Microsoft Windows NT 4.0 log to a Windows XP log, or a binary log file (.blg) to a comma-separated values (.csv) file.
- Resample a log file, and then create a new log file that is based on specified counters, a time period, or a sampling interval.
For example, to convert a binary PerfMon log to a CSV file, use the command:
relog logfile.blg -f csv -o logfile.csv
For details on how to use relog, in a Windows XP box, run “relog -?” or review http://support.microsoft.com/?kbid=303133
Performance Measured by the Penny
Posted by Martin in Performance on February 22, 2010
Cloud computing is a game changer for developers. Not because it requires a new architectural model, that is driven as much by fads and fashion as it is by actual hardware requirements. Nor is it the seemingly endless capacity with near-perfect scalability that the cloud is promising. The game changer is how poorly performing code now has a real price in hard currency.
Since personal computers replaced time shares, performance has been a nice to have. Generally speaking, either the application performance is good enough for the hardware it is running on or it isn’t. You don’t gain anything by dropping your peak CPU utilization from 90% to 81%, expect perhaps a small discount on your electric bill.
With the cloud platform, dropping your CPU utilization by 10% directly translates to a 10% reduction of you monthly bill from your cloud provider. For example, Windows Azure costs 12 cents per machine hour of computational time. Using this knowledge and a good profiler, you could literally say a certain block of code is costing the company X dollars per month.
Once the cost of poorly performing code is know, companies can then make economically sound decisions on whether or not to spend time and money to fix it. Simply by comparing the monthly cost of the code with the salary of a developer tasked with improving it, engineering managers can say with certainty how much time can be spent before the laws of diminishing returns kick in.
The performance=money equation will also bring dynamically typed languages into sharp focus. If we have truly reached the time where dynamically typed languages are “fast enough”, then that will be reflected in the price for renting cloud servers. If, on the other hand, production costs start to skyrocket then there will be irrefutable evidence that a statically typed language is in order. But of course this will have to be decided on case-by-case and project-by-project basis.
Via InfoQ
Configuring WebLogic JMX on LoadRunner Controller
Posted by Martin in Performance on February 4, 2010
Here is a tip shared by my friend Daisy:
The WebLogic SNMP monitor is enable in the Controller as default. If you need to monitor Weblogic JMX, you have 2 options:
- Use the SiteScope as a monitoring tool instead of Controller;
- Enable the Weblogic JMX monitor into Controller.
- To do this you will have to configure online_resource_graphs.rmd file – located under <LoadRunner DIR>\dat\online_graphs: update the EnableInUi param of the relevant monitor (i.e. for WebLogic (JMX): search for the [WebLogicJMX] section and update its EnableInUi param).
- Also, you might need to install java jdk on Controller (I didn’t have chance to test it):
WebLogic Monitor Requirements and Setup
Requirements
- JDK 1.4 on controller
- Permissions on WebLogic MBeans.
Setup on Controller
- After JDK installation Copy weblogic.jar from the lib folder of WebLogic Server to LoadRunner root\classes.
- Remove jmxri.jar from LoadRunner root \classes.
- Specify the path in the LoadRunner root folder\dat\monitors\WebLogicMon.ini file. Edit the JVM entry in the [WebLogicMon] section. For example: JVM=”E:\Program Files\JavaSoft\JRE\1.4\bin\javaw.exe
- Edit the JavaVersion entry in the [WebLogicMon] section.
Set permissions on WebLogic
- Open the WebLogic console (http://<host:port>/console).
- In the tree on the left, select Security > Realms > myrealm > Users, and click Configure a new User… in the screen on the right. The Create User: General tab opens.
- In the Name box, type weblogic.admin.mbean, enter a password, confirm the password, and then click Apply.
- In the Groups tab, enter the name of any user or group you want to use for monitoring, and then click Apply.
Installing HP Diagnostics Probe for ASP.NET Applications
Posted by Martin in Performance on January 26, 2010
Another very useful tip shared by Odorico:
Installation:
- Just install the provided file, “HP .NET Probe.msi”, which is probably under the “Diagnostics_Probes” folder;
- Inform the name of server where the Diagnostic is was installed;
- Keep the other settings as default.
Remember to reset IIS to get the changes (enable/disable probe) in place:
Go to ’Start > Run’ “iisreset”
Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted
You will be able to Enable and Disable the probe in the application server. By default, after installation, probe is enabled.
If the application you intend to monitor is not detected by the Probe, or if new applications are deployed in the server, you can Rescan ASP .NET Application. A new application point will be created for any new application in the server.
Configuration:
Probe will be installed in the folder C:\MercuryDiagnostics\.NET Probe
Configuration and application points settings will be find in etc folder (C:\MercuryDiagnostics\.NET Probe\etc)
File C:\MercuryDiagnostics\.NET Probe\etc\probe_config.xml contains the main configurations. You will be able to add more detailed monitoring information by editing this file.
The main changes you should do are:
- Monitoring Heap: Add to “process enablealldomains” the tag “monitorheap=”true”“
- Monitoring IIS and memory information: Add the Iis and Lwmd file points
Example file:
<?xml version="1.0" encoding="utf-8" ?>
- <probeconfig>
<id probeid="" probegroup="Default" />
<credentials username="" password="" />
- <profiler authenticate="">
<authentication username="" password="" />
</profiler>
<diagnosticsserver url="http://localhost:2006/commander" />
<mediator host="localhost" port="2612" metricport="2006" />
<webserver start="35000" end="35100" />
<modes pro="true" />
- <instrumentation>
<logging level="" />
</instrumentation>
<lwmd enabled="true" sample="1m" autobaseline="1h" growth="10" size="10" />
- <process enablealldomains="true" name="ASP.NET" monitorheap="true">
<logging level="" />
<points file="ASP.NET.points" />
<points file="ADO.points" />
<points file="Iis.points" />
<points file="Lwmd.points" />
- <appdomain enabled="false" name="1923244809/Default">
<points file="1923244809-Default.points" />
</appdomain>
</process>
</probeconfig>
If it is necessary to add monitoring level under some specific classes and/or methods you just need to configure the <application_instance>.points file:
;[1923244809/Default]
;Uncomment and modify this section to capture calls to your business logic
;class = !Namespace_Qualifed_Class_Name_Of_Your_Code.*
;method = !.*
;signature =
;scope =
;ignoreScope =
;layer = 1923244809/Default
Fields class and method will contain the namespace for the classes and method would contain the specific methods to monitor. CAUTION: Avoid monitoring of all methods (.*). That would be very intrusive and the probe tends to impact server performance.
Profiler:
When you open the profiler (during installation it will be showed the port number the service will run) you will see the following screen:
You will also be able to know the Probe’s application port for each IIS application, by checking this information in probe_config.xml file.
<webserver start="35000" end="35200" />
The webserver start and end shows the port ranges for the probe. The first application point will be running in the port 35000, the second one in the port 35001 and so on.
In our example we have only one application installed in IIS, so we just access URL:
http://localhost:35000/profiler
Analysis:
Heap Tab
You can see the application Heap. In this example application presents a memory leak. You can see Gen 2 and Large heap increasing very fast and they are not releasing meaningful portion of memory. Even after the test has been finished, we noticed a significant portion of memory remains allocated.
A rank with the most memory consumer classes is showed. For instance String, Byte[], and Collectors, such as Dictionaries.
Collections Tab
The collectors tab shows how collections grow along the test. For the application example, we have a significant increase in collections allocated in the class CommunityServer.Controls.TagCloud.get_DataSource().
How can I save and share the reports?
You can save a monitoring snapshot by click in Snapshot button. It will be created a XML file containing all information we had collect at that time.
NOTE: Snapshots can create huge XML files. So a good practice is to compact the file before sharing it!
IMPORTANT: The probe is intrusive. It collects a lot of metrics from the application. Thus, don’t forget to disable the probe after you have finished your tests. It will be necessary to reset IIS once again.
You are currently browsing the archives for the Performance category.
