Firebird Documentation IndexFirebird 2.5 Quick Start → Firebird server architectures
Firebird Home Firebird Home Prev: The Firebird ProjectFirebird Documentation IndexUp: Firebird 2.5 Quick StartNext: Document History

Appendix A: Firebird server architectures

This table gives a more detailed overview of the Firebird server architectures that were introduced in the section Classic, SuperClassic or Superserver near the beginning of this guide.

Table A..1. Classic, SuperClassic and Superserver characteristics

 

Classic Server

SuperClassic

Superserver

Processes

A listener process (xinetd on Linux, fb_inet_server on Windows) listens to the Firebird port and spawns a separate server process (fb_inet_server) for every client connection.

A single process (fb_smp_server) listens to the Firebird port and serves all connections, using threads to handle requests.

A single process (fbserver) listens to the Firebird port and serves all connections, using threads to handle requests.

Cache

Each server process (= each connection) has its own cache.

Separate cache spaces for each connection.

A shared cache space for all connections.

Local connections (Linux)

Applications can use the libfbembed library for local connections. This is a client and server rolled into one, permitting fast, direct I/O to database files. The user process must have filesystem-level access rights to the database for this to work. Local connections via the network layer are also possible; in this case, only the server process needs access to the database file.

All local connections are made via the network layer, using localhost (often implicitly). Only the server process needs access to the database file.

Local connections (Windows)

On Windows, all variants support safe and reliable local connections using the XNET protocol, with only the server process requiring access rights to the database file. Direct access in user process space requires a separate package, Windows Embedded Server.

Simultaneous access by multiple engines

Classic and SuperClassic use a shared lock system. This allows access by multiple servers (e.g. a regular server and one or more embedded servers) at the same time.

Superserver acquires an exclusive lock on the database file. No other processes can access the database during the same time.

Multiprocessor / multicore

SMP (symmetrical multi-processing) is supported out of the box. The CpuAffinityMask parameter in firebird.conf is ignored.

Unlike Superserver, Classic and SuperClassic can also assign multiple connections to the same database to different processors.

Windows Superserver defaults to using the first logical processor only, because prior to 2.5 it performed badly on SMP systems. To make use of all your processors, set the CpuAffinityMask parameter in firebird.conf to: 3 for 2 CPUs/cores; 15 for 4 CPUs/cores; 255 for 8 CPUs/cores.

Linux Superserver ignores CpuAffinityMask.

Guardian (Linux)

The Guardian isn't used: xinetd listens for incoming connections and creates server instances as needed.

SuperClassic and Superserver are single-process servers, which can be watched over by the Guardian.

Guardian (Windows)

When run as a Windows application (as opposed to a service), you can't use the Firebird Guardian. Note that running Firebird as an application is the only option on Windows 9x–ME. The Windows installer doesn't offer the Guardian option at all for Classic/SuperClassic.

Can be used with the Guardian on Windows, whether run as an application or as a service.

Events

As of version 2.5, all models can use Fiebird events under all circumstances. If the server is behind a firewall or if connections are made through a secure tunnel, a specific events port has to be assigned to the RemoteAuxPort variable in firebird.conf, and the firewall or tunnel configured accordingly.


The differences listed above result in the following pros and cons of the various models:

As you can see, none of the three models is better in all respects. If, after studying the above information, you're still not sure which is best for you, 64-bits SuperClassic may be a good choice—unless you need the additional connection-level robustness of traditional Classic, where a crashing server doesn't take down the other connections. On 32-bits systems, SuperClassic may run out of memory under high load; in this scenario, Superserver and (especiallly) Classic Server are preferred.

As mentioned earlier in this guide, you can always switch models later. De-installing and installing another server is usually a matter of minutes, and your applications and databases will keep functioning like before. The differences are in the servers only, not in the databases. All Firebird databases have the same architecture and can be accessed by any type of Firebird server.

Prev: The Firebird ProjectFirebird Documentation IndexUp: Firebird 2.5 Quick StartNext: Document History
Firebird Documentation IndexFirebird 2.5 Quick Start → Firebird server architectures