|
> -----Original Message----- > From: Leif Svalgaard > > > I think I've restated my position adequately... C/S and monolithic > > applications are "roughly equivalent", but servers have > opportunities for > > performance enhancements not available to monolithic techniques. > > you COULD do similar things (caching of small tables) in a monolithic > program. 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. In the specific example of caching a table, caching only makes sense when you have many requests. To cache a table for a single request from a monolithic program makes no sense, and in fact adds overhead, whereas caching in a server that supports multiple clients reduces overhead. And even in the case where a single client makes multiple requests, the initialization of the cache is a real amount of work that is duplicated for every client and not duplicated for the server. No matter how much caching will help a single client, it will help multiple clients more. This is indisputable if you take the time to reason it through. This is simple systems design, and I'm surprised you're arguing about it. I suppose I could be wrong, but unless somebody has designed an instruction with negative CPU cycles, servers always provide a performance benefit, at least in initialization overhead. If the initialization overhead is larger than the overhead of the messaging API, the server design is more efficient than a non-server design. If you wish to continue arguing this very basic design point, fine, but please use a real example and explain it. I really don't think simple "COULD do" responses help the discussion, especially when they are factually inaccurate. > remove MORE (especially CAPITALIZED) as well and we agree. The > benefits are > not efficiency, but a host of other things, and they are real. One of the > most important is > that it makes it a lot easier to get off the platform. :-) 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. Joe Pluta www.plutabrothers.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.