| Author |
Performance Cobol Files
|
|
| Euromercante 2005-10-18, 7:55 am |
| Which the best form to increase the access speed the COBOL files in a
Windows net.
The application is developed in Fujitsu Power COBOL V7
The access is very slow when many users try to accede the same file (OPEN
INPUT).
Use Lock "mode automatic"
Many thanks
| |
| Michael Mattias 2005-10-18, 7:55 am |
| "Euromercante" <eurogest@euromercante.pt> wrote in message
news:newscache$s6yjoi$at$1@newsfront4.netvisao.pt...
> Which the best form to increase the access speed the COBOL files in a
> Windows net.
Use better programming techniques along with better design.
Seriously, there is no 'generic best way' to improve performance of any
kind. Every situation is different and every situation is
application-dependent.
The only thing which is constant is the first step: identify what is taking
the time.
The notorious bank robber Willie Sutton was once asked, "Why do you rob
banks, Willie?"
Mr. Sutton gave a good answer: "Because that's where they keep the money."
Same thing here: you have to know *where* your programs are using up time
before you can intelligently try to improve the performance.
In your specific case, here's something obvious:
>The access is very slow when many users try to accede the same file (OPEN
INPUT).
> Use Lock "mode automatic"
If the file is opened (by all users) only for input, why are you even
bothering with LOCK? If a lock is actually occurring, that's controlled by
your compiler. It really shouldn't issue a LOCK on access of this file, but
it may be checking for locked and/or retrying, which it shouldn't do if the
open mode is input only. But... you'd have to check what your compiler is
actually doing.
Simple enough to test: change lock mode to manual and see what happens.
Less obvious:
If all the users are reading the whole file sequentially every time, I'd
check to see why they need to do that. Maybe indexed I-O would be better if
the user only needs one or two records from the file at any one time.
See what I mean? First I say there is no such thing as 'generic'
improvements. Then I get an idea that, well, maybe there are... but then
both these ideas end up getting qualified with application-specific
conditions. (i.e., I should have quit while I was ahead).
MCM
| |
| HeyBub 2005-10-18, 6:55 pm |
| Euromercante wrote:
> Which the best form to increase the access speed the COBOL files in a
> Windows net.
>
> The application is developed in Fujitsu Power COBOL V7
>
> The access is very slow when many users try to accede the same file
> (OPEN INPUT).
>
> Use Lock "mode automatic"
The cheapest and easiest-to-implement way is to get faster computers for the
users.
| |
| Russell 2005-10-18, 6:55 pm |
| "HeyBub" <heybubNOSPAM@gmail.com> wrote in
news:11la0gtlafobc4@news.supernews.com:
> Euromercante wrote:
>
> The cheapest and easiest-to-implement way is to get faster computers
> for the users.
>
>
With Microfocus, you could try leaving the "mode" keyword
out of the select altogether. This gives you "Deny write" mode,
which is MANY times faster than "mode is manual".
This would be worth trying in Fujitsu as well.
What mode are you using anyway?
| |
| Frederico Fonseca 2005-10-18, 6:55 pm |
| On Tue, 18 Oct 2005 11:53:34 +0100, "Euromercante"
<eurogest@euromercante.pt> wrote:
>Which the best form to increase the access speed the COBOL files in a
>Windows net.
>
>The application is developed in Fujitsu Power COBOL V7
>
>The access is very slow when many users try to accede the same file (OPEN
>INPUT).
>
>Use Lock "mode automatic"
Where is the file located?
what access type are you doing (sequential, indexed)
What is the size of the file, and how many indexes does it have (if
indexed).
Are you using the VERY LARGE file DLL or the normal one?
If using a Windows server and with the file located on the server how
is the file being accessed (UNC or mapped drive)
How are file caching parameters set to both the server and the
workstations?
How are opportunistics locks set (hopefully OFF!!!)
And how many users are we speaking of?
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
| |
| Euromercante 2005-10-18, 6:55 pm |
| Thank for the tips!
I altered the program for "LOCK MODE MANUAL", the speed improved some thing.
However the program in cause should also have influences, use many
"PERFORME XXX THRU XXX.
What I notice is that compiling with the option "optimize" or without
"optimize" i do not notice any difference.
Regards,
JM
"Euromercante" <eurogest@euromercante.pt> wrote in message
news:newscache$s6yjoi$at$1@newsfront4.netvisao.pt...
> Which the best form to increase the access speed the COBOL files in a
> Windows net.
>
> The application is developed in Fujitsu Power COBOL V7
>
> The access is very slow when many users try to accede the same file (OPEN
> INPUT).
>
> Use Lock "mode automatic"
>
>
>
> Many thanks
>
>
>
>
| |
| Euromercante 2005-10-18, 6:55 pm |
| Olá Frederico!
> If using a Windows server and with the file located on the server how
> is the file being accessed (UNC or mapped drive)
F:\XXX\...
(mapped drive)
> How are file caching parameters set to both the server and the
> workstations?
server : System cache
workstation: programs
(I don't know if I am understand the question)
>
> How are opportunistics locks set (hopefully OFF!!!)
>
> And how many users are we speaking of?
+ or - 40 users
>
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com
| |
| Richard 2005-10-18, 6:55 pm |
| > The access is very slow when many users try to accede the same file
> (OPEN INPUT).
> The cheapest and easiest-to-implement way is to get faster computers
> for the users.
That is the fastest way to get no improvement at all. It is most
likely that the problem is the network where the file records are
transferring between machines, the next likely cause is the fact that
it is Windows on the server. The speed of the user machines is likely
to be irrelevant.
| |
| Richard 2005-10-18, 6:55 pm |
| > Which the best form to increase the access speed the
> COBOL files in a Windows net.
> The access is very slow when many users try to accede
> the same file (OPEN INPUT).
How are the files read ? Are the users reading the whole file or is it
just reading a few records by key ? If the whole file then how big is
it ? The data needs to travel over the network.
You need to check the speed of the network cabling and measure the
traffic over the network. If you have only got 10 Mbit network you need
to replace the network cards in each machine and the hub with 100 MBit
or Gigabit network.
It seems that the file will be on a Windows machine (_there's_ the
problem!!). Is it using FAT or NTFS ? FAT will be quite slow for large
files. Are there lots of files in the directory ?
| |
| Michael Mattias 2005-10-19, 7:55 am |
| "Euromercante" <eurogest@euromercante.pt> wrote in message
news:newscache$nqekoi$1fb$1@newsfront4.netvisao.pt...
> What I notice is that compiling with the option "optimize" or without
> "optimize" i do not notice any difference.
And what does that tell you?
What it should tell you is there is nothing in your code technique which is
an obvious source of problems; i.e., your problem is elsewhere: File access,
network access or (my personal candidate) a 'less-than-optimal' design.
(Because design is always my prime candidate, that's why).
MCM
| |
| HeyBub 2005-10-19, 9:55 pm |
| Richard wrote:
>
>
> That is the fastest way to get no improvement at all. It is most
> likely that the problem is the network where the file records are
> transferring between machines, the next likely cause is the fact that
> it is Windows on the server. The speed of the user machines is likely
> to be irrelevant.
Nope. In EVERY test we've done, the speed of the client machine is the
bottleneck. On a PC peer-to-peer network, network traffic seldom exceeds 10%
of capacity. Our Win2003 Server tracked at better than 80% "System idle"
time. (Windows has utilities to track things like network utilization and
CPU time.)
In thinking on it, simple math says that a 100Mbit network is WAY faster
than the transfer rate to/from a hard drive.
So we took a couple of pokey 600 MHz machine and upgraded them (by
swapping-out the motherboard) to 2.6 GHz (total cost < $250 each). There
were no other changes made to the network. These two workstations now fly
like the wind.
If you're persuaded that machine speed is irrelevant, I've got a couple of
600MHz motherboards, with 512Meg memory, I'll sell you cheap ($250 each).
| |
| HeyBub 2005-10-19, 9:55 pm |
| Michael Mattias wrote:
> "Euromercante" <eurogest@euromercante.pt> wrote in message
> news:newscache$nqekoi$1fb$1@newsfront4.netvisao.pt...
>
> And what does that tell you?
>
> What it should tell you is there is nothing in your code technique
> which is an obvious source of problems; i.e., your problem is
> elsewhere: File access, network access or (my personal candidate) a
> 'less-than-optimal' design. (Because design is always my prime
> candidate, that's why).
Not exactly, it just tells him there are no optimizable code snippets in his
coding. For example, the optimizer found no need to change:
PERFORM 10000 TIMES
MOVE 1 TO X
(something else)
END-PERFORM
to
MOVE 1 TO X
PERFORM 10000 TIMES
(something else)
END-PERFORM
Or, alternatively, the compiler optimized the hell out of the code, but he
didn't hit that optimized part during his testing.
| |
| Richard 2005-10-19, 9:55 pm |
|
HeyBub wrote:
> Richard wrote:
[color=darkred]
> Nope. In EVERY test we've done, the speed of the client machine is the
> bottleneck.
That is probably from all the spyware and viruses running on your
Windows.
> On a PC peer-to-peer network, network traffic seldom exceeds 10%
> of capacity.
That is a very bold statement. Of course, what each network has as
traffic depends entirely on the traffic.
> In thinking on it, simple math says that a 100Mbit network is WAY faster
> than the transfer rate to/from a hard drive.
Well think again. You should realise that network is 100 M _BITS_ per
second and disks are up to 160 M _BYTE_ per second. Even a cheap PC
drive can sustain 40 or 50 MBytes/sec. So, you failed that test.
> no other changes made to the network.
Maybe, but I was addressing his actual problem (see top line), not the
problem that you had. His claim is that when he has _many_ users
accessing the file it becomes slow. This implies that it is not slow
when one user accesses it. If the problem was the workstations and not
the network, server, or file access then it would be expected that it
would be slow when just one was accessing the file.
So, you failed that test too.
| |
| Michael Mattias 2005-10-19, 9:55 pm |
| "HeyBub" <heybubNOSPAM@gmail.com> wrote in message
news:11ldapqfn24ie7c@news.supernews.com...
> Michael Mattias wrote:
>
> Not exactly, it just tells him there are no optimizable code snippets in
his
> coding. For example, the optimizer found no need to change:..
That's what I meant: 'Doh!" moments whilst programming.
I'll stick with design as besst source for performance improvement (although
a very powerful case has been made for 'client motherboard clock speed').
One thing is for sure: upgrading the motherboards will no doubt be less
expensive then taking a hard look at - and revising - the design, and the
faster motherboards will be faster even if nothing is done to the design.
MCM
| |
| Euromercante 2005-10-20, 7:55 am |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1129659405.830664.35480@g44g2000cwa.googlegroups.com...
>
>
> How are the files read ? Are the users reading the whole file or is it
> just reading a few records by key ? If the whole file then how big is
> it ? The data needs to travel over the network.
>
> You need to check the speed of the network cabling and measure the
> traffic over the network. If you have only got 10 Mbit network you need
> to replace the network cards in each machine and the hub with 100 MBit
> or Gigabit network.
The net is all to 100MBit
>
> It seems that the file will be on a Windows machine (_there's_ the
> problem!!). Is it using FAT or NTFS ? FAT will be quite slow for large
> files. Are there lots of files in the directory ?
>
The application uses 7 files.
Two, the reading is made "read next record..." (65MB)
Other "Read invalid key..."
The net is all to 100MBit.
The files are in a "server" with the Wondows2003 server (ntfs).
The clients are 80% XP Pro and the rest Windows98.
Most uses FAT.
+ or - 800 files in the directory .
Thank you
JM
| |
| Richard 2005-10-20, 6:55 pm |
| > Two, the reading is made "read next record..." (65MB)
If the whole file is read then it would take at least 10 seconds across
the network. This would saturate the network making every one else very
slow. If two were reading all the file the times are additive so for
20 seconds every one else is very slow.
> Use Lock "mode automatic"
If the program is locking every record as it reads it (which it should
not having open input) then it will take longer and will use more
network time.
Is it reading the whole 65 MByte file ? Why ?
|
|
|
|