Page 1 of 4

Slow RDD experiences

PostPosted: Wed May 28, 2014 3:09 pm
by 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 :-)

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 3:21 pm
by Enrico Maria Giordano
Antonio,

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

1. What RDD were you using ?


DBFCDX (FPT)

Antonio Linares wrote:2. An upgrade of Harbour (or xHarbour) solved it ?


No.

Antonio Linares wrote:3. Was it related to a certain Windows version ?


No.

Antonio Linares wrote: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.

Antonio Linares wrote:5. How did you fixed it ? :-)


I couldn't fix it. :-(

EMG

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 4:02 pm
by 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

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 4:32 pm
by 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 :-)

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 4:33 pm
by 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

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 4:55 pm
by 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.

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 6:05 pm
by 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

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 8:17 pm
by 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/viewtopic.php?f=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"

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 8:44 pm
by wilsongamboa
Antonio
smb2 was active on Windows Server 2003 ?

Nop but oportunistick locking, etc


best regards

Re: Slow RDD experiences

PostPosted: Wed May 28, 2014 9:11 pm
by Otto
Hello Antonio,
there is some Information about SMB here:

viewtopic.php?f=3&t=21740&p=115743&hilit=smb2#p115743

Best regards,
Otto

Re: Slow RDD experiences

PostPosted: Thu May 29, 2014 3:22 am
by 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

Re: Slow RDD experiences

PostPosted: Thu May 29, 2014 7:17 am
by Patrizio
Antonio Linares wrote: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() :(

Re: Slow RDD experiences

PostPosted: Thu May 29, 2014 9:24 am
by 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!?

Re: Slow RDD experiences

PostPosted: Thu May 29, 2014 1:56 pm
by 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

Re: Slow RDD experiences

PostPosted: Thu May 29, 2014 4:04 pm
by 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  Expand view
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()