Re: Throughput and storage requirements questions for modern vs old database processing apps

"Paul Linehan" <plinehan_at_not.a.chance.ie> wrote in message news:3c010358.15039660_at_news1.eircom.net...
>
> "John Becich" <jbecich_at_nospam.net> wrote:
>

> *_WHATEVER_* you do, when you get the new app, make *_SURE_* that you
> have the source code and that it is developed in a reasonably
> mainstream development environment - get your client to invest in one
> copy of the environment so that they can hire someone to "tweak" it if
> and when necessary.
Hmmm. I am impressed by how strongly you feel about this. This would only be of interest if the parent company disappeared...which could happen, of course. I guess that's why big companies like other big companies, like Microsoft and Oracle; for their sustaining power.
>
>
> >> Also, I'm pretty sure that there are programmes out there that can
> >> give you reports on network usage, so you could look into that also -
> >> if the network isn't under strain, then adding more capacity is a
> >> waste of time.
I would doubt that, unless I rent some kind of network analyzer. The network has to be changed anyway. 10BaseT is obsolete.
>
> >The customer is ready to accept new wiring and modern switching
equipment.
> >So the 10 Mb Ethernet network is on the way out, regardless.
>
>
> Fair enough, but can you lay your hands on a network analysis
> programme? Can you ask for access to the server durning the busy time
> (don't use PC anywhere!!) and bring up the task manager and just look
> at the numbers - or just ring them up and ask someone there who has
> (IQ > house-plant) to do this - it *_may_* be that your network is
> fine.
No. This isn't in the cards.

> Ask about things like "mission creep" and what about archiving stuff -
> i.e. can the app cope with data being added indefinitely - what about
> removing/archiving redundant/old data?
Now you have brought up a very good point. The new app should be able to "archive" old data, to get it out of circulation.

> > The customer complains about the
> >slowness under such peak conditions, and is willing to hire me to remedy
it.
> >Furthermore, the customer has never implemented some experiments I have
> >petitioned them to perform, to give me a sense of where the bottlenecks
are.
> >I will be looking for an opportunity, therefore, to visit the site, and
> >conduct several experiments to discover bottlenecks. That is yet to
come.
> >I don't have those answers yet...
>
> It is *_CRITICAL_* that you do this before changing anything. If they
> wanted a doctor, they wouldn't be too happy if he consulted over the
> phone - they can't expect you to do the same.
I appreciate your proficiency, here, but I prefer to shotgun sometimes in the name of keeping costs down. The network is obsolete anyway. Not much sense in performing an autoposy on an uninteresting cadaver. Sometimes too much science makes bad business sense. Besides, it will suffice as an experiment if the customer will simply use the new W2K Pro workstation with its big pipe to the server, and report their impressions to me. This is one case where nagging makes more sense than a mountain of science. They will do it. I'm nagging them, and they are motivated finally.

>
> >> Again, if it's not under stress, a faster disk will just be siiting
> >> around waiting for requests.
>
> >I upgraded the disks and Host Bus Adapter last February, and there was a
> >performance jump.
>
>
> What are the stats on this? Do you actually have any? On what basis do
> you say that there was a jump?
The "stats" are the impressions of the customer.
>
> Well, on the Borland newsgroups I have seen people writing about this
> issue - many people have issues similar to yours and I know that
> people have mentioned the limits of file server databases, one of
> which was the size of the tables - this does not happen with rdbms
> server systems - it's not that RDBMS systems aren't affected by size,
> it's just that they're designed to grow better.
Ooo. Good point. I should ask the author of our existing system if it is relational or not. Do you know? It was written in Clipper with Comix databases.

>
> Client server is only as good as the programming that's done behind
> the scenes - if you have an rdbms system and the programmer does
> "select * from 90MB_Table" and this goes across the network, it will
> also grind to a halt.
>
> This is why I'm so interested in seeing the stats from the task
> manager - it *_may_* be the app, but it could be simply a network
> bottleneck, or maybe just doubling the RAM on the server or
> workstations might solve the problem for a few years.
Yes, yes, yes. If the customer uses the W2K station, several variable will be "improved" at once, and I can re-evaluate dramatically. I have already enhanced hard drive access and I've doubled the RAM, and quadrupled the processor, in the server, to little avail.
>

 >
> However, you can spend all the money you like on fancy new clients and
> if it's the app, then all you'll get for your trouble is Free Cell for
> the floor people to play while they're waiting for the system to
> respond.
Like I said, I will bug them to use theW2K client. It's been in place for months. They'll do it within two weeks. And they can't do ANYTHING new at this point without replacing the clients. The only possible way to keep them would be to repair the database app, and I don't think that's a serious option. There comes a point when repairing old stuff doesn't make sense.

>
Received on Sun Nov 25 2001 - 21:26:47 CET