Tim,

I created a test project and uploaded it to the binaries ng. I didn't include any DBISAM
tests, just comparison of EDB C/S and local mode.

Tried with 3 different physical machines (no VMs), created a shared folder with full
permissions, copied edbsrvr.exe into it, started it, started my testapp, entered the
server ip and the shared folder path, and run the tests.

Got VERY different results...

On a Win2K3 server (the one I used yesterday) : 30 ms local, 1100 ms C/S
On a WinXP client : 30 ms local, 2000 ms C/S
On an old Win2K client : 1200 ms local, 1600 ms C/S

First thought was : Maybe the Windows Firewall ? But the DBISAM Server runs also on the
Win2k3 Server, and has no trouble with it.

Can you give it a look ?

>>Also, just so you know - you don't need the KI or WI modifiers for the DEU
>>collation so they can safely be left out.

Thanks for the hint. Question : If I would want EDB varchars behave exactly like DBISAM,
which collation should I choose...or is DBISAM default the same as EDB default ?

Heiko

Heiko,

<< I created a test project and uploaded it to the binaries ng. I didn't
include any DBISAM tests, just comparison of EDB C/S and local mode.

Tried with 3 different physical machines (no VMs), created a shared folder
with full permissions, copied edbsrvr.exe into it, started it, started my
testapp, entered the server ip and the shared folder path, and run the
tests.

Got VERY different results...

On a Win2K3 server (the one I used yesterday) : 30 ms local, 1100 ms C/S
On a WinXP client : 30 ms local, 2000 ms C/S
On an old Win2K client : 1200 ms local, 1600 ms C/S

First thought was : Maybe the Windows Firewall ? But the DBISAM Server runs
also on the Win2k3 Server, and has no trouble with it. >>

Two comments regarding the project:

1) Don't name components generic names like Engine, Session, Database.
They'll get confused with the special global Engine() and Session()
functions in the edbcomps unit, as well as the Database property for
datasets.

2) The major slowdown seems to be the RemoteCompression setting that you're
using.  Don't use RemoteCompression > 0 for fast networks (100MB or higher).
It simply ends up costing the process more time compressing/decompressing
the data than it does in terms of time savings due to smaller transmission
sizes.

<< Thanks for the hint. Question : If I would want EDB varchars behave
exactly like DBISAM, which collation should I choose...or is DBISAM default
the same as EDB default ? >>

Yes, the EDB default ANSI collation is essentially the same thing as the
DBISAM default ANSI table locale.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>Don't name components generic names like Engine, Session, Database.
>>They'll get confused with the special global Engine() and Session()
>>functions in the edbcomps unit

So YOU name a GLOBAL function "engine" and "session" ? )

OK, I'll change that habit. Thanks for the hint.

>>The major slowdown seems to be the RemoteCompression setting that you're
>>using

Just tried it again, on my network at home (ever used an EEE-PC as a database server ? *g*)

Local : 50 ms
C/S with compression 6 : 3800 ms
C/S with compression 0 : 2500 ms

Heiko

Heiko,

<< So YOU name a GLOBAL function "engine" and "session" ? ) >>

Sure, I got a note from the principal that says it's okay. (you may not
get that joke since it's a bit US-centric)

<< Just tried it again, on my network at home (ever used an EEE-PC as a
database server ? *g*) >>

Are you really using an EEE-PC for the database server ?

<< Local : 50 ms
C/S with compression 6 : 3800 ms
C/S with compression 0 : 2500 ms >>

I'm getting times around 1400 ms with the database server running on the
same machine, so 2500 ms sounds about right for a 100MB network.  The
biggest issue that you run into as the bandwidth gets smaller is the
turnaround time on all of the tiny requests for a locate.  Locate can't use
the client-side cache at all, either, so it doesn't help at all.  1000
Locates are going to generate at least 2000+ requests/responses for the
Locates and the subsequent row retrievals.

I'll do some more looking, but I don't see anything particularly out of the
ordinary at this time.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>Are you really using an EEE-PC for the database server ?

Only at the moment, to test this, since I have only one PC at home, and the EEE-PC.

>>I'll do some more looking, but I don't see anything particularly out of the
ordinary at this time.

Sorry Tim, but this can't be normal. The last weeks I migrated my main app to EDB, almost
finished last weekend, and tried it in the same environment the DBISAM app is running now
for several years (with C/S, and compression set to 6). Until then I didn't notice any
speed difference to DBISAM...but now using C/S, some forms where I made heavy use of
lookups are almost unusable now. Filling a treeview was done in less than a second, now it
takes 20 seconds. Nested grids became so slow that you almost can watch the cells filling.
And I tested it without load...don't want to imagine the speed when there are 30 users
working with it.

I try again tomorrow with no compression. I could live with EDB beeing a little bit slower
than DBISAM, but not so obvious slow, that every user will question me about it.

Heiko

Heiko,

<< Sorry Tim, but this can't be normal. >>

I didn't say it was - I said "I don't see anything out of the ordinary at
this time".  Meaning, I haven't found anything in the code that screams
"problem" yet.  And, as I said, I'm going to keep looking.

<< And I tested it without load...don't want to imagine the speed when there
are 30 users working with it. >>

The number of users is irrelevant.  Whatever the issue is, it's more than
likely related to too many calls to the server.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Sure, I got a note from the principal that says it's okay.

Are you REALLY sure Sam gave you a note? Can you scan it in and let us see it?

Roy Lambert

Roy,

<< Are you REALLY sure Sam gave you a note? Can you scan it in and let us
see it? >>

What, you don't trust me ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Heiko,

<< Tried with 3 different physical machines (no VMs), created a shared
folder with full permissions, copied edbsrvr.exe into it, started it,
started my testapp, entered the server ip and the shared folder path, and
run the tests.

Got VERY different results...

On a Win2K3 server (the one I used yesterday) : 30 ms local, 1100 ms C/S
On a WinXP client : 30 ms local, 2000 ms C/S
On an old Win2K client : 1200 ms local, 1600 ms C/S >>

Okay, how does this sound:

DBISAM:

Fill - 1719 MS
Lookups - 390 MS

EDB:

Fill - 1765 MS
Lookups - 329 MS

The issue was a stream being created for every send/receive, and this wasn't
necessary.  The stream creation was costly because it was initializing the
BlowFish encryption (internally the EDB streams can all use encryption)
every time.

This fix will be in 2.01 B2.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

this is really GREAT. Thank you very, very much for it.

I spend the day extending the test project to do a dbisam comparison and more tests,
playing around with some settings, and found that when choosing the right settings at the
right situation, the speed difference shrinks to about 1 : 1.5, at least in the test
project. That would have been acceptable to me, but since I didn't know how the real app
would react (haven't had the time to implement the changes) I would have updated you tomorrow.

It's absolutely terrific that you eliminated the remaining .5 so fast - you made my day !

Heiko