After moving clients from Server-2008 to Server-2016, I received
complaints about the slowness of the new server.  I've created a
simple test timing writing 100K records into a small table and then
seek and read each record.  I've run this test under same conditions
on the servers listed in the attachement.

While initializing a session on Server-2016 is significantly faster
with SSD, the SSD database performance is similar to the 15K RPM HDD.
The performance of Server-2008 is significantly better than
Server-2016.

Interesting Looks like you are saturating the network maybe..

Any difference in cache setup???

Also with multiple uses locking/unlocking of index files make a major 
negative contribution to speed



On 7/19/19 5:36 PM, Itai Ben-Artzi wrote:
> After moving clients from Server-2008 to Server-2016, I received
> complaints about the slowness of the new server.  I've created a
> simple test timing writing 100K records into a small table and then
> seek and read each record.  I've run this test under same conditions
> on the servers listed in the attachement.
> 
> While initializing a session on Server-2016 is significantly faster
> with SSD, the SSD database performance is similar to the 15K RPM HDD.
> The performance of Server-2008 is significantly better than
> Server-2016.
>

James,
It is not the network, but I've discovered that filtered table is
significantly slower on Server-2016.  The work-around this slowness is
to avoid filtering and instead, evaluate each record for the
conditions set in the filter.  Apparently, Alaska's filter is much
slower on Server-2016 than reading an entire table and skip records
that do not meet required conditions.

-Itai

> Apparently, Alaska's filter is much slower on Server-2016 than reading an
> entire table and skip records  that do not meet required conditions.

can you give an Example how your filter look like ?

OPTIMZE ON/OFF ?



---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com

Jim,
Rushmore and optimize are off because they were buggy and Alaska
recommended not to use them (BTW, is the status of these technologies
changed with recent updates?).
SMARTFILTER remains on by default.
I set the filter with:
DbSetFilter( &bFilter, cFilter )

The same EXE runs faster on Terminal-Server-2008 and significantly
slower on Terminal-Server-2016.

-Itai

Hi:
good morning.
I always use OrdCondSet() for filtering. It is very fast. After the use 
I destroy the created index.

Fraternally
Beling


Em 17/08/2019 03:41, Itai Ben-Artzi escreveu:
> Jim,
> Rushmore and optimize are off because they were buggy and Alaska
> recommended not to use them (BTW, is the status of these technologies
> changed with recent updates?).
> SMARTFILTER remains on by default.
> I set the filter with:
> DbSetFilter( &bFilter, cFilter )
> 
> The same EXE runs faster on Terminal-Server-2008 and significantly
> slower on Terminal-Server-2016.
> 
> -Itai
>

Good idea, Carlos, thank you!
The documentation is not clear on this function.  What happens when I
use <bForCondition>?
Does DbGoTop() goes to the top of the table or top of index?  Does
EOF() reached at the end of the index or the end of the table?

As  rule I avoid general filters on any table larger then 10K When 
needed I try to use scopes instead (much faster But you must have an 
appropriate index). Also if you can set a scope to get a partial subset 
then filter you can reduce the skipped records.

Jim

On 8/18/19 5:00 AM, Itai Ben-Artzi wrote:
> Good idea, Carlos, thank you!
> The documentation is not clear on this function.  What happens when I
> use <bForCondition>?
> Does DbGoTop() goes to the top of the table or top of index?  Does
> EOF() reached at the end of the index or the end of the table?
>

James,
I use the filter for the more complex user selection (otherwise, I
have to maintain too many indexes for too many tables/files). Needless
to say, if a pertaining index already exists, it is used instead of a
filter.
All was working well till I switched hosting from Server-2008 to
Server-2016.  Apparently, reading and writing on terminal-server-2016
is significantly slower than reading/writing on terminal-server-2008.

Server-2008 delivers better performance and better compatibility with
xBase (and Cristal Reports).  Regrettably, Microsoft discontinued
Server-2008 and forced us into the inferior Server-2016 or
Server-2019.  It seems that promoting the Azure technology is traded
for inferior performance of traditional 32-bits application such as
xBase++.

-Itai

Hello Itai.
The <bForCondition> filters the records to be inserted in the index when 
returns <bForCondition> returns .t.
After the index is created everything works as the database having only
records which the <bForCondition> returned .t.

I use the index command like this, using DBFCDX:
DbGoTo(1)
index on    MyKeyExpression;
       tag   TagName;
       to    IndexFileName;
       for   {|| forcondition}  may to be a function ie: 
ConditionForInsertTheRecord

Fraternally
Belinh


Em 18/08/2019 06:00, Itai Ben-Artzi escreveu:
> Good idea, Carlos, thank you!
> The documentation is not clear on this function.  What happens when I
> use <bForCondition>?
> Does DbGoTop() goes to the top of the table or top of index?  Does
> EOF() reached at the end of the index or the end of the table?
>

Thank you, Carlos.
Alaska should add this into the documentation.
-Itai