|
Steve-
You mentioned the administrative wizard-- where is it located on a
server? I've looked everywhere (but apparently not in the right
place). I did find an article pertaining to "opportunistic file locking"
but it requires messing around with the server registry-- taboo land.
Thanks!
Lee
----- Original Message -----
Sent: Tuesday, July 11, 2006 4:07
PM
Subject: [RBASE-L] - RE: What's up with
this?
Steve,
Thanks for the info. Are you able to set
opportunistic file locking in XP? If so
I'd like to check out the third
client site.
Also, the tweaks relative to the NIC you mentioned, how
substantially do
they affect performance? Are they complicated to
understand?
Thanks
Ben
On 11 Jul 2006 at 14:56,
Steve Durham wrote:
>
> Ben,
>
> "opportunistic
file locking" ON is a default setting in Windows. With
> Windows Server
2003, you can now setup your server for file sharing by
> simply
running the administrative wizard. This will optimize Windows for
>
file sharing. Now depending on the network card you have, there are things
> to tweak there. You will have to account for the type of security you
are
> using on your network while making those changes. If this server
has some
> sort of support, someone should be able to contact them and
ask for
> assistance on setting up the server NIC to be fully optimized
for your
> environment. Then the next thing to try is set all
your virus scanning on
> clients and servers not to scan $$$, rb*, and
any other RBase file you use
> or create during a session. I would
recommend setting this at the file
> extension level seeing the files
can exist anywhere on the server. All the
> above is dependent upon
setting up your file shares in a Windows Standard as
> well. Hope this
helps.
>
> >From: "Ben Petersen" <[EMAIL PROTECTED]>
>
>Reply-To: [email protected]
>
>To: [email protected] (RBASE-L
Mailing List)
> >Subject: [RBASE-L] - RE: What's up with
this?
> >Date: Tue, 11 Jul 2006 07:47:20 -0700
> >
>
>
> >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]
>
> >
> >
>
|
