Enhance restore performance of GBAK using batch API [CORE5952]

[firebird-automations]

Submitted by: @AlexPeshkoff

Is related to CORE5951

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.

[firebird-automations]

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

[firebird-automations]

Modified by: @AlexPeshkoff

Link: This issue is related to CORE5951 [ CORE5951 ]

[firebird-automations]

Commented by: @AlexPeshkoff

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).

[firebird-automations]

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

[firebird-automations]

Commented by: @aafemt

Sending of backup stream to services API can be even more effective and also doesn't require any changes in switches, etc.

[firebird-automations]

Commented by: @AlexPeshkoff

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.