Ha a szerver lehetővé teszi, akkor érdemes a 64 bites Firebirdöt telepíteni, mert a 64 bites Firebird egyértelműen nagyobb teljesítményre képes, aminek elsősorban a nagyobb adatbázisok esetben van jelentősége. A légyegesebb különbségek:

– 2 GB-nál több memóriát csak a 64 bites tud használni.

– az adatbázisonként használható olvasási cache csak a 64 bitesnél lehet 130 KB-nál több.

Firebird szerver telepítése Classic / SuperServer / SuperClassic módban

Az egyes telepítési üzemmódok belső felépítése és erőforrás-felhasználási profilja eltér, ezért a felhasználás körülményeitől – leginkább a csatlakoztatott adatbázisok és a csatlakozó kliensek számától – függ, hogy melyik üzemmód a legelőnyösebb. (A szerver telepítési módja nem befolyásolja az adattárolás szerkezetét, tehát a telepítési mód változtatása után is használható ugyan azon adatbázis). A legfontosabb különbségek:

Számunkra a működési sebesség szempontjából fontos beállítás a firebird.conf fájlban a GCPolicy = background, amelyet csak a SuperServer ismeri, ezért javasoljuk, hogy a Firebirdöt Superserver üzemmódba telepítsék.

	Classic	SuperServer	SuperClassic
Processzek	Minden kapcsolathoz külön process indul a szerveren.	Minden kapcsolat egyetlen processzt használ
Memória	Minden kapcsolat saját gyorsítótárat használ	Minden kapcsolat ugyan azt a gyorsítótárat használja	Minden kapcsolat saját gyorsítótárat használ
Guardian	Nem használható	Használható	Csak Linuxon használható

Az ideiglenes adatok tárolási helyének beállítása

Néhány lemezműveletet a Firebird nem az adatbázis fájlban, hanem egy külön TEMP mappában végez, úgy hogy a TEMP mappában létrehoz a nevükben „fb_” karakterekkel kezdődő fájlokat, amiket a használat után automatikusan töröl. Ilyen műveletek például az adatok rendezése vagy az ideiglenes táblák használata.

környezeti változók

Az adatbázist tároló háttértár tehermentesíthető – ezáltal a sebesség növelhető – ha a Firebird által használt ideiglenes mappát egy másik – szintén gyors –

háttértáron helyezzük el.

Annak ellenére, hogy csak ideiglenes adatok tárolási helyéről van szó, a helytelen beállítások leállíthatják az adatbázis szervert, ezáltal nem csak az adott felhasználót, hanem a szerverre csatlakozó összes program összes felhasználója számára elérhetetlenné válhat az adatbázis, ezért fontos figyelemmel lenni az alábbiakra:

Ha a megadott TEMP mappa nem érhető el (pl.: nem elérhető a megadott meghajtó, vagy a megadott mappa nincs létrehozva…), akkor a Firebird – a TEMP mappa első használatának kísérletekor – SQL hibát ad, és ezzel együtt leáll, a Firebird Szerver és a Guardian szolgáltatás is.

Ha a megadott meghajtó a művelet végrehajtása során betelik, akkor a művelet SQL hibát ad. Amíg a tárterület nem szabadul fel más felhasználók TEMP műveletei sem hajthatóak végre.

A megadott meghajtót az egész Firebird szerver használja, tehát a meghajtón annyi helynek kell lennie, ami elegendő az összes csatlakozó felhasználó összes adatbázis-kapcsolat számára, ami természetesen az adatbázisok teljes fájlméretének többszöröse is lehet.

Mivel a TEMP mappába egyes lekérdezések is tárolnak ideiglenes adatokat, ezért ennek a TEMP adatokat tároló háttértár sebessége is fontos.

A Firebird által használt TEMP mappa megadható a FIREBIRD_TMP környezeti változóban. Fontos, hogy:

