I would like to ask you for your experiences regarding slow performance RDDs:
What RDD were you using ?
An upgrade of Harbour (or xHarbour) solved it ?
Was it related to a certain Windows version ?
4 Was it related to the network ?
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
Antonio Linares wrote:I would like to ask you for your experiences regarding slow performance RDDs:
1. What RDD were you using ?
Antonio Linares wrote:2. An upgrade of Harbour (or xHarbour) solved it ?
Antonio Linares wrote:3. Was it related to a certain Windows version ?
Antonio Linares wrote:4 Was it related to the network ?
Antonio Linares wrote:5. How did you fixed it ?
Antonio
dbfntx
nop, but last versions of Harbour seems works good
nop
4 Was it related to the network ?
90% true ,much issues like disables smb2, review the hardware, etc
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
* 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
4 Was it related to the network ?
90% true ,much issues like disables smb2, review the hardware, etc
Antonio,
DBFCDX and ADS
No
No
4 Was it related to the network ?
Yes, as Enrico pointed out.
Moving to ADO.
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
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"
Antonio
smb2 was active on Windows Server 2003 ?
Nop but oportunistick locking, etc
best regards
Hello Antonio,
there is some Information about SMB here:
viewtopic.php?f=3t=21740p=115743hilit=smb2#p115743
Best regards,
Otto
&&&
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
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
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!?
The slow performance are due to deleted records but we can't use the INDEX ... FOR !Deleted()
function TurnShared( lOnOff )
return dbInfo( DBI_SHARED, lOnOff )