From: Anonymous on
In article <tJQ9j.121$El5.23(a)newssvr22.news.prodigy.net>,
Michael Mattias <mmattias(a)talsystems.com> wrote:
>I'd bet at least ninety percent of run-time performance is determined before
>you write the first line of source code.. by your application design.

Hmmmmm... given how I have seen systems age, Mr Mattias, I'm not quite
sure where 'application design' properly fits in. For example:

Away back when... Mr Able got budget approved to put together... something
that gives annual totals by location.

Then, later... Ms Baker wants what Mr Able has... but she wants it broken
down by department within location.

Later... Mr Charlie wants what Ms Baker and Mr Able have... but he wants
it broken down by manager within department within location and totalled
by quarter.

And again... Ms Dexter wants what Mr Charlie and Ms Baker and Mr Able
have... but she wants it updatable by manager within department within
location on a nightly basis.

Then... Mr Echo wants (see above)... but updatable and queryable across
each way and displayed in realtime.

The application design for what Mr Echo wants would be, from what I have
seen of such things, rather different from what Mr Able started with...
but in my experience what frequently happens is that the system already in
place is turned over to someone with a dictum that starts with 'All ya
gotta do is...'

>That extra hour or so you spend *thinking* about file access, network
>traffic, indexes, record/table layouts, overall program flow, etc pays for
>itself.

If one searches this newsgroup for the phrase "stepped out for a smoke"
one might find an anecdote about how 'thinking time' has been valued by a
Project Leader.

>Sure, it pays for itself but a few seconds or milliseconds at a time, but
>over hundreds of thousands or millions of iterations it *does* pay for
>itself.

Now that just Doesn't Make Sense, Mr Mattias... for what reason would a
Manager, evaluated on a quartely basis, spend extra money in order to
benefit those who Come After? Let *Them* pay for optimising... get that
code into Prod, fast!

DD

From: Richard on
On Dec 18, 11:37 pm, razor <irudd...(a)blueyonder.co.uk> wrote:
> or...
>
> If I were an 'IT Consultant' who had never known how to design and
> code a system I could say...
>
> "You need a bigger server". Pocket the consultancy fee and walk.
>
> Unfortunately, I'm sure we've all seen it done.

If you were an 'IT Consultant' you would say "You need an XYZ server",
pocket the consultancy, pocket the kickback from XYZ, and charge for
installation, training and support at consultancy rates while sending
in a part-time student to do it.


> When you say 40 clients, are these clients actually running the
> application or are they using Terminal Services/Remote Desktop ?

From: Richard on
On Dec 18, 11:02 pm, "Euro" <e...(a)euromercante.pt> wrote:
> Thanks a lot for the suggestions, however the same application run in a
> system with the Windows 2003 Server has a completely different reply.
> This is that I do not obtain a explain.
> I do not use OPEN WITH LOCK or LOCK MODE
> EXCLUSIVE) will be each access, but yes i use READ WITH LOCK and UNLOCK xxxx
>

Perhaps the Windows 2003 server had gigabit LAN and the 2000 has
10/100 with 10Mbit hubs.

Perhaps the W2003 has SATA2 drives with RAID 0 (striped) for speed and
the 2000 has a single IDE mode 4.

Perhaps the W2003 has several Gbytes of RAM while the W2000 has only
512Mbyte and is thrashing its swap file.

Perhaps the W2000 is part of a botnet and is spending 75% of its time
sending out spam emails.

Only when you start collecting numbers will you be able to work out
what to do.

From: HeyBub on
Euro wrote:
> Excuse me, if I did not inform, but I am speak of windows 2000 server
> !!!
>
> "HeyBub" <heybub(a)gmail.com> escreveu na mensagem
> news:13mfd74sqne34a4(a)corp.supernews.com...
>> Euro wrote:
>>> Thanks a lot for the suggestions, however the same application run
>>> in a system with the Windows 2003 Server has a completely different
>>> reply. This is that I do not obtain a explain.
>>> I do not use OPEN WITH LOCK or LOCK MODE
>>> EXCLUSIVE) will be each access, but yes i use READ WITH LOCK and
>>> UNLOCK xxxx
>>> Thanks one more time
>>> Joe
>>
>> Windows 2000 is limited to TEN concurrent connections.
>>
>> "By default, Windows 2000 Professional is limited to no more than 10
>> concurrent connections. Anyone trying to connect after the maximum
>> number of connections is reached receives an error message, and the
>> connection is refused."
>>
>> There you are.

Okay, so how many CALs (Client Access Licenses) is the 2000 Server
authorized?


From: Pete Dashwood on


"Richard" <riplin(a)azonic.co.nz> wrote in message
news:4f6f0113-9318-47ef-b723-1d56b06db0a9(a)d21g2000prf.googlegroups.com...
> On Dec 18, 6:39 am, "Euro" <e...(a)euromercante.pt> wrote:
>> I have a customer that has + or - 40 clients and a server with windows
>> 2000,
>> HP PROLIANT, dual processor 2,8 MHZ, 2GB RAM to run an application made
>> in
>> fujitsu powercobol, using indexed files.
>> The system is very slow.
>> That configurations recommend to me to improve the situation.
>
> One of the problems of using indexed files on a system like this is
> that the client is not just 'reading a record', it is searching the
> index and transferring multiple blocks of data across the network so
> that it can follow all the index levels and _then_ it reads the
> record.
>
> You need to start by analysing the problem. Measure the network
> traffic, monitor the disk activity. Check the level of record locks
> and collisions.
>
> It may be, for example, that the clients are spending significant
> amounts of time waiting for records locked by another client, or it
> may be that the network is overloaded, or that the disk is
> continuously active.
>
> Some of these may be fixable (eg upgrade to gigabit network, or change
> to SATAII or spread the load across more drives), while other problems
> will need rewriting the application.
>
> For example if there are a significant number of locked record clashes
> do you simply redo the read immediately (and thus overload the network
> and disk) or do you 'sleep' for a short time and then retry.
>
> If, eg, you keep filling window lists with all records on each
> interaction you may be better to load it once and hold it in an array
> in the client to refill the list from the next time.
>
> Performance is a function of application design and not just of
> hardware configuration.
>
Excellent response, Richard. Mine would have been along the same lines. The
problem is not necessarily PowerCOBOL, it is in all the factors you mention.

Pete.
--
"I used to write COBOL...now I can do anything."