A környezeti váltózó a rendszerváltozók között szerepeljen (tehát ne a felhasználó profiljában legyen). Ilyen változót a Rendszer tulajdonságai > Speciális rendszerbeállítások > Környezeti változók > Rendszerváltozók beállítási csoportba lehet felvenni.
A változó beállítása után újra kell indítani a Firebird szolgáltatást.

Ha LINUX-ra telepítik a Firebird-szervert

Linuxon Ext3 fájlrendszeren a Firebird sebessége lényegesen lassabb (az átlagos Windowsos teljesítmény felét tudja csak), viszont XFS fájlrendszeren jobb teljesítményt ad, mint Windowson.

http://www.slideshare.net/ibsurgeon/firebird-25-benchmark-by-tsutomu-hayashi-tomneko

Firebird beállításaival kapcsolatos problémák

A Firebird szerver beállításai

Az adatbázis szervert SuperServer módban kell telepíteni, mert egy fontos beállítás csak ebben a módban elérhető.

Az adatbázis-szerveren lévő firebird.conf fájlban át kell állítani az alábbi beállításokat. Figyelni kell rá, hogy a sor előtt a NE legyen # karakter, mert különben a beállítás hatástalan.

GCPolicy = background

Ebben az esetben az automatikus tábla-karbantartó utasítások egy külön szálon futnak és nem várakoztatják a tábla hozzáféréseket. Ez a beállítás csak SuperServer módban elérhető, a Classic-nál nem.

CpuAffinityMask = 255

Ekkor a Firebird az első 8 processzormagot használhatja. Ez a beállítás csak akkor érdekes, ha SuperServer-ként telepítettük a Firebirdöt.

ProcessPriorityLevel = 1

Ekkor a Firebird magas prioritással fut a számítógépen és hamarabb és több ideig használhatja a gép erőforrásait. Az alapértelmezett érték 0, ami a normál prioritásnak felel meg.

LockMemSize = 4194304

A Firebird belső adatzárolás-kezelője által használható memória mérete, bájtokban megadva. Alapból 1 MB, ha egy tranzakción belül sok adatmódosítás történik, akkor érdemes ezt az értéket növelni.

TempCacheLimit = 967108864

A Firebird néhány művelethez ideiglenes táblákat hoz létre, például az alábbiakhoz:

Ha a „Create Temporary Table” utasítással létrehozott táblába írunk / módosítunk
Olyan rendezésekhez (order by), amelyekhez nem tartozik index
Olyan tábla kapcsolatokhoz (join) amelyekhez nem tartozik index

Ezek csak ideiglenes adatok ezért sosem kerülnek be az adatbázis-fájlba, sőt legjobb, ha elférnének a memóriában és sosem kellene lemezre írni őket. A TempCacheLimit beállítás adja meg az e célra felhasználható maximális memória mérete, bájtokban. Alapértelmezett értéke 64 MB. Classic szerver esetén vigyázni kell vele, mert adatbázis-kapcsolatonként használ ennyi memóriát.

Ha nagyméretű táblákat kell a Firebirdnek TEMP táblákban kezelnie, akkor érdemes lehet a TempBlockSize beállítás értékét növelni (alapból 1 MB), mert ez határozza meg, hogy a TEMP területet mekkora egységekkel növelje. A nagyobb érték csökkenti a TEMP adatok belső töredezettségét, így hatékonyabb használatot eredményez.

RemoteAuxPort = 8100

A Firebird szerver „Event Notification Messages” TCP üzeneteit az itt megadott TCP portra küldi. Az alapértelmezett érték 0, ami azt jelenti, hogy véletlenszerűen kitalál egy portot, ami esetleg problémát okozhat a tűzfalnál. Próbáljunk meg beállítani egy meghatározott portszámot és ezt engedjük át a tűzfalon.

TcpRemoteBufferSize = 8192

A TCP protokoll adatforgalmát az itt megadott méretű csomagokba szervezi (alapértelmezett értéke: 8192, lehetséges értékei 1448 – 32767 között). Ha rendszerint sok adatot fetchelünk, megbízható hálózaton, akkor hasznos lehet nagyobb értéket megadni.

