Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 5 of 5 total |
optimize tables, speed up C/S |
Tue, Mar 14 2006 6:37 AM | Permanent 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |