Hi
2009/10/5 Przemyslaw Czerpak <dru...@acn.waw.pl>:
>> 50-100 councurrent access
>
> Over 100 in one of my installations.
>
>> 1. very large load on the server
>
> No at least in programs I wrote. The most expensive is database access
> and rest is unimportant.
>> 3. not everything can be transferred to the server (browse...)
>
> I still do not understand.
> In my case whole applications are executed on server side.
I am very happy for you
But we speak now not about your program.
"I wrote my own 'screen' like program which keeps alive applications
executed on the server side"
In fact, this terminal-server
We have a lot of calculations and terminal access is not suitable (as
is your decision)
> For me it's obvious that seek may not work properly and I do not
> understand why I have to clarify such simple things.
> Please try this code with pure DBFCDX and LetoDB.
>
> REQUEST DBFCDX
> REQUEST LETO
> field F
> proc main(rdd)
> local cFile := "_tst"
> if empty( rdd )
> cFile := "//127.0.0.1:2812/" + cFile
> rddSetDefault( "LETO" )
> else
> rddSetDefault( "DBFCDX" )
> endif
> dbCreate( cFile, {{"F","N",10,4}} )
> use (cFile)
> ? rddSetDefault(), alias(), used()
> index on F tag T to (cFile)
> dbAppend(); F := 1 / 8
> ? "FOUND:", dbSeek( 1 / 8 )
> close
> return
>
> If you plan to answer in your next message that you do not use seek
> in such context so it's not a problem then please do not waste my
> time.
I (honestly) do not understand the meaning of this example, since a
long time (even with the clipper 5.2) away from such actions (unstable
floating-point on different machines and operating systems)
Use for just such a character string (always predictable results)
index on STR(F,10,4) tag T to (cFile)
dbSeek( STR( 1 / 8, 10, 4 ) )
>> What exactly would the author - one must ask the author. In any case
>> the project is completed by the author (based on activity over the
>> past year)
>> Now we are not talking about the UDF. I would like to, but it means a
>> change that just lead to incompatibility with the current
>> implementation
>
> And it's the reason I do not want to touch LetoDB code and I strongly
> prefer to create sth new from scratch using my own ideas for final
> code. Most of the problems which have to be resolved in such fully
> functional remote server implementation I resolved adding MT mode to
> Harbour so now it's enough to use this functionality but it also mean
> that the new code will not work with older Harbour versions or with
> xHarbour.
What we do with the current functionality? Bright and well into the
future and the present is bad?
>> > You can use RDD section in CA-Clipper 5.3 Technical Reference.
>> > Harbour RDD model follow very closely Clipper one. There are only
>> > few small differences and extensions and it was the place were
>> > I started before I touched Harbour RDD code.
>> "few small differences and extensions" :)
>
> Your comment clearly shows that you haven't invest even 5 minutes to
> compare Clipper documentation with Harbour RDD implementations.
> We may return to this discussion when you will have something serious
> to say or some precise questions for which you cannot find answers in
> Clipper documentation.
> I also suggest to look into ChangeLog and if possible into xHarbour
> ChangeLog too. A lot of RDD code I committed in the past working on
> xHarbour as primary repository. Together with Clipper documentation
> it address everything.
No one wanted to offend
> Yes, it is and here LetoDB is very inefficient because is disables
> existing RDD optimizations.
>
>> My example (two connections to the table):
>> RDD: DBFCDX \\192.168.170.11\income\_tst2
>> testing... 25.58 sec.
>> RDD: LETO //192.168.170.11:2812/_tst2
>> testing... 56.09 sec.
>
> 1. what is 'your example' in this test?
> 2. how many records (N_RECCOUNT) you tested?
> 3. can you also show results for my example?
This is your example, but the network
>> But since I do not use OrdKeyNo () for each record (and what is it
>> for?)
>
> It was only example, looking at LetoDB code I've found that it has to
> kill the performance for such operations anyhow it was also real life
> example from people using:
> nBar := ordKeyNo() / ordKeyCount()
> to calculate vertical progress bar in browse() and I was asked to
> optimize it few years ago. I guess you will write that they do not
> create real applications or that they can change their code and for
> sure at least the second conclusion is true anyhow if you accept it
> then you have to also clearly say that LetoDB cannot work with
> acceptable performance with any Clipper code.
Yes, there are problems with OrdKeyNo ()
But even for the "calculate vertical progress bar in browse ()" do not
call it 10000 times as in the example
>> Then I rewrote at SEEK
>
> Which quite well hides internal LetoDB problems, i.e. activating seek
> on each skip() during simultaneous access. Additionally SEEK in LetoDB
> is broken and does not restore SCOPE settings.
>
>> /* dbGoTop()
>> while !eof()
>> x := ordKeyNo()// / ordKeyCount()
>> dbSkip()
>> enddo*/
>> for i := 1 to lastrec()
>> seek ( l2bin( i ) + "x" )
>> if ! found()
>> ? "!!!!!!!!!!!!!!!!!!"
>> endif
>> next
>> RDD: DBFCDX \\192.168.170.11\income\_tst2
>> testing... 17.59 sec.
>> RDD: LETO //192.168.170.11:2812/_tst2
>> testing... 8.12 sec.
>
> We have two loops in above test so which one you tested?,
> how many records were used in this test?
> did you removed scope settings in the code?
This is your example (with alteration of SEEK)
> In this test the most expensive is TCPIP overhead so LetoDB which
> uses less frames have to win. Anyhow it does not change the fact
> that the difference is very small and should be much bigger and
> does not fix internal LetoDB problems.
Repeat:
At least twice LetoDB faster (in reality, almost 4 times)
RDD: DBFCDX \\192.168.170.11\income\_tst2
testing... 17.59 sec.
RDD: LETO //192.168.170.11:2812/_tst2
testing... 8.12 sec.
> Because you have different code and this is LetoDB problem. Such things
> should not happen and any user database code should be improved by using
> remote RDD or at least should not be slow down.
#define N_RECCOUNT 10000
REQUEST LETO
REQUEST DBFCDX
field F
proc main(rdd)
local cFile := "_tst2", fileFunc, x, t, i
if empty(rdd)
cFile := "//192.168.170.11:2812/" + cFile
rddSetDefault( "LETO" )
fileFunc:=...@leto_file()
else
if upper(rdd)="NET:"
cFile := "NET:127.0.0.1:/" + cFile
else
cFile := "\\192.168.170.11\income\" + cFile
endif
rddSetDefault( "DBFCDX" )
fileFunc:=...@dbexists()
endif
? "RDD:", rddSetDefault(), cFile
if !fileFunc:exec( cFile + ".dbf" )
? padr( "creating table...", 20 )
t := seconds()
dbCreate( cFile, {{"F","C",100,0},{"F2","L",1,0}} )
use (cFile) alias tst
while lastrec() < N_RECCOUNT
dbAppend(); F := l2bin(recno()) + repl( "x", 100 )
enddo
t := seconds() - t
?? t, "sec."
? padr( "indexing...", 20 )
t := seconds()
index on F tag T to (cFile)
t := seconds() - t
?? t, "sec."
close
endif
use (cFile) alias tst shared
set index to (cFile)
? padr( "testing...", 20 )
wait // !!!! launch a second instance !!!!!!!!!! LAN !!!!!!!!!!
t := seconds()
ordScope( 0, l2bin(0) + "x" )
for i := 1 to lastrec()
seek ( l2bin(i) + "x" )
if ! found()
? "!!!!!!!!!!!!!!!!!!"
endif
x := F
next
t := seconds() - t
?? t, "sec."
close
return
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
