A Firebird SQL szerver alapvetően kétféle architektúrában/modellben érhető el. Ezek neve ClassicServer ill. SuperServer. A 2.5 verziótól kezdve került bevezetésre a SuperClassic architektúra, mely a Classic architektúrára épül. Így a 2.5 verzótól kezdődően háromféle modell közül kell választani a telepítéskor. Az alábbiakban összefoglalt néhány szempont segít a választásban. Az esetek többségében mindhárom modell egyformán jól teljesít, és közel egyforma lehetőségeket kínál.
A dokumentum a http://www.firebirdsql.org/manual/qsg25-classic-or-super.html oldalon található információk kivonata.
A választás szempontjai:
Processzek
A ClassicServer minden kapcsolathoz külön folyamatot használ. A SuperClassic és a SuperServer egy folyamatot használ. Így ha a ClassicServer esetén egy processz összeomlik, ez a többi folyamatra nincs hatással. A SuperClassic és a SuperServer esetén az összeomlás az összes folyamatra kihathat.
Guardian
A SuperServer az ún. Firebird Guardian felügyelete alatt fut, ami automatikusan újraindítja összeomlás esetén. A SuperClassic csak Linux esetén ajánlja fel a Firebird Guardian opciót, míg ClassicServer esetén erre értelemszerűen nincs ilyen lehetőség.
Erőforrások
Mivel a SuperClassic és a SuperServer single-process (csak egy folyamatot használ), ezért hatékonyabban használja ki a rendelkezésre álló memóriát sok egyidejű kapcsolat esetén, mint a ClassicServer. A SuperServer és a SuperClassic között pedig az a különbség, hogy a SuperServer az adatbázis gyorsítótárakat megosztja a folyamatok között, vagyis még hatékonyabban használja ki a rendelkezésre álló memóriát.
Local connections
A ClassicServer és SuperClassic esetén van ún. embedded local connection mode Linuxon, ami nagyon gyors, de nem olyan biztonságos, mint az ún. regular network connection. Windows esetén külön ún. embedded server is elérhető, ami még kevésbé biztonságos, de bizonyos esetekben praktikus lehet.
Megjegyzés
Egyidejű kapcsolatok
Ha egy adatbázishoz embedded local connection módban történik a kapcsolódás, az adatbázis szerver csak abban az esetben tudja az adott adatbázis file-t használni, ha az ClassicServer, vagy SuperClassic modellben fut. A SuperServer az ilyen módon megnyitott adatbázishoz nem képes kapcsolódni, tehát, ha így (is) kell használni az adott adatbázist, és egy másik "regular network connection"-nel is, akkor célszerű a ClassicServer, vagy a SuperClassic architektúrát telepíteni.
Multiprocessing
Windows operációs rendszer esetén a SuperServer alapbeállításon csak az első processzort vagy magot használja a számítógépben. A többi processzor használatához a CpuAffinityMask paramétert kell beállítani a firebird.conf file-ban. A SuperServer minden egyéb esetben (pl. Linuxon) alapértelmezetten támogatott a több processzort, és ebben az esetben figyelmen kívül hagyja a CpuAffinityMask paramétert.
Amint fentebbiekből látható egyik modell sem jobb, vagy rosszabb a többinél minden helyzetben. Ha nem biztos abban, melyik a legjobb választás, úgy ökölszabályként, a SuperClassic jó választás lehet 64-bites rendszerekre. A 32-bites rendszereken a SuperClassic az első ami kifogy a memóriából nagy terhelés mellett. Ezért a SuperServer az osztott gyorsítótárral vagy a Classicserver a külön folyamataival jobban teljesíthet ezen a területen.
Ha a telepítés nem megfelelő, természetesen a későbbiekben is lehetőség van másik telepítési módra váltani, az alkalmazások és adatbázisok ugyanúgy működni fognak. A különbségek csak a szerverek belső működésében vannak, nem az adatbázisokban.
További információk találhatók még a Firebird server architectures c. dokumentumban.
Telepítő csomagok
Linuxhoz külön telepítő csomagok vannak a SuperServerhez ill. ClassicServerhez. SuperServer esetén a letöltési csomagok a FirebirdSS-sel kezdődnek, A ClassicServer esetén a FirebirdCS előtag jelzi a csomagot. Az alapértelmezett telepítési mód a ClassicServer ill. SuperClassic telepítése esetén ClassicServer. A SuperClassic architektúrára való váltáshoz le kell futtatni a changeMultiConnectMode.sh szkriptet, és a szkript által feltett kérdésre a “thread” opciót kell választani. A szkript a Firebird install könyvtárában a ...\bin alkönyvtár alatt található.
Windows esetén kombinált telepítő csomag van, mely minkét modellt tartalmazza. A telepítés során ki kell választani a SuperServer vagy ClassicServer módot. A ClassicServer választása esetén külön engedélyezhető a SuperClassic mód egy későbbi képernyőn.
Függelék:
Összehasonlítás:
/ https://firebirdsql.org/manual/qsg25-appx-architectures.html /
Table A..1. Classic, SuperClassic and Superserver characteristics
Classic Server | SuperClassic | Superserver | |
|---|---|---|---|
Processes | A listener process ( | A single process ( | A single process ( |
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 | All local connections are made via the network layer, using | |
Local connections (Windows) | On Windows, all variants support safe and reliable local connections using the | ||
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 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 Linux Superserver ignores | |
Guardian (Linux) | The Guardian isn't used: | 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 | ||
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.