| Firebird Documentation Index → Firebird 2.5 Release Notes → Changes in the Firebird Engine |
|
|
|
Table of Contents
The primary objective of this release was to refactor Firebird's threading architecture to take advantage of the symmetric multiprocessing (SMP) capabilities of multiprocessor hardware. This has a noticeable effect on the scaleability of Superserver when multiple databases are being accessed simultaneously but its major effect is the emergence of the architectural “Superclassic” model that will underpin the fine-grained multi-threading under development for Firebird 3.
For Superserver, the new architecture will be most obvious in two ways:
In a multiple database environment, Superserver threads for each database are allotted evenly to available processors.
The default CpuAffinity setting still binds SuperServer to
a single processor only. In order to take advantage of this improvement when working
with multiple databases, this setting should be changed in firebird.conf.
A slight improvement in scaling should be apparent for single database usage on SMP hardware
It is with Classic that the effects are most evident:
Classic Server can now be multi-threaded. The one worker thread per process model remains but now it is possible to use additional threads for parallel tasks such as asynchronous shutdown, sweep, inter-process communications with the lock manager and more.
On POSIX, services in Classic also run in threads now, rather than in forked processes as previously.
For Windows Classic, services became threadable in v.2.1.
The embedded libraries—libfbembed.so on POSIX and fbembed.dll on Windows—are now multi-thread-capable and thread-safe, so they can be used in multi-threaded applications.
Testing suggests that the performance of Classic in this version will be be significantly faster than previous Classic versions.
This multi-threaded mode for Classic has been dubbed “Superclassic” for its capability to handle multiple worker threads—dedicated or pooled—inside a single server process. It shares all the usual Classic features, with a few differences:
Safe, full shutdown of the server engine is possible on any platform
Under some TPC conditions, it can outperform Classic—by about 15-20%
It uses fewer kernel resources (although not less memory)
When a Superclassic process crashes, it takes all its connections with it
Recognised limitations in the Services API for the Classic server, such as the inability to retrieve the list of attachments/active users, do not apply to SuperClassic.
On POSIX, Superclassic does not require [x]inetd.
The embedded server in the Windows library, fbembed.dll, now uses Superclassic, not Superserver as previously, thus unifying its model with that of local connection to Superclassic on POSIX. The database file-lock that previously restricted connections to a single application space is replaced by a global lock table that allows simultaneous access to the same database from different embedded server modules. This facilitates concurrent debugging of applications and use of native utility tools like gbak, gstat and so on.
A single attachment handle can now be shared by simultaneous threads. (Tracker reference CORE-2498, A. dos Santos Fernandes).
On Windows, the same fb_inet_server.exe binary delivers
either the Classic or the Superclassic working modes, according to switch settings.
Classic is the default mode.
To use the Superclassic mode as a service, add the -m[ulti-threaded]
switch to the instsvc.execommand line, as follows:
instsvc install -multithreaded
When intending to run Superclassic as an application, use
fb_inet_server -a -m
On POSIX, the new binary fb_smp_server is supplied for the Superclassic model.
It contains the network listener, meaning it works similarly to fbserver with regard
to attachment requests and does not require [x]inetd.
The multi-threaded engine used by fb_smp_server is the
libfbembed.so library, in accordance with OSRI requirements. The Classic packages
also include fbguard (the Guardian) which, in a Superclassic installation, starts
fb_smp_server, rather than fbserver as it does when the
Superserver model is installed with Guardian.
Do not try to use fbguard when running the traditional Classic server.
|
| Firebird Documentation Index → Firebird 2.5 Release Notes → Changes in the Firebird Engine |