| Firebird Docset → Using Firebird → About Firebird → Classic and Superserver architectures |
|
|
|
Firebird server comes in two distinct architectures for managing multiple client connections: Superserver and Classic Server. For Windows, both architectures are included in a single download. For Linux, there are separate download packages which have either CS or SS in their name, indicating the type of server.
The Classic server starts a separate process for each connection to a database under its control. Each client is allocated its own database cache buffers. Superserver serves many clients simultaneously within a single process. Instead of separate server processes for each connection it uses threads of a single process and pools the database cache buffers for use by all connections.
If you are upgrading from a previous version of Firebird or faced with the choice between Classic and Superserver, the information listed in the comparison table below will help to explain what the differences are and how they affect database operations.
The server architecture does not affect the structure of databases or the way client applications work. Firebird databases built on a Classic server can be operated on by an equivalent Superserver server, and vice versa. The same client library can connect to either server.
In other words, if you begin by installing the Superserver distribution of Firebird on your Linux host machine and, later, decide to change to Classic, any applications you wrote for your Superserver-hosted databases will work unmodified and the databases themselves will continue to behave as they did before.
The table below gives a quick overview of the main differences between Classic and Superserver. These differences will be discussed in more detail in the subsections that follow.
Table 2.2. Comparison of Classic and Superserver architectures
|
FEATURE |
ARCHITECTURE |
|
|---|---|---|
|
Classic |
Superserver |
|
|
Availability |
Linux: All Firebird versions Windows: Firebird 1.5 and higher |
All Firebird versions |
|
Executable |
fb_inet_server(.exe) |
fbserver(.exe) |
|
Processes |
Multiple, on demand, one instance per client connection. |
Single server process, each client request is handled in its own thread. |
|
Lock management |
gds_lock_mgr process. |
Implemented as a thread. |
|
Local access on Linux |
Fast, direct I/O to the database file is possible. But you can also connect network-style via localhost. |
Network-style access only. |
|
Local access on Windows |
Versions 1.x: network-style access only. |
Versions 1.x: single (!) local connections can be made using IPC (IPServer). Network-style local connections are also supported. |
|
Firebird 2 and higher: both architectures support safe, multiple local connections on Windows machines through XNET. |
||
|
Resource use |
One cache per process. |
One cache space for all clients. |
|
Multiprocessor support |
Yes. |
No. Performance may drop if not properly configured. |
|
Services Manager + API |
Partial in Firebird 1.5, full in 1.5.1 and up. |
Full. |
|
Guardian on Windows |
On Firebird 2 Classic/Win only, a bug prevents you from using the Guardian if you run Firebird as an application. |
The Guardian functions with all Windows Superservers, whether run as a service or as an application. |
|
Guardian on Linux |
You can't use the Guardian with any Firebird Classic version on Linux. This is by design. |
The Guardian functions with all Linux Superservers. |
Runs on demand as multiple processes. When a client attempts to connect to a Firebird database, one instance of the fb_inet_server executable is initiated and remains dedicated to that client connection for the duration of the connection.
Runs as a single process, an invocation of the fbserver executable. fbserver is started once by the owning user or by a boot script. This process runs always, waiting for connection requests. Even when no client is connected to a database on the server, fbserver continues to run quietly. On Linux, the Superserver process does not depend on inetd; it waits for connection requests to the gds_db service itself.
For every client connection a separate server process is started to execute the database engine, and each server process has a dedicated database cache. The server processes contend for access to the database, so a Lock Manager subsystem is required to arbitrate and synchronise concurrent page access among the processes.
The lock manager is implemented as a thread in the fbserver executable. It uses inter-thread communication mechanisms to resolve access issues. Therefore, an external process isn't needed.
Each instance of fb_inet_server keeps a cache of database pages in its memory space. While the resource use per client is greater than in Superserver, Classic uses fewer overall resources when the number of concurrent connections is low.
Employs one single cache space which is shared by client attachments, allowing more efficient use and management of cache memory when the number of simultaneous connections grows larger.
On Linux only, the Classic architecture permits application processes that are running on the same machine as the database and server to perform I/O on database files directly. Note that this is only possible if the client process has sufficient filesystem-level access rights to the database as well as some other files. Network-style access to the local server (via localhost or equivalents) is supported on all systems.
You can only connect to local databases via TCP/IP loopback, using localhost or any other host name / IP number that points back to the local machine. (Many clients may let you get away with omitting the hostname though, and supply localhost to the server automatically.)
In Windows Classic versions prior to Firebird 2, you can only connect to local databases via network loopback, using localhost or an equivalent. Firebird 2 and higher support local access through the reliable XNET protocol, which permits multiple simultaneous connections in a safe way.
Firebird 1.5 and earlier Superservers use the IPC (IPServer) protocol for single local connections on Windows. This method is not as fast and certainly not as robust as the direct I/O on Linux Classic. Furthermore, IPC needs an internal window to exchange messages. As a consequence, local access on these versions is only available if:
the Firebird process runs as Localsystem (the default), and
the configuration parameter CreateInternalWindow has not been set to 0 (you would set this to 0 if you want to run multiple servers simultaneously).
Firebird 2 uses a different local protocol – XNET – which doesn't suffer from these restrictions, and supports multiple connections.
Of course if local protocol is disabled you can still connect to any local database via localhost, provided TCP/IP is available on your system.
Supports SMP (symmetrical multi-processor) systems. This improves the performance in case of multiple unrelated connections.
No SMP support. In fact, Superserver performance may drop significantly on multiprocessor Windows systems as a result of processor swapping. To prevent this from happening, set the CpuAffinityMask parameter in the configuration file firebird.conf.
Versions up to and including 1.5 have a partially implemented Services Manager, supporting tasks like backup/restore, database shutdown etc. over the network. Other service tasks have to be performed locally using the client tools that come with Firebird. Versions 1.5.1 and up have a full Services Manager, just like Superserver.
The Services Manager, present in all Firebird Superserver versions, allows you to perform management tasks (backup/restore, database shutdown, user management, stats, etc.) programmatically. You can connect to the Services Manager over the network and thus perform these tasks remotely.
The Firebird Guardian is a utility which monitors the server process and attempts to restart the server if it terminates abnormally.
Due to a bug in the Guardian, it can't be used with Firebird 2 Classic on Windows if run as an application. If Firebird runs as a service, the Guardian works correctly. Since the Windows 9x–ME line doesn't support services, you can't use the Guardian with Firebird 2 Classic on those systems. This bug does not exist in Firebird 1.5 versions.
(The Guardian can't be used at all with Firebird Classic on Linux, but that's by design, not by accident.)
The Guardian works fine with Superserver on both Linux and Windows, whether as a service or as an application.
In abstract terms, neither architecture is a clear winner. One architecture generally outshines the other under specific workload conditions:
A single application running on the same machine as the server is faster with the Classic architecture.
For a Linux application embedded in an appliance, Classic is better, because it provides a single process from application to disk.
On a single-processor machine, an application with larger numbers of frequently contending clients is faster with Superserver, because of the shared cache.
On SMP machines, small numbers of clients whose data updates do not impact others' tasks work better in the Classic architecture.
Besides Superserver and Classic, there's Firebird Embedded Server for Windows, which you can download as a separate package. This is not really a different architecture, but a Firebird client plus Superserver rolled into one DLL for ease of deployment. Although it has a number of downsides, it may be an attractive option if you want to include Firebird with your Windows application. More on Embedded Server in the client-server chapter.
|
| Firebird Docset → Using Firebird → About Firebird → Classic and Superserver architectures |