Inter-process communication

[Jon Davis]

Then you have asked your question incorrectly. In all of your posts, how
IIS uses memory is a central part of your complaint.

There was no complaint, but a small portrait of the background which frankly
I shouldn't have mentioned. I was sloppy about describing the background by
pronouncing a few symptomatic inferences, but it was all because I
considered it completely off-topic.

If IIS memory utilization is not the issue, then I recommend you stop ...

You wrote a lot of stuff here, but you don't get it. We have 30 or so
instances of web apps of identical codebases that are co-branded and hosted
on the same server. The memory each of those instances takes up is roughly
identical as they are using the same codebase. There is RAM enough on the
server to support dropping in a single indexing process that takes up a gig
or so. Dropping that process directly into the ASP.NET codebase will not
work, as the server will not support being multiplied by a factor of 30. We
need an isolated Windows service. None of this is any of your business. I
came here for IPC discussion. I will find another newsgroup for memory
optimization.

Jon

 

[Jon Davis]

Thanks Peter. I am grateful for the link.

I'm still not sure how significant the overhead of marshalling w/ IPC will
be but I am going to go ahead and move forward with IPC for a quick
implementation, then I might come back and refer to your article for MMF for
a possible refactoring and refinement.

But please don't take that as disregard. I'll keep this handy and it's
exactly what I asked for.

Jon

Jon,
In this article
http://www.eggheadcafe.com/articles/20050116.asp
I did some "proof of concept" work with MMF's using the MetalWrench
Toolbox
assembly, a copy of which is in the bin/debug folder of the associated
download.

It was the only one I tested that held up consistently under heavy load.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net

I see what you're saying, per your original reply. I guess I need to do
some
tests to see what impact MarshalByRef implementation, for remoting, would
have. The problem is the level of effort for MMF, which isn't native to
.NET
(or is it?).

We are performing search queries between the IIS process and the indexing
process, so the client/server model works fine for us (better, actually).
The compromise of ease of implementation w/ MarshalByRef for Ipc vs. the
performance overhead of TCP sockets might be legitimate enough to go with
IPC remoting over named pipes.

But if you can find a sample of MMF that's straightforward, obviously not
necessarily as straightforward as the link I just found and posted but
relatively readable, I'd be most grateful.

I'm really not interested at this time in pursuing the purchase of
third-party middleware. Free and open-source, maybe, but one would think
Microsoft would get this stuff to work right out of the .NET box.

Jon


in
message news:[email protected]...

Jon,

You could use that, but in the end, you have to consider how much
data
you are going to push across this pipe. MMF might be better if you
have
to access that data, but for signalling between the two applications, I
would go with remoting, or, if you can use .NET 3.0 (which is 2.0 with
some additional class libraries) then, you should use WCF.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


This looks rediculously straightforward.

http://www.developer.com/net/vb/article.php/10926_3520891_2

Erm, that's Part 2 of a two-part, rediculously straightforward
article.

http://www.developer.com/net/vb/article.php/10926_3520891_1

 

[Peter Duniho]

There was no complaint, but a small portrait of the background which
frankly I shouldn't have mentioned.

Yes, it's true. If you include extraneous things that are irrelevant to
your actual question, you will find it very difficult to get helpful
answers.

You wrote a lot of stuff here, but you don't get it.

All of what I wrote was intended to help you understand better the memory
management model in use, something you clearly don't currently
understand. If you don't find it helpful, I suppose that's your
prerogative. But make no mistake: you don't understand the memory
management model.

[...] We
need an isolated Windows service. None of this is any of your business.

Not "my business"? Why so hostile? You are the one who brought up the
memory management issues, and all I was trying to do was help you
understand them better so that you don't waste time working on a solution
that doesn't actually solve your problem.

You may also want to review the bromide about not biting the hand that
feeds you.

Pete

 

[Jon Davis]

Yes, it's true. If you include extraneous things that are irrelevant to
your actual question, you will find it very difficult to get helpful
answers.

On the contrary, I got some incredibly helpful information from one who
answered my question rather than questioned the question.

Jon

 

[Jon Davis]

