Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 11 to 20 of 26 total |
CS Performance Problem from Remote Site |
Mon, Apr 28 2008 8:44 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< No. The customer decided to perform some additional functions while recording the log. I assumed that if there was a problem, it would jump out as a long delay in the log itself. I can have him generate it again with just the startup and shut down, or is there a way to programatically stop the log once the application as completed the startup process. >> The issue isn't one of a particular request taking a long time, but the result of many requests causing too much latency due to the request/response cycle. There's a lot of chatter in there, but I need to know where the application startup stops so that I can determine how much is unnecessary chatter. One thing I see, for example, is a lot of calls to the Exists method and a lot of calls to properties on tables when the table isn't actually open. I assume that these are calls for structure and version checking, etc. You may want to consider moving these to the actualy server itself, because there isn't really a need to have each application startup check these things when the server actually controls them anyways. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Apr 28 2008 9:25 AM | Permanent Link |
Gordon Turner | Tim Young [Elevate Software] wrote:
> > The issue isn't one of a particular request taking a long time, but the > result of many requests causing too much latency due to the request/response > cycle. There's a lot of chatter in there, but I need to know where the > application startup stops so that I can determine how much is unnecessary > chatter. One thing I see, for example, is a lot of calls to the Exists > method and a lot of calls to properties on tables when the table isn't > actually open. I assume that these are calls for structure and version > checking, etc. You may want to consider moving these to the actualy server > itself, because there isn't really a need to have each application startup > check these things when the server actually controls them anyways. The app was "ported" from the shared file version of the program, and so it checks to see if the tables exist during start up. If not, a screen is displayed so the customer can re-create any missing files. Any changes to the database structure (new fields or indexes due to an update) are also performed at this time. So, in general, to move this code to the server, I would create a procedure (CheckDBFiles) that would perform this process and send a message back to the client in a RemoteParm value. Is this correct? -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Mon, Apr 28 2008 2:04 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< So, in general, to move this code to the server, I would create a procedure (CheckDBFiles) that would perform this process and send a message back to the client in a RemoteParm value. Is this correct? >> You could do it that way, or simply have the server check at startup time in the FormCreate for the main form of the server. The benefit of doing it at server startup time, is that it is done once and that's it. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Apr 29 2008 5:26 PM | Permanent Link |
Gordon Turner | As I'm looking into this deeper with the customer, application startup
is only part of the problem. The program does a group of calculations that perform a number of database queries. Since it's all using shared file commands (rather than SQL commands) I'm not sure exactly how much network traffic there is between the client and the server. I'm using the FindKey, FieldByName, and Filter properties to retrieve data and perform the calculation. But I'm not sure how these commands translate to networking requests of the database server. But at about 63 msecs per REQUEST_something, the time to perform my calculations can add up rapidly. (Over a 100MB LAN in shared file mode, it takes a second or two.) So for those of you who are doing CS applications over a WAN, how do you handle database intensive calculations and still get good response time from the user perspective? (A rule based calculation where the rules are stored in tables, earned vacation time for example.) -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Wed, Apr 30 2008 11:06 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
< I'm using the FindKey, FieldByName, and Filter properties to retrieve data and perform the calculation. But I'm not sure how these commands translate to networking requests of the database server. But at about 63 msecs per REQUEST_something, the time to perform my calculations can add up rapidly. (Over a 100MB LAN in shared file mode, it takes a second or two.) >> FieldByName won't be an issue, but FindKey or modifying the Filter property will result in one or more messages to and from the server. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Apr 30 2008 3:22 PM | Permanent Link |
Gordon Turner | Tim Young [Elevate Software] wrote:
> > FieldByName won't be an issue, but FindKey or modifying the Filter property > will result in one or more messages to and from the server. Just so I understand more, in the CS version, the FindKey is the equivalent of select * from table where keyvalue = x. Is that why the FieldByName doesn't send messages? -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Wed, Apr 30 2008 3:48 PM | Permanent Link |
Gordon Turner | Tim Young [Elevate Software] wrote:
> > FieldByName won't be an issue, but FindKey or modifying the Filter property > will result in one or more messages to and from the server. I ran the log for the kind of calculation I was referring to, and there were 913 Request/Reply pairs for that process. Locally, the delay time was usually less than a msec, but over a WAN with some latency, performance would plummet. -- Gordon Turner Mycroft Computing http://www.mycroftcomputing.com |
Wed, Apr 30 2008 4:17 PM | Permanent Link |
Sean McCall | FieldByName is a method of TDataset. It just finds the TField in
TDataset.Fields with the passed name. Sean Gordon Turner wrote: > Tim Young [Elevate Software] wrote: >> >> FieldByName won't be an issue, but FindKey or modifying the Filter >> property will result in one or more messages to and from the server. > > Just so I understand more, in the CS version, the FindKey is the > equivalent of select * from table where keyvalue = x. Is that why the > FieldByName doesn't send messages? > |
Thu, May 1 2008 6:33 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Gordon,
<< Just so I understand more, in the CS version, the FindKey is the equivalent of select * from table where keyvalue = x. >> Well, it's a little more direct than that and there isn't any SQL involved, but yes, that's the general idea. << Is that why the FieldByName doesn't send messages? >> FieldByName is a standard method, as Sean indicated, and works by using one of the record buffers that has already been retrieved from the server, hence it doesn't need to make any requests to the server. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, May 1 2008 8:27 AM | Permanent Link |
"John Hay" | Gordon
> So for those of you who are doing CS applications over a WAN, how do you > handle database intensive calculations and still get good response time > from the user perspective? (A rule based calculation where the rules > are stored in tables, earned vacation time for example.) I am just going through a very similar excercise to you. In my case I would have a process like (psudeocode) Person.First; While not Person.Eof do begin if Allowances.Findkey([Person.AllowanceType]) then begin Person.Edit; Person.Allowance := <calc involving person and allowance record> Person.Post; end; Person.Next; end; Changing it to a query which went UPDATE Person SET Allowance = <calc involving person and allowance record> FROM Person JOIN Allowances ON Person.AllowanceType=Allowances.AllowanceType cut the chat down to nearly zero and gave a huge speed increase. If your calcs are to complicated for an SQL statement you might need to create a server side procedure. Cheers John |
« Previous Page | Page 2 of 3 | Next Page » |
Jump to Page: 1 2 3 |
This web page was last updated on Tuesday, May 7, 2024 at 06:25 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |