Az lenne a kérdésem, hogy mi számít sok illetve kevés egyidejü kapcsolódásnak? 100-150 kapcsolódás esetén ki melyiket választaná ?
Z.
Hozzászólások
Ez már soknak számít. A döntésben nem csak a kapcsolódások, hanem a szerver processzorainak száma is fontos.
Mi classic-ot használunk, mert többprocesszoros rendszereken ez a jobb. Az xinetd használata javasolt, inetd alatt néha megmagyarázhatatlanul lassú egy-egy kérés (de nem mindegyik, többféle Debian kiadás alatt próbálva).
Windows Server 2000 alatt döcögünk és 2 db HT Xeon 2.8 van benne azaz 4 procit lát a windows, a kliens gépek száma 80, egy gépről átlag 2 kapcsolódás jön, mert több prg-ot is használnak. Ilyenkor kb 160 kapcsolata van. A gép egy rendes Siemens szerver 1 Gb ram-al, az adatbázisok mérete kb 10G. Jelenleg Super fut rajta, de a több cpu kihasználás miatt gondolkodunk a Classic-on. Ez a kérdés, hogy jó ötlet-e ? Persze linux telepítés is eljön egyszer, de addig marad a win.
"SuperServer has demonstrated an ability to efficiently serve a higher number of concurrent clients."
"Classic Server - Creates a separate process for every client connection, each with its own cache. Less resource use if the number of connections is low."
"SuperServer - A single process serves all the connections, using threads to handle requests. Shared cache space. More efficient if the number of simultaneous connections grows."
Írod, hogy SMP a gép:
"SuperServer - No SMP support. On multi-processor Windows machines, performance can even drop dramatically as the OS switches the process between CPUs. To prevent this, set the CpuAffinityMask parameter in the configuration file firebird.conf."
Az én tapasztalatom az, hogy pl 3 rétegű architektúra és ún. connection pooling esetén általában nincs szükség "túl sok" párhuzamos kapcsolódási lehetőségre - nyilván ez is sok mindentől függ, de sokkal jobbak a mutatók egy "hagyományos" 2 rétegű architektúránál. Ha nem "hosszúak" és "sűrűk" az elvégzendő feladatok 3-4 kapcsolat kiszolgál 40-50 felhasználót.
Mindazonáltal nemcsak a terheléstűrés az egyetlen választási szempont, amint az írásokból kiderül, az eredeti kérdésfeltevés nem tükrözte, hogy ilyen szempontból is körbe lett-e járva a feladat.
Ne haragudj, de nagyon kicsi a valószínűsége annak, hogy olyan számokat fogsz bárhol is találni, ami a Ti rendszeretekre is jellmező lehet. A sült galamb sajnos nem tud repülni, ezért kell saját kezűleg megsütni.
Én nem sült galambot várok, csak olyan emberek esetleges hozzászólását, akik rendelkeznek TAPASZTALATTAL. Elmeséli, hogy neki erre+erre a feladatra 100 klienssel xy megoldás volt a jobb.
És miért nem tesztelgetek ? Mert egy nagy server + 100 client pc + 100 embert órákig ezzel nyüstölni, hogy tesztelgessük nem olcsó. Előbb kérdezek itt, hátha valaki ad néhány jó tippet.
Állítsd át a rendszert SS-ről CS-re egy éjjel, aztán várj néhány napot.
Ha ezalatt a felhasználók nem ütöttek agyon, akkor tarts közvéleménykutatást, hogy észrevettek-e lassulást/gyorsulást.
A szerver 24 órában megy, és a felhasználók tevékenysége is 24 órás, csak egyszer szeretném átkapcsolni, ha szinte BIZTOS, hogy azzal jót teszek, nem pedig hol ide, hol oda.
Classic esetén nagyon megnő a memóriahasználat, ami nálunk kapcsolatonként 10mb körüli volt. Ez egyrészt nem fért el a memcsiben 1Gb, másrészt a nagy memóriahasználat a mennyisége miatt is egy lassítási tényező.
Egy másik probléma, hogy esetleges leállításnál maradtak zombi process-ek a memóriában és hibák keletkeztek a GDB-ben újraindítás után.
A végeredmény, hogy kell egy nagyobb gép, és optimalizálnom ezerrel.
Konstruktív kérdés: arra nem gondoltál még, hogy másik rdbms-t használj? Tapasztalatom szerint mind a PostgreSQL, mind az MS SQL (már van ingyenes változata is) sokkal gyorsabb. Oracle-nek is van ingyenes változata.
Hozzászólások
Ez már soknak számít. A döntésben nem csak a kapcsolódások, hanem a szerver processzorainak száma is fontos.
Mi classic-ot használunk, mert többprocesszoros rendszereken ez a jobb. Az xinetd használata javasolt, inetd alatt néha megmagyarázhatatlanul lassú egy-egy kérés (de nem mindegyik, többféle Debian kiadás alatt próbálva).
Windows Server 2000 alatt döcögünk és 2 db HT Xeon 2.8 van benne azaz 4 procit lát a windows, a kliens gépek száma 80, egy gépről átlag 2 kapcsolódás jön, mert több prg-ot is használnak. Ilyenkor kb 160 kapcsolata van. A gép egy rendes Siemens szerver 1 Gb ram-al, az adatbázisok mérete kb 10G. Jelenleg Super fut rajta, de a több cpu kihasználás miatt gondolkodunk a Classic-on. Ez a kérdés, hogy jó ötlet-e ? Persze linux telepítés is eljön egyszer, de addig marad a win.
Z.
érdemes elolvasni:
http://www.firebirdsql.org/manual/qsg15-classic-or-super.html
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_ss_vs_classic
http://kinterbasdb.sourceforge.net/dist_docs/firebird-client-library-th…
és még ez is ide tartozik:
http://bdn.borland.com/article/23217
Egyikben sem találtam terheléssel kapcsolatos leírást, tapasztalatot.
Pedig van, ha nem is az egész arról szól, pl:
"SuperServer has demonstrated an ability to efficiently serve a higher number of concurrent clients."
"Classic Server - Creates a separate process for every client connection, each with its own cache. Less resource use if the number of connections is low."
"SuperServer - A single process serves all the connections, using threads to handle requests. Shared cache space. More efficient if the number of simultaneous connections grows."
Írod, hogy SMP a gép:
"SuperServer - No SMP support. On multi-processor Windows machines, performance can even drop dramatically as the OS switches the process between CPUs. To prevent this, set the CpuAffinityMask parameter in the configuration file firebird.conf."
Az én tapasztalatom az, hogy pl 3 rétegű architektúra és ún. connection pooling esetén általában nincs szükség "túl sok" párhuzamos kapcsolódási lehetőségre - nyilván ez is sok mindentől függ, de sokkal jobbak a mutatók egy "hagyományos" 2 rétegű architektúránál. Ha nem "hosszúak" és "sűrűk" az elvégzendő feladatok 3-4 kapcsolat kiszolgál 40-50 felhasználót.
Mindazonáltal nemcsak a terheléstűrés az egyetlen választási szempont, amint az írásokból kiderül, az eredeti kérdésfeltevés nem tükrözte, hogy ilyen szempontból is körbe lett-e járva a feladat.
Én valamiért akkor is számokat szeretnék látni!
Mi akadályoz meg abban, hogy magad csinálj néhány tesztet SS vs.CS ügyben?
Ne haragudj, de nagyon kicsi a valószínűsége annak, hogy olyan számokat fogsz bárhol is találni, ami a Ti rendszeretekre is jellmező lehet. A sült galamb sajnos nem tud repülni, ezért kell saját kezűleg megsütni.
Én nem sült galambot várok, csak olyan emberek esetleges hozzászólását, akik rendelkeznek TAPASZTALATTAL. Elmeséli, hogy neki erre+erre a feladatra 100 klienssel xy megoldás volt a jobb.
És miért nem tesztelgetek ? Mert egy nagy server + 100 client pc + 100 embert órákig ezzel nyüstölni, hogy tesztelgessük nem olcsó. Előbb kérdezek itt, hátha valaki ad néhány jó tippet.
Állítsd át a rendszert SS-ről CS-re egy éjjel, aztán várj néhány napot.
Ha ezalatt a felhasználók nem ütöttek agyon, akkor tarts közvéleménykutatást, hogy észrevettek-e lassulást/gyorsulást.
A szerver 24 órában megy, és a felhasználók tevékenysége is 24 órás, csak egyszer szeretném átkapcsolni, ha szinte BIZTOS, hogy azzal jót teszek, nem pedig hol ide, hol oda.
Ötletek most nem kellenek, inkább Tapasztalat !
Akkor egy kis tapasztalat.
Classic esetén nagyon megnő a memóriahasználat, ami nálunk kapcsolatonként 10mb körüli volt. Ez egyrészt nem fért el a memcsiben 1Gb, másrészt a nagy memóriahasználat a mennyisége miatt is egy lassítási tényező.
Egy másik probléma, hogy esetleges leállításnál maradtak zombi process-ek a memóriában és hibák keletkeztek a GDB-ben újraindítás után.
A végeredmény, hogy kell egy nagyobb gép, és optimalizálnom ezerrel.
Z.
Köszi a tapasztalatot.
Konstruktív kérdés: arra nem gondoltál még, hogy másik rdbms-t használj? Tapasztalatom szerint mind a PostgreSQL, mind az MS SQL (már van ingyenes változata is) sokkal gyorsabb. Oracle-nek is van ingyenes változata.
Nem, a szoftverek, nagyon összetettek, és sokkal nagyobb meló lenne adatbázist cserélni alatta, mint optimalizálni/gépet bővíteni.