Az adatbázis olvasási gyorsítótár mérete túl kicsi

Az adatbázisból kiolvasott adatokat a Firebird gyorsítótárazza. Az olvasási gyorsítótár adatbázisonként kerül felhasználásra és adatbázisonként állítható a mérete. Ha az adott adatbázis-fájl az olvasási gyorsítótár méretét nem határozza meg (alapból ez a helyzet), akkor a firebird.conf fájl DefaultDbCachePages beállításában megadott gyorsítótárat foglalja le, ami 2048 adatbázis lap. Az alapértelmezett gyorsítótár használathoz tartozik még a firebird.conf fájl FileSystemCacheSize és a FileSystemCacheThreshold beállításai is, amelyeknek csak akkor van jelentőségük, ha az adatbázishoz rendelt gyorsítótár lapok már elfogytak.

A gyorsítótár mérete adatbázisonként megadható az alábbi paranccsal:

GFIX.EXE -BUFFERS 5000 %ELES_FDB% -USER SYSDBA –PASSWORD masterkey

A buffers paraméternek megadott számú adatbázis-lapnak megfelelő memóriát foglal az adatbázisban, tehát ha az adatbázis lapmérete 4KB (mi ilyen adatbázisokat használunk) akkor az 5000 lap összes memóriaigénye: 5000 * 4KB = 20 MB lesz. SuperServer telepítés esetén minden felhasználó ugyan azt a gyorsítótárat használja, ez optimális a memória és a sebesség szempontjából is. Ahány adatbázishoz csatlakozunk a szerveren, mindegyik adatbázishoz készít a szerver egy saját gyorsítótárat, az adatbázisban meghatározott mérettel. Például, ha a fenti beállításokkal létrehozott két adatbázishoz csatlakozik 10 – 10 felhasználó, akkor – SuperServer telepítés esetén – összesen 2 * 20 MB = 40 MB memóriát foglal a gyorsítótár.

Nincs értelme nagyobbra állítani a gyorsítótár méretét, mint az adatbázisfájlban lévő összes lapok száma. Az adatbázis lapszámát megbecsülhetjük, ha az adatbázis fájlméretét osztjuk a lapmérettel, például egy 100 MB-os adatbázisnál: 100 MB / 4 KB = 25 000.

Az alábbi batch file az első paraméterben várja az adatbázis fájlt, a másodikban a gyorsítótár méretét megabájtokban (4096 bájtos lapméret esetén):

@SET /A CACHE_IN_MEGABYTES=%2 * 256

“c:\Program Files\Firebird\Firebird_2_5\bin\gfix.exe” -BUFFERS %CACHE_IN_MEGABYTES% %1 -USER SYSDBA -PASSWORD masterkey

Az adatbázisban lévő lapok száma pontosan lekérdezhető az alábbi paranccsal, ami sajnos táblánként írja ki a lapok számát, több egyéb adattal együtt:

GSTAT.EXE -d %ELES_FDB% -USER SYSDBA -PASSWORD masterkey > c:\proba.txt

A fenti parancs által készített listafájlból ( c:\proba.txt ) csak a lapok számát ( „Data pages” ) tartalmazó sorokat listázni lehet az alábbi DOS paranccsal:

findStr /C:”Data pages” c:\proba.txt > c:\proba2.txt

A fenti parancs által készített fájlból az Excel számára használható lista készíthető ezzel a PoweShell paranccsal:

powershell -Command “(gc c:\proba2.txt) -replace ‘ Data pages: ‘, ” | Out-File c:\proba3.txt”

A fenti parancs által készített fájlt (c:\proba3.txt) meg lehet nyitni az Excelben, a megnyitáskor elindul a „szövegbeolvasó varázsló” (az Excel 2003-ig: „adatok – szövegből oszlopok”) amelyben az első oldalon „tagolt” a másodikban a „határoló jelek” keretben az „Egyéb” mezőbe be kell írni a vessző karaktert.

