In the previous example, we discussed the possibility of a user querying the database via a modem line and proxy server. Suppose the user executes a query that returns 100,000 rows of data, each row being around 1 KB. That’s a lot of information to pull across a slow network connection.
To speed things up, you could configure the proxy server to use
on-the-fly compression
(via
the
Compress::Zlib
module) to clients querying the database
over dial-up connection. This will radically reduce the quantity of
data being transferred across the modem link. You can do this by
running the dbiproxy script with the additional
arguments of:
--compression gzip
which specifies that the GNU gzip compression
method should be used.
In order for your client to be able to send and receive compressed
data from the DBI proxy server, you also must tell the proxy driver
to use a compressed data stream. This is done by specifying the
additional DSN key/value pair of compression=gzip
when connecting to the database. For example:
$proxyloc = 'hostname=fowliswester;port=3333';
$compression = 'compression=gzip';
$dsn = 'dbi:ODBC:archaeo';
$dbh = DBI->connect( "dbi:Proxy:$proxyloc;$compression;dsn=$dsn",
"username", "password" );The trade-off is the cost in CPU time for the proxy server and proxy client to compress and decompress the data, respectively. From a client perspective, this is probably not an issue, but the proxy server might be affected, especially if several large queries are being executed simultaneously, with each requiring compression.
However, compression is a useful and transparent feature that can increase the efficiency of your networks and databases when using DBI proxying.