INSTALLATION NOTES

Please read the previous chapter, Known compatibility issues before you set out to install Firebird 2.0.

Classic, Superserver and Embedded are all the same Firebird engine. The differences are in the ways the server module uses machine and network resources. Briefly:

• Classic runs a stub process named fb_inet_server.exe on Windows that listens for connection requests from network clients. On POSIX systems, the [x]inetd daemon performs this listening role. The stub process or daemon creates a separate fb_inet_server process for each successful connection. Each process has its own private page cache and, on 32-bit systems, can use up to 2 GB of RAM.
• Superserver is a process named fbserver.exe on Windows, fbserver on POSIX. Like the Classic server stub it also listens for connection requests. Unlike Classic, Superserver is a threaded application. It starts (or assigns) one or more threads for each successful connection request. All of these connection threads share a common page cache. On 32-bit systems, Superserver is limited to using a maximum of 2 GB of RAM.
• In discussions, Classic and Superserver are often referred to as full servers because Firebird also supports an embedded server on both Windows and POSIX. In this model, intended for stand-alone deployments, a local client and a server are rolled together into one shared object library.
  • On Windows, the embedded server library is named fbembed.dll. It is a temporary file name that must be changed in order to be used. The Windows embedded server is an instance of Superserver.
  • On POSIX, the embedded library is distributed with the Classic kits. Its name is libfbembed.so and its manner of resource usage is like Classic.

There are no issues that make databases created by one server model incompatible with another server model. Your ultimate choice of which server model to deploy to user sites will be determined by comparing the performance of one with another in your test lab. You don't have to do anything to a database in order to make it work under a different server model.

At install time, your choice is most likely to be whether to use Classic or Superserver. For development, there's nothing in it. For testing and deployment, the choice may be more important. Superserver's shared page cache, properly configured, can be beneficial for performance where many users are working concurrently. On the other hand, Superserver for Windows does not “play nice” with multiple CPUs on most rigs and has to be set for affinity with just one CPU.

Classic can be a good choice if the host server has multiple CPUs and plenty of RAM.

Note: There is more discussion about the Classic/Superserver decision in the Quick Start Guide. A more detailed paper on the subject can be found in the IBPhoenix documentation archives.

Treat the embedded server as a deployment option. It is intended to be used by one and only one system user exclusively, which makes it impossible to use in many integrated application development environments.