kormánypénzvivő.hu

Online berkekben erősen kicsapta a biztosítékot a kormanyszovivo.hu 200 milliós költsége. Hagyjuk egyelőre a politikai tényezőket, azt a kérdést, hogy szükség volt-e erre, hogy néz ki, stb. Nézzük meg az online közösség miként reagálta le a hírt műszaki/gazdasági szempontból.

Alapvetően három kategória van.

Az első kategória az én-megcsinálom-százezerér-vazze kategória. Ezek az emberek ránéznek az oldalra, látják az egyébként gyalázatos design-t, és azonnal tesznek ajánlatot, hogy ők ezt PHP-ban megcsinálják 500 eFt-ért. Nekik a műszaki tartalom megáll a weboldal funkció listájában. Nem kalkulálnak semmi mással. Ezek az emberek valószínűleg soha nem csináltak komolyabb projekteket, ahol műszaki szempontból jól meghatározott keretek között kell megoldani a feladatot. Szerintuk a kormanyszóvivo.hu elfutna akár egy virtuális szerveren is.

A következő kategória az a mérnök akinek megfelelő tapasztalatai vannak komolyabb rendszerek méretezésével. Ezek az emberek tudják, hogy bizonyos site-ok naponta 400 ezer látogatót is kiszolgálhatnak, sőt akár óránkénti 100 ezer látogatós csúcsok is lehetnek. Ennek a problémának hatása van a megoldásra. Itt nem elsősorban a hardver a szűk keresztmetszet, hanem a szoftver. Kevés az a mérnök, akinek van gyakorlati tapasztalata nagyméretű weboldalak mögötti RDBMS rendszerek konfigurálására. Vegyünk az első kategóriába eső "dilettánsok" (a szó jó értelmében véve) felvetését miszerint mi került egy ingyenes MySQL szerveren 4 millió forintba? Aki dolgozott már nagyobb rendszereken, az tudja, hogy a MySQL community edition operációs rendszertől függően 3-400 konkurrens kapcsolatnál többet nem tud kiszolgálni. Nem a MySQL miatt, hanem az operációs rendszer thread könyvtára okozza ezt a limitációt.

Szóval itt azért nem olyan egyszerű az ár megállapítás mint elsőre az oldalra való ránézésre gondolná az ember. Nagyon fontos a rendelkezésre állás is. Ezt az site-ot, ha jól tudom 99,99%-os rendelkezésre állásra tervezték (virtuális szerver kilőve kedves Richárd). Ez a szempont mind hardver, mind szoftver oldalról komoly tervezést igényel. Az is nyilvánvaló, hogy egy ilyen kormányzati oldal mindennapos támadásnak van kitéve, tehát a biztonsági policy-ra is kell gondolni.

Megmondom őszintén én ebbe a második kategóriába estem és kb 20 millió forintra becsültem a költségeket. Hibásan, mivel nem voltak ismereteim a műszaki tartalomról, valamint az egész üzleti folyamatról.

Az utolsó kategória ritka mint a fehér holló. Lehet hogy van is ilyen az országban, csak ő nem blogol, hanem dolgozik. Ezek az emberek azon túl, hogy műszaki szempontból helyesen fel tudják mérni a feladat nagyságát, az egész folyamatra kiterjedően megoldást tudnak nyújtani. Mert ugye hiába készítem én el a tökéletes rendszeremet és adom át, gondolni kell azokra az emberekre és folyamatokra, melyek napi szinten használni fogják az infrastruktúrát. Kell oktatás, a folyamatok újra szabályozása, szerkesztőségi rendszer kialakítása, stb.

Így egy kicsit több információval a birtokunkban, lehet mondani, hogy 40-50 millió forint lehet a piaci ára egy ilyen rendszernek. De a részletek nélkül csak szájtépés az egész.

Hozzászólások

Érdemes meghallgatni az

Érdemes meghallgatni az ügyben Kelemen Gábor (Index, Origo, Korridor) véleményét

mysql milyen edition?

Azért kiváncsi vagyok, hogyan boldogul a MySQL enterprise edition ugyanazon az os-en, amelyik szinten 3-400 paralel kapcsolatot kepes kiszolgalni. Hiszen az os thread konyvtara ugyanaz. Btw. a mysql nem mondott meg (tudtommal) rosszat a Linux thread kezeleserol (a freebsd-erol annal inkabb)...

Ütköztem már MySQL

Ütköztem már MySQL maximum kapcsolati problémákba Linux disztribúciókon. Ezeken a MySQL max_connections konfigurációs paraméter növelésével mindenhol meg lehetett oldani a dolgot. Sajnos akkora projektem még nem volt, ahol gondot okozott volna a thread kezelés :(.
Egyébkén, ha jól tudom a MySQL speciális statikusan fordított binárisokkal küszöböli ki az ilyen jellegű akadályokat. Ekkor nem kap szerepet az OS által nyújtott thread könyvtár.
Én általában a SpamAssassin AWL adatbázisát tartom MySQL-en. Ilyen esetben figyelni kell, hogy az SMTP szerver és a MySQL szerver kapcsolati paramétereit ésszerűen összhangba hozzuk.