Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread What perf gain likely with the DBISAM db server?
Wed, Nov 1 2006 7:39 PMPermanent Link

Sam Jones
Hello!

We use DBISAM 4.02 from May 2005.

We mostly use it in file sharing mode. Most installs have 2-5 workstations accessing the
database.

Or main concern is read performance (lots of sequential SELECT statements, some joins).


Will the DBISAM server give us a boost?

What should we expect?


Thanks!
Thu, Nov 2 2006 10:46 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Sam,

<< We mostly use it in file sharing mode. Most installs have 2-5
workstations accessing the database.

Or main concern is read performance (lots of sequential SELECT statements,
some joins).

Will the DBISAM server give us a boost?  >>

If you're primarily using SQL for reading data, then most certainly it will
give you a big boost in performance since the clients won't have to shuttle
lots of data back and forth across the network in order to execute the SQL.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Nov 7 2006 5:30 PMPermanent Link

Sam Jones
Wellllllll.............

We are using SQL, but our testing shows zero performance gain when using DBISAM server.


Next.... optimizing our queries.... if only we can figure out how to do this in DBISAM....
(we know how in SQL Server...  but can't find the profiler tool in DBISAM).


Suggestions?
Tue, Nov 7 2006 5:50 PMPermanent Link

"Johnnie Norsworthy"
"Sam Jones" <sam@acme.com> wrote in message
news:FE484374-A903-4510-90A2-F0A49B8B688B@news.elevatesoft.com...
> Wellllllll.............
>
> We are using SQL, but our testing shows zero performance gain when using
> DBISAM server.
>
>
> Next.... optimizing our queries.... if only we can figure out how to do
> this in DBISAM....
> (we know how in SQL Server...  but can't find the profiler tool in
> DBISAM).
>
>
> Suggestions?

DBsys is all you need to profile if you just want to see what is slowing any
queries. As far as profiling the code that acts on the query, that is
another thing.

Check- Generate Plan [x]

Run your query, and read the plan. It will tell you about the optimization
of the query.

-Johnnie

Wed, Nov 8 2006 4:25 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Sam


Don't forget the difference between c/s and fileserver is network traffic. So, firstly, if you have small tables and a fast LAN you won't notice much difference. Secondly, if your application is "chatty" (eg lots of lookup fields) the network traffic will still be high and you won't notice much difference.

Roy Lambert
Wed, Nov 8 2006 3:12 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Sam,

<< We are using SQL, but our testing shows zero performance gain when using
DBISAM server. >>

Are you sure that your application is accessing the data via the server and
not still directly via the Win32 API ?  There should be at least a small
improvement in the speed, unless the queries are all 20-30 msec queries to
begin with that only select a few rows.

<< Next.... optimizing our queries.... if only we can figure out how to do
this in DBISAM....(we know how in SQL Server...  but can't find the profiler
tool in DBISAM). >>

As Johnnie indicated, just run the query in question in the DBSYS utility
with the Generate Plan check box checked.  Then check the Plan tab to see
what DBISAM indicates is going on with the query.  If you have a question
about a particular plan, feel free to post it and we'll help you out with
any possible optimizations.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Nov 9 2006 4:36 PMPermanent Link

Sam Jones
<<Are you sure that your application is accessing the data via the server and
not still directly via the Win32 API ?  There should be at least a small
improvement in the speed, unless the queries are all 20-30 msec queries to
begin with that only select a few rows.>>

Our tests shows no benefit at all in using the dbisam server, and in a couple of our tests
the server was slower than direct by a factor of 2 or 3.

However, now that I think about it, the test was not valid.

This was our test bed:

a)  Local reads (system is a VMWare guest system running on a dual processor dual core
3ghz XEON system  [that is four cores each with 2mb cache])

b)  Network file system: App is running local above, database is across a 10mbit ether net
on another VMWare guest on a a 2.8 ghz single cpu box

c)  DBISAM Server: Runs on the same system as 'b' above


The problem here is that we have our tests skewed. The 'a' tests ALWAYS just flew. So none
of our other tests were going to show an improvement over that.

We really need all the hardware to be the same.

We will rerun this suite of tests.
Fri, Nov 10 2006 4:10 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Sam,

<< Our tests shows no benefit at all in using the dbisam server, and in a
couple of our tests the server was slower than direct by a factor of 2 or 3.

However, now that I think about it, the test was not valid.

This was our test bed: >>

Yes, you need to test the execution of the queries on an equivalent box or
you won't get the accurate results.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image