The JustTrace performance and memory profiler has always been a developer tool, aiming to help create the best products possible. That's why we seamlessly integrate with Visual Studio and have our high level analyses. But when our colleagues who develop telerik.com came to us seeking help with finding why the site was leaking memory, we realized we can do more. Sometimes performance issues arise on production servers and must be fixed quickly without disrupting the clients.
Inevitably though, sysadmins are reluctant to install a "developer tool" on production machine and we can't blame them for their reservation.
To adress this issue, we created a small separate tool which requires no installation and disrupts the target process as little as possible. It ships with the JustTrace profiler and you can find it in "C:\Program Files (x86)\Telerik\JustTrace\Libraries\JustTraceCreateDumpFile.exe". To use it, simply copy the file to your server and start it. Select the process you want to examine, press “Get Dump” and wait. When the process completes, you can move the snapshot to your developer machine, import it in JustTrace and search for the problem.
To achieve this, we do not use true profiling. Instead, we use the debugger and create a memory dump of the target process. This approach disrupts the process very briefly by suspending it only while we gather the data. After that the program continues working at its normal pace, as there is no attached profiler that could decrease the performance.
The downsides are two. The major one is that we have limited data to run all of our automated analyses. Fortunately, they are sufficient to allow you to find the problem manually.
The other downside is that importing the memory snapshot is a complex (and slower than usual) operation which runs synchronously and must finish before you can access the data.
Despite the limitations, this is a powerful tool which has already proven itself both inside Telerik and with our customers.
As a finishing note, I must admit that our initial implementation depended on you being always connected to the Internet. We used to depend on the Microsoft public symbols servers, and we could not work when the particular pdb files are missing from it. We switched to a more resilient approach in our service pack. To do this, we had to start gathering more data and we can only import memory dumps created from the SP version of the tool.
Todor is a Senior Product Manager responsible for the high productivity tooling Kinvey Studio, part of the Kinvey Platform. Todor started his career in software development more than 20 years ago, and used multiple technologies, languages, and frameworks. He switched to Product Management and worked on various high-productivity cloud-based solutions inside Progress. A passionate video gamer and avid book reader, he mostly enjoys the quiet family nights with his family.
Subscribe to be the first to get our expert-written articles and tutorials for developers!