Re: Is Client/Server Dead? Conference May 15th

In article <4l469f$el@fohnix.metronet.com> neal@fohnix.metronet.com (Neal Howard) writes: >In article <DpLLyo.46s@cix.compulink.co.uk>, >Malcolm Weallans <onlinedbc@cix.compulink.co.uk> wrote: >>INFUSE will be holding a conference on May 15th entitled "Is >>Client/Server Dead?" at the Commonwealth Institute in London. All are > >I couldn't resist commenting on the whole topic of Client/Server in >general. When you think about it, the typical network will be >10Mbps ethernet, that gives you _roughly_ 1 megaBYTE per second >throughput. That's about the same I/O throughput as a typical >486DX2-66MHz PC has to it's typical single IDE hard disk. >(Actually many such PC's have a little better disk I/O throughput >than this amount). Ask yourself this question when planning a >client server database + application suite: > > Would all the database I/O that my apps will be doing under maximum >full user load be happily handled if that I/O were being done on a >typical 486 PC to it's IDE hard drive? My experience to date confirms this. I have built (and am painfully debugging/tuning) a c-s system written in Progress. Compared to host-based on the same hardware, performance sucks. One to two orders of magnitude worse. Yes, you get pretty screens. This means it takes you 10 minutes to paint a screen and a week to debug it (event-driven means users do *stupid* things) as opposed to an hour to draw (being generous) and 2 days to debug. I'd like to say the solution is X displays on a host-based system but the punters^H^H^H^H^H^H^H clients won't wear it. Brainwashed by MickySoft. About all I can suggest is pray app partitioning works and meanwhile overspecify the client h/ware. It won't help the bandwidth problem but at least it'll speed up local processing. Peter Wiley BTW, NT servers don't - compared to unix ones. IMO, anyway.