Slow RDD experiences

[Antonio Linares]

I would like to ask you for your experiences regarding slow performance RDDs:

1. What RDD were you using ?

2. An upgrade of Harbour (or xHarbour) solved it ?

3. Was it related to a certain Windows version ?

4 Was it related to the network ?

5. How did you fixed it ?

I think this information will be useable by some Harbour and FWH users, especially for those that don't use the most recent versions. Thanks

[Enrico Maria Giordano]

Antonio,

I would like to ask you for your experiences regarding slow performance RDDs:

1. What RDD were you using ?

DBFCDX (FPT)

2. An upgrade of Harbour (or xHarbour) solved it ?

No.

3. Was it related to a certain Windows version ?

No.

4 Was it related to the network ?

Yes! It seems that Windows network is unacceptably slow, even for a simple COPY console command. Or at least the speed is far inferior from its nominal value.

5. How did you fixed it ?

I couldn't fix it.

EMG

[wilsongamboa]

Antonio

1. What RDD were you using ?

dbfntx

2. An upgrade of Harbour (or xHarbour) solved it ?

nop, but last versions of Harbour seems works good

3. Was it related to a certain Windows version ?

nop

4 Was it related to the network ?

90% true ,much issues like disables smb2, review the hardware, etc

5. How did you fixed it ?

I use adsntx local, and in big customers adsntx server

When i try to work with linux and samba with my program we have a problem with the indexes with adsntx local then i Switch to dbfntx and works good

excuseme my bad English

regards

[Antonio Linares]

Many thanks for all your answers, and surely for more that will arrive.

The network scenario of a FWH user is as follows:

* Windows Server 2003 with an app that opens a DBF with its CDX.

* Windows 7 from the client side, using the same DBF opened in the server. The problem could be related to the index as on each dbskeep/dbseek it has to consult the server).

* On this scenario just moving up and down a browse, the app slows down visibly.

* It seems that it is related to DbSkip and DbSeek

I appreciate your solutions, comments, etc. to help this user

[Antonio Linares]

Wilson,

4 Was it related to the network ?

90% true ,much issues like disables smb2, review the hardware, etc

smb2 was active on Windows Server 2003 ?

If so, how did you disabled it ?

thanks

[lucasdebeltran]

Antonio,

1. What RDD were you using ?

DBFCDX and ADS

2. An upgrade of Harbour (or xHarbour) solved it ?

No

3. Was it related to a certain Windows version ?

No

4 Was it related to the network ?

Yes, as Enrico pointed out.

5. How did you fixed it ?

Moving to ADO.

[Rick Lipkin]

To All

Just my personal observation years ago .. I believe 'opportunistic' locking on the client side is to blame for poor performance especially when opening .dbf on a network in SHARED mode... not so much if opened EXCLUSIVELY.

I have found ADO to cure many of the problems especially using Ms Access in place of .dbf for most businesses that run on a shared Lan. I still prefer MS Sql Server or Oracle for Enterprise applications.

Rick Lipkin

[Gale FORd]

Just a comment about skip and seek when .dbf opened in shared mode on network.
Every skip and seek locks and unlocks the index file. This is separate from record locks. When you get a few users with browse and reports, this can really add up with lock contentions and other overhead.

There was a function for some rdds that could turn off that locking. If you had a .dbf that was for history and did you did not update indexes, you could open .dbf in shared mode, turn on option to allow dirty reads and then the skips, go top, seeks, etc. do not need to constantly lock and unlock index file.
The commercial version of xHarbour.com has cmxShared(.F.) that can Switch to non-locking mode.

There was some discussions about network speed some time ago.
http://forums.fivetechsupport.com/viewt ... =3&t=19955

The old SIX driver had some documentation for their version of the index locking.

SET TURBOREAD:

Syntax:

SET TURBOREAD [ON | OFF]

This command allows you to turn-off the automatic locking of index
files during certain read-only processes, ie: SEEK, GO TOP, SKIP, FIND,
etc. This powerful feature has one serious side-effect: IT ALLOWS
OTHERS TO UPDATE YOUR INDEX WHILE YOU ARE SEARCHING IT! Basically,
this means that even though your SEEK may return a FOUND() = .T.
status, if the index was changed during the SEEK process, it would not
necessarily be accurate. That's why we call it a "dirty" read. <g>