Az adatbázis írás-gyorsítótárazása ki van kapcsolva

A Firebird az adatbázis-írási műveleteket alapértelmezés szerint azonnal végrehajtja, azért hogy bármilyen leállás a lehető legkevesebb adatvesztéssel járjon. Lehetőség van az adott adatbázis-fájlra engedélyezni az írási műveletek gyorsítótárazását ( aszinkron írásnak nevezi a Firebird), ekkor az írási műveletet csak a memóriában történnek meg, az adatok lemezre írása egy belső algoritmus által választott, későbbi időpontban történik majd. Ezzel a sok írási műveletet igénylő programrészek jelentősen – akár több tízszeresére – gyorsulhatnak.

Az adatok tényleges kiírása a háttértárra megtörténik:

legkésőbb az tranzakció véglegesítésekor (commit)
egy beállítható időérték leteltekor.

A gyorsítótár bekapcsolása az adatvesztés kockázatát nem növeli számottevően, mert az adatbázisban csak véglegesített (commit) tranzakciókat olvasunk vissza, emiatt nem fordul elő olyan eset, hogy a felhasználó már megtörténtnek látná az adatrögzítést, de azt valójában még nem tároltuk a lemezen.

Az írás-gyorsítótárazása az alábbi parancssori utasítással kapcsolható be a megadott adatbázison (aszinkron írást végez szinkron helyett):

GFIX.EXE –WRITE ASYNC %ELES_FDB% -USER SYSDBA –PASSWORD masterkey

Az írás-gyorsítótárazása az alábbi parancssori utasítással kapcsolható ki a megadott adatbázison (szinkron írást végez aszinkron helyett):

GFIX.EXE –WRITE SYNC %ELES_FDB% -USER SYSDBA –PASSWORD masterkey

Az írási műveletek ki- / bekapcsolt állapota az alábbi paranccsal kérdezhető le:

GSTAT.EXE –h %ELES_FDB%

A fenti parancs ( felhasználónév és jelszó nélkül ) megjeleníti az adatbázis „header page” adatait, amelyek között, ha az „Attributes” beállítás értékében szerepel a „force write”, akkor az írás gyorsítótárazás ki van kapcsolva, tehát az írási műveletek azonnal megtörténnek, míg ha a „force write” nem szerepel, akkor az írás gyorsítótárazás be van kapcsolva.

Az írási gyorsítótár a firebird.conf alábbi beállításai szerint működik (A Firebird.conf-ban szereplő leírás arra utal, hogy a commit utasítás mindenképp kiírja az adatokat a lemezre: „Number of unflushed writes which will accumulate before they are flushed, at the next transaction commit.”):

A gyorsítótárban lévő maximális lapok számát a firebird.conf fájl MaxUnflushedWrites beállításában lehet szabályozni (alapértelmezett értéke: 100). A beállításnak csak aszinkron írás esetén van hatása.

A gyorsítótárban legfeljebb a firebird.conf maxUnflushedWriteTime beállításban megadott számú másodpercig maradhatnak a lapok, az itt megadott idő letelte után kiíródnak a lemezre. (alapértelmezett értéke: 5). A beállításnak csak aszinkron írás esetén van hatása.

Az adatbázis aktív tranzakciós naplója túl nagy

Minden adatbázis művelet sebességét lassítja, ha az adatbázisban a rekordokról túl sok verzió – akár több százezer – szerepel. A rekordverziókat az alábbi paranccsal lehet lekérdezni, de mivel táblánként írja ki, ezért egyből fájlba készítem a listát:

gstat.exe %ELES_FDB% -r -user SYSDBA -PASSWORD masterkey > c:\proba.txt

a gstat.exe a Firebird BIN mappájában található, például itt:

“c:\Program Files\Firebird\Firebird_2_5\bin\”

