You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
When restoring data gbak sends each record to firebird engine one by one. That's not too bad with embedded connection but when network is involved performance losses are dramatic, specially in WAN case. Batch API is designed to solve such problems and should be used in gbak.
The text was updated successfully, but these errors were encountered:
With gbak using batch API performance difference when restoring database using embedded vs. network connection is almost gone - instead at least 2X difference, present even with localhost connections, with batches we have about 5-7% performance difference (also localhost vs. embedded connection). That's obvious result of increasing network packet size.
Improvement did not cause any changes in use of gbak (i.e. no new switches, no changes in old one).
I agree it's very efficient - I've specially added intermediate buffer for that stream in services manager. But doesn't require any changes in switches? What about -se switch? And dividing database name in 2 parts?
To be precise IBatch is first step in this direction, in next FB version we plan to have pipe interface which will not be limited with JDBC restrictions and will provide exactly same performance as services do now but available for generic usage, not only backups.