|
Codelocking will not improve performance.
Dennis McGrath
Hello Everyone-
My thanks and appreciation to all who responded. Lots of great
information flying around, and all suggestions were certainly
welcomed!
Have some things to report:
As I mentioned previously, Microsoft Server 2003 allows for only 2
network connections to the back of the actually server. The wiring
originally went server to 100 mbps router, with each of two machines and a
DSL line also tied to that same router.
I took the opportunity to tie both machines to the 1 gig network cards on
the back of the server directly (gig to gig communication), eliminating any
connection to the router (modem also unhooked). The performance of either
machine to the database on the server did not improve.
Went back to the peer to peer arrangement (machine #1 to router, router to
machine #2 containing the database), and actually saw a slight improvement in
operation over the previous method.
From this, it appears that a transfer rate of 100 mbps between
machines does not adversely effect R-Base database performance.
I set "echo on" on my command files, and watched the results.
"Update" statements seem to create the largest pause in processing, and if there
are a number of them-- it's crawl city. I can only surmise that every
"update" "set" or manipulation of a line of data in the main database is
causing massive traffic between the server and work station. I think that
Microsoft checks every data exchange to the "nth" degree for security purposes,
and that checking is weighing down the system.
I contacted Novell today. They basically make 2 products for the
small business-- Suslinux Enterprise Server (Linux based), and Open Enterprise
Server. Open Enterprise seems to be the choice, because it will
readily support DOS based stuff, and I don't need to learn Martian.
In particular, with their products you don't have to load any intercomputer
security features-- totally eliminating Microsoft's examining of every grain of
sand going down the highway. I truly believe that this is where the rub is
in accessing the database on the server by more than one client at a time.
What's more-- I can down load a trial version from Novell, and try it-- and
that's what I'm going to do. The cost is under $130 per client-- not
bad.
I'm shipping Microsoft Server 2003 back to Bill Gates today-- no matter
what, it does not seem to the answer for a small operation running R-Base in a 2
person multi-user environment.
I tried many of the suggestions offered by the team, but only saw very
small changes in operating performance.
Does codelocking significantly improve performance over "uncodelocked"
cmd's and eep's (with only 2 of us, I see no need to entail this much security
if not needed)?
Hope I didn't bore anybody. Comments?
Will share the results with the group after the experiment. There
goes another weekend!
Have a great week!
Lee
----- Original Message -----
Sent: Tuesday, July 11, 2006 10:47
AM
Subject: [RBASE-L] - RE: What's up with
this?
Bob,
I've run into to this at three customer sites.
Two are running windows server
(2003?) software. I work remotely and do
not have the expertise I need to
tweak server settings. Interestingly, one
site used a computer tech for years
who I felt was pretty good. After
working with him for a while one day he
concluded it was a file
locking/sharing issue between Windows Server and
R:Base and there was
nothing we could do. He went on to work as a
network administrator
at the local college. The tech that replaced him at the
customer site
walked in and solved the problem w/o fanfare. All he did was
turn
"opportunistic file locking" ON and excluded R:Base from virus
checking.
The customer said it was a "day and night" difference. I should
note that
no more than three people would access the database at one time,
and as
you said, it is the second user that gets awful, awful performance. It
is
not a matter of bandwidth or server horsepower.
Another site with the
same app and same windows server platform was
experiencing what you are
also. When I passed the fix on to their tech
nothing happened. He was only
insistent there was nothing "wrong" with the
network. Communication there
is poor and I have not been able to learn
more.
At the third site
they are running XP Pro Peer to Peer with only two
computers accessing the
same app as above. Same symptoms. I have not
found a file locking setting
for XP, but have not taken much time at all to
scope out the problem there
either.
I'd appreciate your posting back whatever you learn about this.
It's been a
major issue for me.
Ben
On 10 Jul
2006 at 18:35, [EMAIL PROTECTED]
wrote:
>
> I certainly am not a server expert, database
expert or even a programming expert!
> But I do know that there are
probably millions of installations using Rbase, FoxPro, Access,
>
Paradox, Pervasive(localmode)and other non-client/server databases crunching
away out there
> every day.It is hard to imagine they are all having
"show stopping" performance problems.
>
> The company I mainly
work for has several commercial applications they purchased that run on
> one or more of the above packages. I have written a number of Rbase
systems to integrate with
> the above as well and am working toreplace
some with Rbase apps.
>
> I have heard of the "speed" issue but I
guess I am lucky enough not to have seen it.
> Running a 2003 server, 1
gig connection between server and switch but 100mb from switch to the
>
work stations. Not a huge network, but more than 15 users and none of the
database applications
> seem to have any problems, regardless of
"brand". Rbase is actually faster than the others! I
> switched from a
Novell system to Windows 2003 about 1 1/2 years ago and actually saw
>
significant improvement, although I also upgraded the hardware at that time as
well.
>
> My point is, I would think that having just 2 PC's
connected would not (should not) bring an
> application to a stand
still? There must be some settings somewhere that need tweaked. I can
>
see large number of users having significant impact, but small numbers I would
not think one
> should see much issue.
>
> Again, I am
one of the "lucky ones" that seems to not have speed issues!
>
>
-Bob
> -------------- Original message
--------------
> From: "Dennis McGrath" <[EMAIL PROTECTED]>
> Access will suffer the same problems on an MS
server, since it is a file server db just like
> RBASE (I believe it was a rip off of RBASE to
begin with!!!)
> There is a considerable amount
of server tuning instructions out there to
>
try to help alleviate the problem with file server dbs, but the MS security
model generates
> lots of
> network traffic due to the fact that it
checks your access rights to each and every file
> every time you access them over the
network.
>
>
Novell of oldhad you log in , figured out your access rights, and screamed
forward from
>
there.
> It's disk caching was awesome too.
>
> Better to
avoid any MS caching of DB files!!! Brain
dead.
>
> When we
get to Client-Server, these issues will largely go away because all access to
the
> db is by code running on the server and
thus the db files are "local"
>
> Dennis
McGrath
>
>
>
>
>
>
> From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Castanaro,
Bob
> Sent: Monday, July 10, 2006 12:55
PM
> To: RBASE-L Mailing
List
> Subject: [RBASE-L] - RE: What's up with
this?
>
>
> Does anyone have any experience on this issue
with Access? OK, the DREADED
> Access. Does
Access have the same speed issues, or is there some trick they (MS) are
> not sharing that optimizes the MS
servers?
>
> For
a small office, this will continue to be an issue and will be a problem for
R:Base. For a
> large installation, I'm sure
the RB Client -Server will solve it. Novell really blew it a few
> years back. It was clean, stable and
efficient. R:base screamed on it. They just had no
> clue how to market, and were way behind on a
GUI interface. Look how they bumbled
> Word
Perfect, still the best word processor ever.
>
> BC
>
>
> From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Javier
Valencia
> Sent: Monday, July 10, 2006 1:41
PM
> To: RBASE-L Mailing
List
> Subject: [RBASE-L] - RE: What's up with
this?
>
>
> Emmitt:
> This
is a nice checklist; however, as a way of background, my client has a Novell
server
> and they were experiencing some delays
(turned out to be a problem with R:Base, now
>
fixed). We tried switching the client cards form auto to full duplex and the
response
> dropped to a crawl, we set the cards
back to auto and the performance improved
>
dramatically. I am nor sure if this is typical but it would be wise to test it
both ways and see
> if how performance is
affected.
>
Javier,
>
>
Javier Valencia, PE
>
President
> Valencia Technology Group,
L.L.C.
> 14315 S. Twilight Ln, Suite
#14
> Olathe, Kansas
66062-4578
> Office
(913)829-0888
> Fax
(913)649-2904
> Cell
(913)915-3137
>
================================================
>
Attention:
> The information contained in this
message and or attachments is intended
> only
for the person or entity to which it is addressed and may
contain
> confidential and/or privileged
material. Any review, retransmission,
>
dissemination or other use of, or taking of any action in reliance
upon,
> this information by persons or entities
other than the intended recipient
> is
prohibited. If you received this in error, please contact the sender
and
> delete the material from all system and
destroy all copies.
>
======================================================
>
> -----Original
Message-----
> From: [email protected]
[mailto:[EMAIL PROTECTED] Behalf Of Emmitt
Dove
> Sent: Monday, July 10, 2006 12:17
PM
> To: RBASE-L Mailing
List
> Subject: [RBASE-L] - RE: What's up with
this?
>
>
> Lee,
>
> The problem is a Microsoft thing. Any time on
an MS network with the database
> on an MS
server, more than one user experiences slowdown. To combat this,
> there are a few steps to
take:
>
> 1. Use
a gigabit link between all your machines.
> 2.
Use a switch downstream from the router.
> 3.
Try to use hardware that supports full duplex. Check your cards to see if
they're
> operating full duplex, and if not
(and set to AUTO), try forcing full duplex.
> 4.
Use quality cables.
> 5. Make certain each user
has scratch files set to their local drive.
> 6.
Run with STATICDB ON.
> 7. Make certain the box
holding the files is set to optimize for background
> services not
applications.
> 8. Don't use the box holding the
files for anything else.
> 9. Don't use
peer-to-peer; install a domain controller (not o n the file
server).
> 10. Install R:Base locally on each
client.
> 11. Run, don't walk, to 7.5, Windows
not DOS.
>
> Now,
these are all in the nature of suggestions, but are things we've found
> improve the
responsiveness.
>
>
>
> Have you
experienced the same types of difficulties when
> employing your applications in a network
scenario? What do the
> "big boy" clients do to
avert this issue?
>
> Thanks to
all!
>
>
Lee
>
> Emmitt
Dove
> Manager, DairyPak Business
Systems
> Blue Ridge Paper Products,
Inc.
> 37 Sybil
Ave
> Branford, CT
06405
> (203)
643-8022
> [EMAIL PROTECTED]
>
[EMAIL PROTECTED]
>
|
