Subject | Re: [IBO] Performance.. |
---|---|
Author | Larry Baddock |
Post date | 2008-08-27T07:06:54Z |
Hi.
Run the app, and Just see over a period of about 5 mins where the CPU time is spent, with the Windows task manager, or profiler, and get an idea as to the Database / App CPU load split.
IF you are spending more than, say, 40 to 50% of the USED processor time in your app, as opposed to the database, then:
(X) don't walk, RUN over to www.automatedqa.com, and get yourself a copy of AQTime. Will tell you what you want to know without mucking about. Come to think of it, this probably be your first step anyway. Don't guess where the issue is - just find out.
You say that you are using TIB_Cursor instead of TIB_Query. If the initial setup time (ie:Cursor open to first record produced) is high, you do NOT have to reopen the TIB_Cursor/Transaction for every pass. Assuming you don't mind long-running transactions hanging about, you can reuse the SAME TIB_Cursor/Transaction combo for multiple iterations. TIB_Cursor is indeed unidirectional, but ".First;" is still perfectly legit to gut to the top of the data stream for the next pass. This may help. YMMV.
IF All else fails (More than likely disk bound problem), then:
(Option 1): don't walk, RUN to your local hardware store, and buy 16GB ram (or whatever, so that your ENTIRE database fits in RAM EASILY, with lots of room to spare), and put a Linux distro on it, and firebird. The OS disk cache makes a MASSIVE difference. (If you choose a 23 bit distro, make sure you use a PAE kernel). If you want to reduce network latency between Windows app and Firebird on Linux, etc etc (Which you do), then just run your windows app on a VMWare virtual machine running on the Linux box. This solution (assuming you can get enough ram into the machine for given database size) is a HELL of a lot cheaper than a fancy disk setup will be, and a hell of a lot faster, too.
(Option 2): Dig deep into your pocket (or wait 6 months), and buy a SATA Solid State Disk to put the database on, which supports NCQ.
Hope this helps.
Larry
[Non-text portions of this message have been removed]
>If you are using Delphi, here are some things you can tryThere is an easier way...
>
>Connection.BeginBusy(True);
>query.DisableControls;
>try
>---- process code here
>finally
>Connection.EndBusy;
>query.EnableControls;
>end;
Run the app, and Just see over a period of about 5 mins where the CPU time is spent, with the Windows task manager, or profiler, and get an idea as to the Database / App CPU load split.
IF you are spending more than, say, 40 to 50% of the USED processor time in your app, as opposed to the database, then:
(X) don't walk, RUN over to www.automatedqa.com, and get yourself a copy of AQTime. Will tell you what you want to know without mucking about. Come to think of it, this probably be your first step anyway. Don't guess where the issue is - just find out.
You say that you are using TIB_Cursor instead of TIB_Query. If the initial setup time (ie:Cursor open to first record produced) is high, you do NOT have to reopen the TIB_Cursor/Transaction for every pass. Assuming you don't mind long-running transactions hanging about, you can reuse the SAME TIB_Cursor/Transaction combo for multiple iterations. TIB_Cursor is indeed unidirectional, but ".First;" is still perfectly legit to gut to the top of the data stream for the next pass. This may help. YMMV.
IF All else fails (More than likely disk bound problem), then:
(Option 1): don't walk, RUN to your local hardware store, and buy 16GB ram (or whatever, so that your ENTIRE database fits in RAM EASILY, with lots of room to spare), and put a Linux distro on it, and firebird. The OS disk cache makes a MASSIVE difference. (If you choose a 23 bit distro, make sure you use a PAE kernel). If you want to reduce network latency between Windows app and Firebird on Linux, etc etc (Which you do), then just run your windows app on a VMWare virtual machine running on the Linux box. This solution (assuming you can get enough ram into the machine for given database size) is a HELL of a lot cheaper than a fancy disk setup will be, and a hell of a lot faster, too.
(Option 2): Dig deep into your pocket (or wait 6 months), and buy a SATA Solid State Disk to put the database on, which supports NCQ.
Hope this helps.
Larry
[Non-text portions of this message have been removed]