#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2011
    Posts
    2
    Rep Power
    0

    Firebird too slow on multi user application


    Hi All,
    I used FireBird in the past locally and had no problems at all. On the other hand, this is the first time I'm developing multi user DB application and obviously I'm doing something wrong. If I run my app. locally on my pc there seems no problem, my inserts, updates usually take a second and again if I connect to DB thru the network then this takes 2-3 seconds at most.

    However when 4-5 user starts using the application at the same time, then it takes about 10 secs., sometiimes it's forever. They just stuck and they have to go ctrl-alt-del. Usually a user inserts / updates 100 records (with 10 columns) at most.

    I'm frustrated, after having this multi user - multi headache, I'm now at the edge of moving to MySQL (never used though and I'm not sure if it would be a solution either).

    This is the confuguration:
    Server: A fast Win2003 server (they are running MS SQL server "without any trouble") and I installed Firebird 2.5 SuperServer

    Clients: winXP, or Win7

    Developed with Delphi and IBX comps.

    I would be greatly appreciated on any clue
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2006
    Location
    Plovdiv. Bulgaria
    Posts
    226
    Rep Power
    13
    If you use "wait" transactions maybe you have lock conflicts and FB waits the previous transaction to finish its work. And if your app doesn't commit the work right after it did the changes, but lets say when the user closes some window or message dialog that may be open for an hour or two there will be lock conflicts when another user tries to change the same records.
    We need more information about how your app works.

    So first check your transactions' options. If they are "wait" transactions make them "no wait" to test when your app will throw lock conflict exceptions so you can catch problems in app's logic. You can always change them to wait again if you need them to be that way.
    Also make sure that when you begin to do changes in the database there is no breaks in the process - like confirmation messages, stopping for some input from the user etc. And right after the changes you must commit or rollback the work.
    Last edited by mIRCata; August 15th, 2011 at 03:06 AM.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2011
    Posts
    2
    Rep Power
    0
    mIRCata, thank you for your answer.
    My Transaction.DefaultAction = TACommit. and the way I used is as following:

    try
    try

    Trans1.StartTransaction;

    UPDATE Table1 SET FIELD1 = :val1 WHERE (ID = :val2)
    .......
    ExecSql;
    Trans1.Commit;

    except
    on E: Exception do Trans1.Rollback;
    end;

    finally
    Trans1.Active:= False;
    end;

    Am I using the Transaction properly? Any comment would be a great help.

    thanks
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2010
    Posts
    52
    Rep Power
    5
    I dont know too much about using transactions, my app is all in php, but I have max 30 employees accessing and adding to the database at any time, not to mention all the web traffic from our website accessing the same database.

    When I was first creating it I noticed it got slower the more people used it, if I remember correctly, I fixed it by switching from a superserver to a classic server when reinstalling firebird.

    if you look here

    http://firebirdsql.org/manual/ufb-about-arch.html

    it explains the difference between the two, including the main reasons to choose one or the other

    • A single application running on the same machine as the server is faster with the Classic architecture.
    • For a Linux application embedded in an appliance, Classic is better, because it provides a single process from application to disk.
    • On a single-processor machine, an application with larger numbers of frequently contending clients is faster with Superserver, because of the shared cache.
    • On multi processor machines, small numbers of clients whose data updates do not impact others' tasks work better in the Classic architecture.
    I love my work!! Mid Fifty F-100 Parts
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2004
    Location
    Sarajevo, Bosnia
    Posts
    120
    Rep Power
    14
    Originally Posted by cantemmuz
    This is the confuguration:
    Server: A fast Win2003 server (they are running MS SQL server "without any trouble") and I installed Firebird 2.5 SuperServer

    Clients: winXP, or Win7

    Developed with Delphi and IBX comps.
    Is this Multu-CPU server? If yes, install firebird super-classic 2.5.1 and use UIB components, so you can fully use firebird power. IBX is not supported with Firebird at all, it may - but doesn't have to work.
    It will be easy to switch from IBX to UIB.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Nov 2009
    Posts
    74
    Rep Power
    6
    I have some performance problems too.

    Please read this:

    http://www.ib-aid.com/articles/item65

    If you start redesigning you application:

    Consider MySql and PostgreSQL instead of Firebird
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2008
    Posts
    55
    Rep Power
    7

    Thumbs up FIBPlus 7.3 from Devrace


    Dear friends,

    Firstly, try to use 2 transactions for your projects.

    Example:

    DataSet.TransactionRead and TransactionWrite properties.

    FibPlus, UniDAC, and others, can to use it.

    So (FIBPlus example)

    Transaction.READONLY ==>
    isc_tpb_read <-- READONLY
    isc_tpb_nowait <--dont wait one lock or deadlock
    isc_tpb_rec_version <-- just only last version commited
    isc_tpb_read_committed <-- read the others transactions update

    Transaction.READWRITE ==>
    isc_tpb_write <-- READ and WRITE
    isc_tpb_nowait
    isc_tpb_rec_version

    Look at this for better explanation:
    http://www.devrace.com/en/fibplus/articles/3286.php


    So, one just READ and another, just WRITE the transactions (updates) not commited.

IMN logo majestic logo threadwatch logo seochat tools logo