Az %ELES_FDB% helyére az FDB fájl teljes elérési útját és nevét kell írni. Írok ide két utasítást, amelyek a fenti példafájlból (c:\proba.txt) kiemelik azokat a sorokat, amelyek táblái több rekordverziót tartalmaznak:

findstr /C:”total versions:” c:\proba.txt > c:\log2.txt

findstr /V /C:”total versions: 0″ c:\log2.txt > c:\log3.txt

Az elkészült listából az egyes táblák „Total versions” adata érdekes, itt egy példa, ami a RENDELTET tábla egy állapotát mutatja:

RENDELTET (186)

Primary pointer page: 878, Index root page: 879

Average record length: 232.56, total records: 17502

Average version length: 9.09, total versions: 511770, max versions: 129

Data pages: 5811, data page slots: 13600, average fill: 76%

Megoldás:

adatbázis mentés – visszatöltés

vagy

SWEEP futtatása, az alábbi paranccsal:

gfix.exe -user SYSDBA -password masterkey -sweep %ELES_FDB%

(a gfix.exe a Firebird BIN mappájában található, például itt:

“c:\Program Files\Firebird\Firebird_2_5\bin\”)

A SWEEP idejére az adatbázis nem elérhető a felhasználók számára.

Ha ez a probléma fennáll az adatbázisnál, akkor érdemes az automatikus sweep műveletet kikapcsolni, különben a Firebird esetleg a felhasználók számára alkalmatlan időpontban indítja el az adatbázis automatikus karbantartását ( sweep ) ami percekre megakaszthatja a munkát. A Firebird adatbázis automatikus karbantartását kikapcsolni ezzel az utasítással lehet:

gfix.exe %ELES_FDB% –h 0 -user SYSDBA -password masterkey

Természetesen a kikapcsolt karbantartás (sweep) mellett az adatbázis használata egyre lassabb lesz, tehát időnként futtatni kell egy sweepet vagy egy adatbázis mentést és visszatöltést.

Háttértár sebességével kapcsolatos problémák

A lemez írási/olvasási sebessége

Az adatbázis műveletekhez NEM a lemez szekvenciális írási/olvasási sebessége számít, hanem a random írási/olvasási sebessége. Ezt érdemes lemérni egy tesztprogrammal, például az ingyenesen használható CrystalDiskMarkkal, ami letölthető innen:

https://crystalmark.info/en/download/#CrystalDiskMark

Egy gyors szerver winchester	Egy normál SSD

Egy gyors SSD (Kingston SKC400)	3 gyors SSD-ből álló RAID0 tömb (Kingston SKC400)

Két NVMe tárolóból álló RAID1 tömb (Samsung NVMe 950 PRO)	Egy nagyon gyors NVMe tároló (Intel NVMe 750)

A tesztprogram adataiból nekünk a “4K” sorban szereplő adatok érdekesek, mert ugyan ekkora az adatbázis lapmérete ( a Firebird is 4 kilobájtos blokkokban írja az adatbázis-fájlt ).

Megoldás:

Az adatbázist át kell helyezni egy olyan háttértárolóra, amelynek a 4K random írási / olvasási sebessége több 10 MB / másodperc.

Samsung SSD 850 EVO

Samsung SSD 860 EVO M2

Samsung 970 Evo plus NvMe

A lemez-vezérlőn az írási gyorsítótár ki van kapcsolva

A legtöbb esetben ez alapból be van kapcsolva a beépített lemezeken Windowsban, de ha külső (USB-n csatlakoztatott) lemezen tárolná az adatbázist, ott alapból ki van kapcsolva. Ha az eszközvezérlőben az írási gyorsítótár ki van kapcsolva, az még SSD esetén, egyetlen felhasználónál is a többszörösére lassítja az adatbázis írási műveleteit. A gyorsítótárat bekapcsolni a Windowsban az eszközkezelőben meg kell keresni azt a lemezmeghajtót, amelyiken az adatbázist tároljuk, dupla klikk a lemez nevén, majd a házirendek fülön be kell kapcsolni az írási gyorsítótárazás engedélyezése az eszközön kapcsolót.

