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:

If a traditional Classic server process crashes, the other connections remain unaffected. If a SuperClassic or Superserver process crashes, all the connections go down with it.
The Guardian gives some extra reliabilty because it automatically restarts a crashed server. On Windows, this gives Superserver a little edge, especially if you run Firebird as an application (crashed services can also be restarted by the OS).
Traditional Classic uses less resources if the number of connections is low. SuperClassic and Superserver are more efficient if the number of simultaneous connections grows.
The local access mode provided by Classic and SuperClassic on Linux, though very fast, doesn't offer full security. You can disable it (see the Security chapter), but then you also lose the speed benefit.
While working with a Windows Embedded application, it may be useful if you can open its database through the regular server at the same time, e.g. for “live” inspection or to make a backup. This is only possible if your regular server is a Classic or SuperClassic.

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.