Subject | Re: [firebird-support] Strange performance problems |
---|---|
Author | Rafael Szuminski |
Post date | 2003-12-04T22:02:41Z |
I have many clients running 100 MB databases with Win98 with 64-128 MB ram
without any issues. I would say a transaction lock of some sort is your issue here.
I have run into this many times with IB6 and IBExpert. If I open a table for
edit in IBExpert and dont commit the transaction and my application tries to
read that record, my app will just sit there and wait until I commit or rollback
the edit.
I can't remember if I could duplicate this issue with IBConsol.
Btw, can you duplicate the behavior by running a script in IBConsole that mimics
your application behavior?
Raf
Tim Ledgerwood wrote:
Rafael Szuminski
Email:raf@...
Phone:(949)939 - 2458
www.BDCSoftware.com
without any issues. I would say a transaction lock of some sort is your issue here.
I have run into this many times with IB6 and IBExpert. If I open a table for
edit in IBExpert and dont commit the transaction and my application tries to
read that record, my app will just sit there and wait until I commit or rollback
the edit.
I can't remember if I could duplicate this issue with IBConsol.
Btw, can you duplicate the behavior by running a script in IBConsole that mimics
your application behavior?
Raf
Tim Ledgerwood wrote:
> Hi all,--
>
> we are experiencing very strange performance problems with our production
> databases.
>
> Our application runs on Interbase 6.02, and is a POS system for service
> (petrol and diesel) stations. As such, it inserts new transactions and
> commits them, gathers the sale data from the POS, then updates the inserted
> sale with the POS data. Finally, when the client settles the amount owing,
> the application inserts the amount tendered as a transaction.
>
> We have had complaints that the updating of the transaction and the
> inserting of the amount tendered (the two form part of one database
> transaction) sometimes take up to 30 seconds, which is unacceptable to our
> clients.
>
> The clients' computer (in this case) is running Windows 98 SP2, with 64 MB RAM.
>
> I get similar response times on my computer, which is running Windows 2000
> professional SP 2, with 128 MB RAM.
>
> Forced writes are ON in all cases.
>
> The applications are written in D5, using IB Express components.
>
> My first avenue of approach was to examine the Delphi Code. I noticed that
> running the stored procedures that do the inserts and updates takes about 2
> hundredths of a second. So I thought that the code was the problem - I
> noticed, for example, that there is no prepare of the stored procedures.
>
> However, our test center was also testing the application at the same time.
>
> On one test machine, running W98 SP 2 with 64 MB RAM, the response time is
> about 5 seconds. On another machine, a laptop running Windows XP with 128
> MB RAM, the response time is about 3 seconds. On yet another machine,
> running Windows XP with 64 MB RAM, the response time was 30 seconds. When
> we upgraded the RAM to 256 MB, the response time improved to 3 seconds.
> When we downgraded the RAM back to 64 MB, the response time was 15 seconds.
>
> I am sorry if this sounds confusing. It confused me too. :-)
>
> I must admit that I have no idea of where or how to start looking for the
> problem, or how to solve it. I don't want to recommend simply upgrading the
> memory, unless that really is the problem.
>
> In all cases, the machines are running the same version of Interbase -
> version 1.0.0.336 - the old 6.02 Open Source version.
>
> In all cases, the machines are running the same version of the software,
> and the same version of the GDB files.
>
> Anybody have any idea of what I should be looking for?
>
> Regards
>
> Tim
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To unsubscribe from this group, send an email to:
> firebird-support-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
Rafael Szuminski
Email:raf@...
Phone:(949)939 - 2458
www.BDCSoftware.com