Issue Details (XML | Word | Printable)

Key: CORE-5952
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Enhance restore performance of GBAK using batch API

Created: 25/Oct/18 11:03 AM   Updated: 25/Oct/18 01:05 PM
Component/s: GBAK
Affects Version/s: 4.0 Initial
Fix Version/s: 4.0 Alpha 1

Issue Links:
Relate
 

QA Status: No test


 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 25/Oct/18 11:09 AM - edited
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).

Dimitry Sibiryakov added a comment - 25/Oct/18 11:58 AM
Sending of backup stream to services API can be even more effective and also doesn't require any changes in switches, etc.

Alexander Peshkov added a comment - 25/Oct/18 01:05 PM
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.