LabVIEW Shared DLL when used with ASP.Net spikes Memory of Worker Process on IIS

[jprucha]

Hi All,

I am currently on a development team that has developed a web application using ASP.Net (C#) that will call a LabVIEW (v7.1) Shared DLL. This shared dll takes in a string and returns a string. What we are seeing is that when the worker process kicks off the call to the LabVIEW dll the Memory usage of the IIS worker process spikes (about 80MB) and then doesn't let go of the memory. With each subsequent call the worker process memory does go up but just by small increments of about 100KB.

Is this the expected behavior with a shared dll called through IIS? When the LabVIEW application is run through the LabVIEW IDE we only see the small increment of memory (about 100KB). Does the worker process keep the DLL in memory for future calls? Is that possibly the reason for the worker process to keep the memory? Could it be that the LabVIEW application isn't freeing the memory correctly? Is there a way to correctly free all the memory used by the shared dll?

Thanks in advance for any insite into this matter,

Jim

[Ankita]

Hi,

The easiest way to test if the worker process keeps the DLL in memory for future calls, is to create a very simple LabVIEW dll(lets say the dll adds two numbers) and call it from C#. You can now monitor the memory usage for C# application while calling the LV dll. This would tell you if the memory spike is due to the particular dll in question or due to the way worker process handles labVIEW DLLs.

Ankita