| Firebird Documentation Index → Firebird 2.1 Release Notes → Global Improvements in Firebird 2.1 → Remote Interface Improvements |
|
|
|
The remote protocol has been slightly improved to perform better in slow networks. In order to achieve this, more advanced packets batching is now performed, along with some buffer transmission optimizations. In a real world test scenario, these changes showed about 50 per cent fewer API round trips, thus incurring about 40 per cent fewer TCP roundtrips.
In Firebird 2.1 the remote interface limits the packet size of the response to various isc_XXX_info calls to the real used length of the contained data, whereas before it sent the full specified buffer back to the client buffer, even if only 10 bytes were actually filled. Firebird 2.1 remote interface sends back only 10 bytes in this case.
Some of our users should see a benefit from the changes, especially two-tier clients accessing databases over the Internet.
The changes can be summarised as
Batched packets delivery. Requires both server and client of version v2.1, enabled upon a successful protocol handshake. Delays sending packets of certain types which can be deferred for batched transfer with the next packet. (Allocate/deallocate statement operations come into this category, for example.)
Pre-fetching some pieces of information about a statement or request and caching them on the client side for (probable) following API calls. Implemented on the client side only, but relies partly on the benefits of reduced round trips described in (a).
It works with any server version, even possibly providing a small benefit for badly written client applications, although best performance is not to be expected if the client is communicating with a pre-V.2.1 server.
Reduced information responses from the engine (no trailing zeroes). As the implementation is server-side only, it requires a V.2.1 server and any client. Even old clients will work with Firebird 2.1 and see some benefit from the reduction of round trips, although the old remote interface, unlike the new, will still send back big packets for isc_dsql_prepare().
Another round-trip saver, termed “defer execute”, whereby
SELECT requests will be held at the point just before execution of
the isc_dsql_execute until the next API call on the
same statement. The benefit of the saved round-trip becomes most
visible where there is a bunch of SELECT requests whose result set fits into
one or two network packets.
This enhancement takes effect only if both client and server are v.2.1 or higher.
A faintly possible side-effect is that, if
isc_dsql_execute should happen to fail with a certain
exception, this exception is returned to the client in the response to the
API call that was actually responsible; i.e., instead
of being returned by isc_dsql_execute it would be returned by
isc_dsql_fetch, isc_dsql_info, or
whichever API call actually dispatched the op_execute
call.
In most cases, the side-effect would be transparent: it might show up in a case where some error occurred with default values for PSQL parameters or variables and would be noticed as an exception array where the exceptions were delivered in an unusual sequence.
The changes work with either TCP/IP or NetBEUI. They are backward-compatible, so existing client code will not be broken. However, when you are using a driver layer that implements its own interpretation of the remote protocol—such as the Jaybird JDBC and the FirebirdClient .NET drivers—your existing code will not enable the enhancements unless you usedrivers are updated.
|
| Firebird Documentation Index → Firebird 2.1 Release Notes → Global Improvements in Firebird 2.1 → Remote Interface Improvements |