A RAID vezérlő írási gyorsítótár beállítása

Ha külön RAID vezérlőkártyát használ, akkor ellenőrizze, hogy az írási gyorsítótár beállítása „wright-back” (nem „write-through”). Azon RAID vezérlők, amelyek saját akkumulátort tartalmaznak (BBU = Backup Battery Unit), lehetséges, hogy nem engedélyezik a gyorsítótár bekapcsolását, ha az akkumulátor állapota nem megfelelő, illetve, automatikusan kikapcsolják a gyorsítótárat ha problémát észlelnek az akkumulátorral.

A megfelelő RAID tömb használata

Akár egyedülálló lemezen (RAID tömb nélkül), akár RAID1 vagy RAID5 tömbben használja az adatbázis fájlokat tároló háttértárat, ennél nagyobb teljesítményhez juthat, ha áttér RAID10 konfigurációra. Ez a fenti kialakításokhoz képest több fizikai lemezt igényel, ezért jelentős költségekkel járhat.

Az adatbázis lapmérete és a lemez „allocation unit” mérete

A gyorsabb I/O műveletek eléréséhez az is fontos, hogy az adatbázis lapmérete (4 KB) megegyezzen az adatbázis-fájlt tároló partíció formázásakor megadott “allocation unit” méretével. Az alábbi parancssori utasítással meg lehet nézni, hogy mekkora a megadott partíció “allocation unit” mérete (a parancs futtatásához rendszergazdai jog kell):

fsutil fsinfo ntfsinfo c:

A formázáskor megadható „allocation unit” méretét a fenti parancs a „bytes per cluster” sorban írja ki.

Megoldás:

Olyan lemezpartíción kell elhelyezni az adatbázis-fájlt, amelynek „allocation unit” mérete 4K.

A partíció allocation unit mérete csak formázáskor állítható, ráadásul a Windows beépített lemezformázó eszköze nem mindig ajánlja fel az „allocation unit” beállítását.

Hálózattal kapcsolatos problémák

A hálózat sebessége

A Firebird szervernek egy kérés feldolgozási idejéhez hozzátartozik az adatok hálózati utaztatása is, ami a művelet összes-végrehajtási idejének 90%-át is adhatja.

Ha vezeték nélküli hálózaton kapcsolódnak, az különösen problémás, mert ott sokkal gyakoribb a kapcsolat megszakadása, amit az adatbázis-szerverek nem tolerálnak olyan jól, mint a webkiszolgálók.

Megoldás:

A szerver és a kliensek is vezetékes hálózatot használjanak
Lehetőleg gigabites hálózatot használjanak

Ha számítógépnév alapján kapcsolódnak a szerverhez

Ha az adatbázis-kapcsolat felépítésénél NEM IP címet, hanem számítógépnevet használunk és a szerveren több hálózati csatoló is szerepel ( pl.: LAN, WIFI, VPN, Virtuális hálózati adapterek… ) akkor előfordul, hogy a számítógépnév feloldására nem mindig a LAN hálózati csatoló IP címét kapjuk vissza, hanem egy másik csatolóét, amelyre esetleg más beállítások vonatkoznak ( pl.: más a TimeOut ideje, más tűzfal-szabályok vonatkoznak rá…) és ez változatos – nem állandóan, hanem látszólag véletlenszerűen jelentkező – problémákat okozhat (lassulást, működésképtelenséget ).

Megoldás:

Az adatbázis-kapcsolat megadásánál mindenhol IP cím szerepeljen

A szerver nevének és IP címének összerendelése az sam fájlban. A fájl helye a Windowsban: <windir>\System32\drivers\etc\lmhosts.sam. A fájl egy egyszerű szöveges fájl a kliens számítógépen (mindegyik kliensen módosítani kell), ahol egy új sor elejére kell írni a szerver IP címét, majd egy (vagy több) SPACE (vagy TAB) karakter után a szerver nevét, például:

