August 13th, 2011, 09:25 AM
Firebird too slow on multi user application
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
August 15th, 2011, 01:58 AM
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 02:06 AM.
August 15th, 2011, 06:58 AM
mIRCata, thank you for your answer.
My Transaction.DefaultAction = TACommit. and the way I used is as following:
UPDATE Table1 SET FIELD1 = :val1 WHERE (ID = :val2)
on E: Exception do Trans1.Rollback;
Am I using the Transaction properly? Any comment would be a great help.
September 14th, 2011, 08:47 PM
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
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.
October 28th, 2011, 11:05 AM
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.
Originally Posted by cantemmuz
It will be easy to switch from IBX to UIB.
November 12th, 2011, 05:21 AM
I have some performance problems too.
Please read this:
If you start redesigning you application:
Consider MySql and PostgreSQL instead of Firebird
August 15th, 2012, 02:14 PM
FIBPlus 7.3 from Devrace
Firstly, try to use 2 transactions for your projects.
DataSet.TransactionRead and TransactionWrite properties.
FibPlus, UniDAC, and others, can to use it.
So (FIBPlus example)
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
isc_tpb_write <-- READ and WRITE
Look at this for better explanation:
So, one just READ and another, just WRITE the transactions (updates) not commited.