RE: CFINT: I understand it now... -- MIDRANGE-L

Leif,

I agree with you completely.  Don't know what QED is, but catch your drift.

jt


> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Leif Svalgaard
> Sent: Saturday, November 10, 2001 5:05 PM
> To: midrange-l@midrange.com
> Subject: Re: CFINT: I understand it now...
>
>
> From: Joe Pluta <joepluta@PlutaBrothers.com>
> > I was going to let this slide, but Leif, you're just not being accurate.
> > The benefit of a server over a monolithic program is in the
> fact that, when
> > servicing multiple clients, a server job stays resident and a monolithic
> > program does not, because it runs in the same job as the
> client.  I am NOT
> > talking about calling the same program over and over from the
> same job, but
> > the concept of multiple client jobs executing the same business
> logic.  By
> > definition, a monolithic program must go through initialization (such as
> > opening files, and so on) when it is called.  This initialization is
> > repeated for every client.  Such initialization is not repeated for the
> > server when it processes multiple client requests.  QED, the
> server is more
> > efficient.
> >
>
> The initialization is usually a minor part of the application and the time
> lost in a monolithic program to do this is often offset by the
> communication
> overhead in a C/S approach. By the virtue of being monolithic, a
> traditional
> application will initialize only once for a given user, who then
> may work for
> hours on end with the application. The communication cost is borne
> throughout the use of the application. What I'm saying is that the cost of
> initialization versus communication is application and usage dependent
> and thus not inherently a C/S versus monolithic issue. No QED here,
> the more accurate characterization is : "it depends".
>
> > If the initialization overhead is larger
> > than the overhead of the messaging API, the server design is
> more efficient
> > than a non-server design.
>
> and if it is smaller, then it is the other way around. Again: "it all
> depends".
>
>
> > Nope.  Won't remove more, but I'll remove the capitalization.
> It depends
> on
> > the server design as to how efficient it is, but if you apply even basic
> > server design philosophies, you can usually make a server more efficient
> > than multiple client calls.
> >
>
> "usually ... more" is better than the uncategorical "more" you had before.
>
> -------
>
> When you have the same server servicing multiple clients queuing
> theory becomes important. The worst you can do is to have a single-
> server queue. You can counter this with having multiple servers
> (maybe with dynamic creation and destruction as needed), but that
> adds complication (maybe only once as you may be able to reuse
> the code), but there is also operational complexity (locking, deadlocks,
> error handling, etc) that come into play.
>
> Again, it is not ALWAYS true that C/S is more efficient than Monolithic,
> it depends. But efficiency is not so important in face of all the other
> benefits from C/S. I would recommend a C/S solution regardless.
>
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>