192.168.0.4 SERVERXP

A Firebird hálózati forgalmának magasabb prioritást beállítani (QOS)

Az alábbi beállításnak csak akkor van értelme, ha:

a kliensek hálózatban csatlakoznak az adatbázis-kezelőhöz
az adatbázis szerver nem dedikált szerver, hanem az adatbázis kiszolgáláson felül más hálózati feladatokat is végez ( pl.: fájlszerver, webszerver…)

Az operációs rendszerbe épített QOS (Quality Of Services) használatához az adatbázis szerverhez vezető hálózati forgalmat kezelő routereknek és switcheknek támogatniuk kell a Differentiated Services Code Points (DSCP) technológiát. Ezzel a hálózat TCP protokolljának minden egyes csomagjához egy prioritási érték rendelhető (0-63 közötti szám). Ha a hálózati eszközben (switch, router) több csomag is várakozik, hogy hozzáférhessen a fizikai réteghez („ a vezetékhez”), akkor az eszköz azt a csomagot próbálja hamarabb küldeni, amelyiknél nagyobb a beállított száma.

Az adatbázis szerveren az alábbi beállításokat kell elvégeznie:

Jelentkezzen be rendszergazdaként
Írja be a parancssorba: MMC, majd nyomjon ENTER-t
Az MMC konzol ablakában nyomja meg a CTRL+M billentyűket új beépülő modul hozzáadásához.
Az „Add or Remote Snap-ins window”-ban válassza a „Group Policy Object Editor”-t az „Available snap-ins” listából, majd nyomja meg az Add
A „Select Group Policy Object” ablakban csak nyomja meg a „Finish” gombot.
Kattintson az „OK”-ra, az „Add or Remote Snap-ins” ablak bezárásához.
Az MMC konzol bal oldalán nyissa ki a „Local Computer” > „Computer Configuration” > „Windows Settings” beállítást, majd kattintson a jobb egérgombbal a „Policy-based QoS”-re és válassza a „Create new policy”-t a menüből.
A „policy-based QOS” ablakban írjon be egy nevet a „policy name” mezőbe, állítsa be a DSCP értékét 63-ra, majd kattintson a „Next” gombra.

policy-based QOS

A következő ablakban jelölje be a „Only applications with this executable name” rádiógombot
Írja be annak az alkalmazásnak a nevét, amelyiknek hálózati forgalmának nagyobb prioritás szeretne adni – Superserver telepítésű Firebird szerver esetén ez: „fbserver.exe”, majd kattintson a „Next” gombra.

policy-based QOS fbserver

Hálózati adatbázis-kapcsolat vagy terminál szerver közötti választás

Több felhasználó csatlakozásának hagyományos módja a kliens-szerver architektúra, ahol a hálózatban dolgozó felhasználók kliens programjai csatlakoznak ugyan ahhoz az adatbázis-kiszolgálóhoz. Ekkor a kliens és a szerver között forgalmazott összes adat áthalad a hálózaton.

Ettől eltérően a terminál szerveres használat esetén lehetőség van arra, hogy a felhasználók egy terminál szerverre csatlakozzanak, amely helyben telepített adatbázis-kezelőt használ. Ekkor a felhasználók kliens számítógépeire egyáltalán nem szükséges telepíteni a Novitax programokat. A felhasználók a Windowsba épített „távoli asztali kapcsolat” nevű programmal csatlakoznak a kiszolgálóhoz, ahol minden felhasználónak külön bejelentkezési lehetősége van, amelyhez a Windows felhasználás szokásos elemei (asztal, dokumentumok…) tartoznak. A felhasználók a szerver által számukra előállított felhasználói felületének képét látják, amelyet saját egerükkel és billentyűzetükkel vezérelnek, épp úgy mintha a saját gépükön futó programot használnának.

Bizonyos esetekben a terminál szerveres működés gyorsabb használatot biztosít, mint ha a felhasználók saját gépére telepített Novitax programokkal csatlakoznának az adatbázishoz.