To offer some type of solution to this integrity problem, semaphore
management functions (Sx_MakeSem(), Sx_KillSem(), etc) have been included
so that you may have a mechanism through which you can inform other network
users that you are in the SEEK process. With this, they can be forced to
wait until your process is complete before performing the index file
update.

NOTE: Using this function, while somewhat risky, will improve your
network performance by up to 100%, so weigh the options carefully.

NOTE: This command is NOT supported under SIXNTX.

Example:

/*
This program demonstrates the speed difference dirty read makes when
skipping though a shared database.
*/

#include "SIXNSX.CH"

LOCAL nStart, nEnd

SET EXCLUSIVE OFF // Make SHARED the default

USE TEST VIA "SIXNSX" // Open up the TEST database
INDEX ON last TO last // Build an index; Since it's exclusive after
CLOSE DATA // just creating it, close the database and
USE TEST VIA "SIXNSX" // reopen it
SET INDEX TO LAST // Then set our index active again

? "Skip test - shared"
?
nStart := Seconds() // Save starting time
FOR nCnt := 1 TO 240 // Cruise through the database for a bit
?? "." // Print a dot
DO WHILE !eof() // Skip to the end of the file
SKIP
ENDDO
DO WHILE !bof() // Skip back to the beginning of the file
SKIP -1
ENDDO
NEXT
nEnd := Seconds() // Save ending time

? "Elapsed time:", nEnd - nStart, "seconds"
?

// Now turn dirty read on
SET TURBOREAD ON

? "Skip test - shared with dirty read on"
?
nStart := Seconds() // Save starting time
FOR nCnt := 1 TO 240 // Cruise through the database for a bit
?? "!" // Print an exclamation point
DO WHILE !eof() // Skip to the end of the file
SKIP
ENDDO
DO WHILE !bof() // Skip back to the beginning of the file
SKIP -1
ENDDO
NEXT
nEnd := Seconds() // Save ending time

? "Elapsed time:", nEnd - nStart, "seconds"

[wilsongamboa]

Antonio
smb2 was active on Windows Server 2003 ?

Nop but oportunistick locking, etc


best regards

[Otto]

Hello Antonio,
there is some Information about SMB here:

http://forums.fivetechsupport.com/viewt ... b2#p115743

Best regards,
Otto

[Antonio Linares]

Otto,

thanks!

It seems as Michel has a great experience with this. Michel could you explain us how you detect the smb2 service and stop it ?

Same code as Dutch explained ?

thanks

[Patrizio]

I would like to ask you for your experiences regarding slow performance RDDs:

1. What RDD were you using ?

2. An upgrade of Harbour (or xHarbour) solved it ?

3. Was it related to a certain Windows version ?

4 Was it related to the network ?

5. How did you fixed it ?

I think this information will be useable by some Harbour and FWH users, especially for those that don't use the most recent versions. Thanks

1. DBFCDX (FPT)
2. No
3. No
4. No (our program don't run on network)
5. We don't fix.

The slow performance are due to deleted records but we can't use the INDEX ... FOR !Deleted()

[byte-one]

On Network i use a local version from the often used databases as cache (espacially core-data). At beginn of the app i update this data if necessary. On collection of data i write this data also in a temporary database and write back at end of the collection. This is a good way if the actuality of the data are not so important.
I always use NTX as this is the fastest RDD!?

[James Bott]

Patrizio,

The slow performance are due to deleted records but we can't use the INDEX ... FOR !Deleted()

Why can't you?

James

[Antonio Linares]

For those of you that still have the slowness problem, here you have a very simple function that can help you very much:

Code: Select all

function TurnShared( lOnOff )

return dbInfo( DBI_SHARED, lOnOff )
 

or simply call dbInfo( DBI_SHARED, .F. )

I appreciate your feedback regarding this function. Its behavior is similar to cmxShared()