Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 5 of 5 total
Thread optimize tables, speed up C/S
Tue, Mar 14 2006 6:37 AMPermanent Link

"Santy Concepción"
Hi!

We have started to test the application on C/S environment over Internet.
Two computers, 1MB DSL on both sides.

The connection is stablished correctly, but some EMPTY tables takes about 2
seconds to open or Refresh.
I thinkt it is normal, isn't it? Or should it take less time to open them?

If I make a Table.Refresh it takes about 1 or 2 seconds too.
2 seconds is not bad, but the table is empty. What about when the tabe
contains 50.000 records?

So the question...
Are there any tricks, tips, etc... to speed up the table opening or
refreshing?
Something like opening after filtering, etc...?

And another important question...
The computer that will act as "Server" and contains the Tables... has to
access the Tables in C/S mode, or can it access them in Local mode?

Thanks!!

Tue, Mar 14 2006 9:21 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Santy

And another important question...
The computer that will act as "Server" and contains the Tables... has to
access the Tables in C/S mode, or can it access them in Local mode?


Most of it I can't answer, but you can have any mixture you like of local and client/server access to your tables so YES.

Roy Lambert
Tue, Mar 14 2006 1:50 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Santy,

<< The connection is stablished correctly, but some EMPTY tables takes about
2 seconds to open or Refresh. I thinkt it is normal, isn't it? Or should it
take less time to open them? >>

Do you have any lookup tables or calculated fields defined ?  Those are the
real performance killers in most cases.  A lot of lookup fields cause a lot
of round-trip calls (request/response) to the database server, and the
network latency is very time-consuming with TCP/IP and the Internet.

<< If I make a Table.Refresh it takes about 1 or 2 seconds too.  2 seconds
is not bad, but the table is empty. What about when the tabe
contains 50.000 records?  >>

The table size is irrelevant when it comes to C/S access.

<< The computer that will act as "Server" and contains the Tables... has to
access the Tables in C/S mode, or can it access them in Local mode? >>

It can access them in local mode.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Mar 14 2006 3:26 PMPermanent Link

"Santy Concepción"
Hi, Tim...

> Do you have any lookup tables or calculated fields defined ?  Those are
> the real performance killers in most cases.  A lot of lookup fields cause
> a lot of round-trip calls (request/response) to the database server, and
> the network latency is very time-consuming with TCP/IP and the Internet.

No, the table doesn't contain any Lookup or Calculated Fields, and BTW, the
table is Empty.

The only "rare" thing I'm doing is opening the table "filtered" but without
"filter", like the following:
Table1.Filter := '';
Table1.Filtered := True;
Table1.Open;

> The table size is irrelevant when it comes to C/S access.

Ok.

> << The computer that will act as "Server" and contains the Tables... has
> to access the Tables in C/S mode, or can it access them in Local mode? >>

Ok, Thanks!

Tue, Mar 14 2006 4:39 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Santy,

<< No, the table doesn't contain any Lookup or Calculated Fields, and BTW,
the table is Empty. >>

Okay, the next step then is to turn on the remote tracing via the
TDBISAMSession.RemoteTrace property.  Then use the OnRemoteTrace event
handler to log the trace messages.  You can use this event handler (from
DBSYS) to translate the trace messages into text and write them to a text
file (previously opened):

procedure TMainForm.RemoteSessionRemoteTrace(Sender: TObject;
                                            TraceRecord: TTraceRecord);
var
  TempString: string;
begin
  with TraceRecord do
     begin
     TempString:=PadRight(DateTimeToStr(DateTime),24,' ');
     case EventType of
        teConnect:
           TempString:=TempString+' '+PadRight('Connect',10,' ')+
                                  ' '+PadRight(IntToStr(ElapsedTime)+'
msecs',16,' ');
        teReconnect:
           TempString:=TempString+' '+PadRight('Re-connect',10,' ')+
                                  ' '+PadRight(IntToStr(ElapsedTime)+'
msecs',16,' ');
        teDisconnect:
           TempString:=TempString+' '+PadRight('Disconnect',10,' ')+
                                  ' '+PadRight(IntToStr(ElapsedTime)+'
msecs',16,' ');
        teRequest:
           TempString:=TempString+' '+PadRight('Request',10,' ')+
                                  ' '+PadRight(IntToStr(ElapsedTime)+'
msecs',16,' ')+
                                  ' '+PadRight(RemoteRequestName,30,' ')+
                                  '
'+PadRight(IntToStr(RemoteRequestSize)+' bytes',16,' ');
        teReply:
           TempString:=TempString+' '+PadRight('Reply',10,' ')+
                                  ' '+PadRight(IntToStr(ElapsedTime)+'
msecs',16,' ')+
                                  ' '+PadRight(RemoteReplyResultName,30,'
')+
                                  ' '+PadRight(IntToStr(RemoteReplySize)+'
bytes',16,' ');
        end;
     end;
  WriteLn(TraceLogFile,TempString);
end;

Here are the procedures for dealing with the log file:

procedure TMainForm.OpenLogFile;
begin
  System.AssignFile(TraceLogFile,LogFileName);
  if FileExists(LogFileName) then
     System.Append(TraceLogFile)
  else
     System.Rewrite(TraceLogFile);
end;

procedure TMainForm.CloseLogFile;
begin
  System.CloseFile(TraceLogFile);
end;

procedure TMainForm.RemoveLogFile;
begin
  SysUtils.DeleteFile(LogFileName);
end;

and the TraceLogFile variable is declared as this:

   TraceLogFile: TextFile;

If you could then send me this log file, it would shed some light on the
situation because it gives me exactly what server calls are being made and
the time taken to perform each one.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image