On Fri, 06 Apr 2007 11:22:23 -0700, Jon Davis

All of what I wrote was intended to help you understand better the memory
management model in use, something you clearly don't currently
understand. But make no mistake: you don't understand the memory
management model.
..
Why so hostile?

You're smart. I have no doubt you can figure this one out.

Jon

 

[Willy Denoyette [MVP]]

Of course; all instances of "IIS" mentioned in this thread are short-form references the
ASP.NET app we are executing.


IIS "self-tunes" itself and avoids taking up more than roughly one quarter of the
available physical RAM, which is far less than standalone process will allow for. We have
seen OutOfMemoryExceptions frequently by stepping above this threshhold, despite at least
a gig of available physical RAM. This does not work well for a dedicated web host machine.

Once again, IIS and ASP.NET run in different processes InetInfo.exe and w3wp.exe (one per
application pool) respectively on W2K3.
IIS doesn't control the memory reserved by asp.net worker processes, this is done through
the web.config files or the IIS metabase, depending on the version of IIS you are running.
IIS5.1 uses the Web.Config "ProcessModel" section which contains a "memoryLimit" entry
defining the amount of memory that can be allocated before the process recycles (after
throwing an OOM). IIS6 Worker processes don't use the ProcessModel from the config files,
instead the process model is configured through the "aspnet_isapi.dll", when running IIS6 in
native mode, configuration of the processModel for the worker processes must be done through
the IIS Manager User Interface, or programmatically via WMI.

Of course, we can look at experimenting more with 64-bit machines that have gobs of RAM
and see what a quarter of 8GB (2GB) would do for us, but that's not the point. The point
is I am looking in parallel at IPC and that's what this thread is for.

There is no such thing as a quarter of..., the problem is that description of the
"memoryLimit", which really is the max. amount of per process Virtual Memory to be used,
when running on 32 bit, the process limit is 2GB, with a default is 60% for "memoryLimit",
this amounts to 1.2GB. But be aware that when allocating even much less than 1GB in one
chunk, you can get OOM's because there is no such amount of contiguous space available!
When running on 64bit, the Virtual memory size is 8TB, the "memoryLimit" is no longer
expressed in %, instead you have to specify the amount of memory in KB (same for IIS7).

Willy.

 

[Peter Duniho]

You're smart. I have no doubt you can figure this one out.

Nope. I honestly can't. Your hostility is bewildering to me, since all I
was trying to do is help you.

I certainly won't make that mistake again.

 

[Jon Davis]

Nope. I honestly can't. Your hostility is bewildering to me, since all I
was trying to do is help you.

Shame that I have to spell it out for you.

1) You remain off-topic, and insist on questioning the question, which is
not helpful. I know that you think you are helpful, but you're stepping on
toes where you were not invited.

2) You're incessantly condescending. You beat people down and spell out in
detail that they are ignorant. For a hard-working software professional,
that's essentially calling them stupid. You lack tact. The fact that you
cannot see it is itself reason enough to want to avoid you and be abrasive.

3) You quote me out of context. Cases in point: In my post, the URL to the
IIS memory management matter was with regard to the phrase "self-tunes", but
to the phrase "one quarter of the available RAM" I specifically answered
"No". Yet you quoted me referencing the URL and said that the URL does not
talk about IIS using one quarter of available RAM and used that against my
point. Or, case in point, in this post you snipped out the answer to the
question, "Why so hostile?"; the answer was because "all of what [you] wrote
was intended to ["help"] me understand better the memory management model in
use, something [you] insist don't understand. That sort of "help" was
not asked for. And of course you would think I don't understand it, because
I'm not explaining my understanding of it, because I'm not putting thought
to it right now, because I am *focused* on IPC!!!

Jon

 

[Jon Davis]

BTW just a word of advice. If you really feel strongly that the details of a
matter is based on an incorrect premise, focus solely on the premise ("that
is incorrect"). Don't dwell on the human being who holds the premise ("you
clearly don't know what you're doing").

Willy Denoyette's replies have been very helpful, btw. He seemed to figure
this one out.

Jon