Net Latency and Firebird Performance

Historically, firebird performance, like most database servers, has been mostly held back by disc and cpu performance. Modern SMP processors and PCI-E based disc sub-systems have eliminated many of the traditional bottlenecks for database servers. But as bottlenecks are removed new ones open up. And as more server deployments are moving to the cloud it is worth investigating the impact of network latency upon Firebird performance.

Lets start with a baseline - 10 Warehouses and 10 Terminals

In this section we will look at the changes in as latency increases in 100 micro-second increments starting from zero latency. That is to say we are looking at very small amounts of latency.

Let’s spin the data around and look at the the impact of network latency on the relation between New Orders and the number of terminals. First, when latency is counted in milliseconds:

For Classic and Super Classic there appears to be a correlation between net latency and number of terminals. The impact of net latency can be offset by adding terminals (ie, increasing the size of the connection pool). But this eventually tops out and adding too many terminals will see performance start to fall. But this effect is hardly noticeable with Super Server. Although it is counter-intuitive it looks as if adding connections to the pool would be a good solution for CS and SC under these circumstances.

If we turn to look at the results when net latency can be measured in micro-seconds we see a similar picture:

Because net latency is minimal the effect of adding terminals is less dramatic. However the performance boost is sufficient to make it worth while.

Network latency is a thing, and in the absence of other bottlenecks will have an impact on performance. In general this impact is fairly low, as long as the latency can be measured in micro-seconds. But…​.

It is clear that as network latency increases performance decreases. Let’s see what happens:

Blobs present a problem as far as network latency is concerned. The Firebird network protocol will pull result sets in batches of rows. So while there are several exchanges between the server and client in a single sql request this will ultimately result in as many rows as can be fitted in each packet. But blobs are retrieved separately and each blob requires several exchanges to set up the transmission. This can have an exponential effect on the number of packets that are sent. A result set of ten rows, each with a single blob will see approximately ten times the number of packets exchanged across the network and this is before we even consider the size of the blobs themselves.

The benchmark we have used does not include blobs so the above graphs do not give us any idea about the performance impact of blobs on net latency. This will be the subject of a future article.

This benchmark only tells us that data throughput is reduced. It doesn’t tell us how the user experiences the latency. The benchmark has some data on this but it is awaiting detailed analysis. This will also be the subject of a future article.

The problem of net latency highlights the limits of the client server model. If network latency is a problem then a three tier structure is recommended. The middle tier should be as physically close to the server as possible and should manage user requests, rather than the server receiving them directly. This model is typically deployed as a web interface, although that is not the only way to implement a middle tier.

As usual with synthetic benchmarks this data and the conclusions should be taken with a pinch of salt. The results apply to the specific combination of hardware, software and test bench. Other configurations will provide different results. However, the results also confirm the hypothesis and are in line both with previous experience and expectations of database server behaviour.