How is memory used when calling a .NET assembly from an ASP.NET web application, and how it is related to bandwidth?

Question

My web application needs to call a .NET assembly which seems to me that allocates "a lot" of memory for a web application (perhaps I'm wrong, that's why I'm asking).

I already call this assembly from my desktop application and, with the help of Task Manager, I realize that it consumes about 60MB when it runs (it is fast though: it takes less that 0.1 seconds to do the job).

What I need to know is what is going to happen, in terms of memory, bandwidth, or anything else you can come up, if, for example, 10 or 100 users use my web application at the same time. The needed memory will be 60MB x (Number of Users)? And what about the bandwidth?

If you can think of more issues, please give a hint how should I treat this problem.

Answer 1

Seriously, there is no real way of arbitrarily calculating just how much impact one added user will have to your application.

For example, while your initial app load will use 60MB of memory, each new user might use as little as 10KB additional memory (containing only his user credentials) -- the rest of the application data will already be loaded or cached. It might be higher however -- that will depend on the behavior of your application.

You should objectively measure just how much memory and bandwidth per user will be used by your application by using load testing tools that would measure your bandwidth and memory usage while simulating an increased number of users for your application.

Some tools that you can look at are:

• Ants Profiler
• dotTrace Profiler
• Badboy

There are a lot more out there but these are what I have used for these kinds of measurements in the past.

Answer 2

Bandwidth is unrelated to memory consumption.

The question is whether this assembly works properly in a service environment. Is it written to assume that only one user is using it, or does it recognize there may be many users, on many threads, accessing it? Even if it handles the service environment properly, maybe some of its normal operation would involve more memory per-user.

The final answer is: test it and find out!

Answer 3

Part of the allocated memory is related to the code of the assembly and a part is related to the data structures created by this assembly.

In your Web app, you will incur the cost of the assembly code once only (like in the desktop or any other case). For the data structures part, it will depend on your own usage. If you create a new instance of the assembly classes for each user, you will incur the memory cost for each user. If the code of this assembly has no side effect, you could share the needed instance and incur the memory cost only once.

So, the answer is: it depends. This assembly may also use shared structures, so even instantiating it several times will not be equivalent to n times the cost of one instantiation.

Answer 4

The memory allocated by using this assembly will be used on the server. It will not be sent over the web to your end users so bandwidth should not be used. For bandwidth to be used data has to be sent over a network. So, only if you serialize the data structures and send them to the client (perhaps as JSON objects) will it lead to your web users incurring extra bandwidth. Any other data transfer over the internet that the assembly makes will impact your bandwidth usage.

Answer 5

Some food for thought:

1) Task Manager is not an accurate way of measuring the memory usage (for example see http://www.itwriting.com/dotnetmem.php)

2) Some of that memory is probably allocated for static or initialization-time data, which is only held in a single copy regardless of how many users are accessing the component.

3) Some of that memory is allocated per-request, meaning it will grow linearly with the # of users using the component.

4) Bandwidth is unrelated to memory usage.

The KEY question you need to answer is "was the component designed for running in an ASP.NET web environment"? This actually includes two separate but related issues:

• If the component wasn't designed to run in a multithreaded (if you aren't familiar with that term then substitute "multi-user") environment then it will probably die horribly as soon as more than a few users share it.

• If it hasn't been tested under ASP.NET (particularly under load) then there is a fair chance that it won't play nicely with the rest of your web app. If possible, try to find which IIS and ASP.NET configurations are officially supported and make sure that it fits your requirements.

I would recommend doing the following:

A) Read the documentation to see whether it is multi-threaded and officially supports ASP.NET

B) TEST IT AND SEE FOR YOURSELF. Create a simple test web application and stress it using a load tool.