Ki bírja tovább Apache vs. Postgres

Linux-haladó

Ki bírja tovább Apache vs. Postgres

  • 615 megtekintés

( einstand | 2004. 11. 05., p – 12:28 )

A kérdés meglehetősen elméleti, mivel egy csomó paraméterről nem tudok elég részletet.
Ami biztos:

van 2 szerver (dual Xeon mind2) Az egyiken apache + php4 a másikon postgres. Mindekttő Sarge-ból.

Az webszerveren lévő portálrendszer sűrűn kérdezgeti az sql szervert (na ezt a sűrüséget nem tudom. Tippeim szerint 20-30 lekérdezés/lekérés)

A kérdés, hogy ha elkezdem duván lekérésekkel bombázni az apache szervert, akkor előbb hal meg az apache, vagy előbb hall meg a postgres?

Illetve igazából ott izgalmas a kérdés, hogy ha megduplázom a webszervert terheléselosztóval, de az sql-t nem, akkor bírja-e az 1 SQL szerver a 2 webszerver támadását.

Tippek is érdekelnek.

m.

( trey | 2004. 11. 05., p – 12:32 )

[quote:cd9cd58bc9="einstand"]Illetve igazából ott izgalmas a kérdés, hogy ha megduplázom a webszervert terheléselosztóval, de az sql-t nem, akkor bírja-e az 1 SQL szerver a 2 webszerver támadását.

Tippek is érdekelnek.

m.

Tipp.

Ha egy SQL backended van, akkor az abban levo memoria merete es a merevlemezek a dontoek. Szerintem jo merevlemezekkel, neadjisten ha van penz RAID10-zel, + megfelelo mennyisegu fizikai RAM-mal (az SQL cache miatt) meg lehet csinalni. Persze egyszer minden eroforras a vegere er... Tesztelni kell, hogy mit bir ki.

Esetleg a Postgres listan megkerdezni, hogy az adott konfig szerintuk mennyi query / sec et bir el. Valamit csak tudnak mondani....

A HUP jelenleg :

Queries per second avg: 47.930

En ebbol mar tudnek szamolni... imho... Igaz ez nem Postgres hanem MySQL...

( cstt v | 2004. 11. 05., p – 12:43 )

Trey !
Honnan (vagy hogyan) jött ki neked ez a "Queries per second avg" érték ? Szeretném nálam is megnézni.

( marczi | 2004. 11. 05., p – 12:44 )

Egyrészt, ha connection pooling-et használsz, akkor sokkal jobb terhelhetőséget érhetsz el, mintha folyamatosan csatlakoznak a kliensek.

Ha 20-30 lekérést csinál a portálrendszered lekérésenként, és nem cache-el semmit, akkor gondolkozz el annak a cseréjén.

Mind az Apache, mind a Postgres nagyon jól konfigurálható az erőforráskezelés tekintetében. Egy olyasmi gépen, ami neked van, 200-500 kapcsolatot simán fenn tud tartani a Postgres párhuzamosan. Ha maga user nem írhat lekérdezéseket, akkor nagyon hazavágni nem tudja, legfeljebb az 501. majd várni fog. De a legjobb az ilyennek úgy elejét venni, már az Apache-nál limitálod a párhuzamosan futtatható workerek számát.

Konkrétan a kérdésedre válaszolva szerintem előbb a Postgres hal le (persze ilyenkor is van még két adatbázis adminisztrátor kapcsolatod), de ez közvetlenül magával fogja rántani az Apache-odat is (legalábbis abban az értelemben, hogy nem fog tudni értelemes válaszokat produkálni), tehát pár másodperccel később az Apache-ot is magával húzza.

Ha tényleg 20-30 lekérés van laponként, akkor inkább úgy oldd meg, hogy mindkét gépen fusson Postgres + Apache is, és a Postgres-eket replikáld.

( ghost | 2004. 11. 05., p – 12:51 )

[quote:ed8f75b1a3="marczi"]Egyrészt, ha connection pooling-et használsz, akkor sokkal jobb terhelhetőséget érhetsz el, mintha folyamatosan csatlakoznak a kliensek.

Ha 20-30 lekérést csinál a portálrendszered lekérésenként, és nem cache-el semmit, akkor gondolkozz el annak a cseréjén.

Mind az Apache, mind a Postgres nagyon jól konfigurálható az erőforráskezelés tekintetében. Egy olyasmi gépen, ami neked van, 200-500 kapcsolatot simán fenn tud tartani a Postgres párhuzamosan. Ha maga user nem írhat lekérdezéseket, akkor nagyon hazavágni nem tudja, legfeljebb az 501. majd várni fog. De a legjobb az ilyennek úgy elejét venni, már az Apache-nál limitálod a párhuzamosan futtatható workerek számát.

Konkrétan a kérdésedre válaszolva szerintem előbb a Postgres hal le (persze ilyenkor is van még két adatbázis adminisztrátor kapcsolatod), de ez közvetlenül magával fogja rántani az Apache-odat is (legalábbis abban az értelemben, hogy nem fog tudni értelemes válaszokat produkálni), tehát pár másodperccel később az Apache-ot is magával húzza.

Ha tényleg 20-30 lekérés van laponként, akkor inkább úgy oldd meg, hogy mindkét gépen fusson Postgres + Apache is, és a Postgres-eket replikáld.

nem tudom hogy az oldalhoz mennyi közöd van de adatbázis ismereteim szerintem 20-30 lekérdezés egy lap előállításához nagyon sok
lehet hogy a portált kellene megvizsgálni először

( Misi | 2004. 11. 05., p – 12:53 )

[quote:feba48321a="cstt"]Trey !
Honnan (vagy hogyan) jött ki neked ez a "Queries per second avg" érték ? Szeretném nálam is megnézni.

status parancs mysql-ben

Misi

( trey | 2004. 11. 05., p – 12:55 )

[quote:0914daa3b8="cstt"]Trey !
Honnan (vagy hogyan) jött ki neked ez a "Queries per second avg" érték ? Szeretném nálam is megnézni.

[code:1:0914daa3b8]
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1023002 to server version: 4.0.20

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> status;
--------------
mysql Ver 12.22 Distrib 4.0.20, for portbld-freebsd5.3 (i386)

[...]

Threads: 8 Questions: 57483620 Slow queries: 686 Opens: 55772 Flush tables: 1 Open tables: 256 Queries per second avg: 48.000
--------------

mysql>[/code:1:0914daa3b8]

( snq- | 2004. 11. 05., p – 12:55 )

[quote:e989301878="cstt"]Trey !
Honnan (vagy hogyan) jött ki neked ez a "Queries per second avg" érték ? Szeretném nálam is megnézni.

mysqladmin status

( trey | 2004. 11. 05., p – 13:12 )

[quote:1dba01971f="marczi"]
Ha tényleg 20-30 lekérés van laponként, akkor inkább úgy oldd meg, hogy mindkét gépen fusson Postgres + Apache is, és a Postgres-eket replikáld.

Ez mondjuk engem erdekelne... Hogyan lehet replikalni olyan SQL szervert, ahol vannak hozzaszolasok is (pl. egy forum)? Magyarul ha egy idoben egyik frontend-en is hozzaszolnak, es a masikon is, akkor a postgresql ossze tudja fesulni az adatbazisokat (ugye igy a ket backenden kulonbozo tartalom van)? Vagy csak az olyan oldalakra gondolsz, ahol nem interaktiv a dolog. Pl. egy forumnal ez erdekes lehet, olvastam a Salashdoton hogy csinaltak meg, de nem latszik egyszeru menetnek...

( einstand | 2004. 11. 05., p – 13:19 )

[quote:ad577967a1="ghost"]
nem tudom hogy az oldalhoz mennyi közöd van de adatbázis ismereteim szerintem 20-30 lekérdezés egy lap előállításához nagyon sok
lehet hogy a portált kellene megvizsgálni először

Nem a szó szoros értelmében vett portál, inkább adatbázis kezelő. Nem én írom és próbáltam pesszimista becslést adni. Valószínű (remélem) ennél jobb a helyzet.

Kössz a tippeket. Majd próbálunk teszteket is, de kiváncsi voltam, hogy érdemes-e egyáltalán dupla webszerverrel indítnai a teszteket.
Most úgy látom a válaszok alapján, hogy önállóan valószínüleg nem, hanem ahhoz az adatbázisszervert is meg kell majd erősíteni.

Amúgy az SQL backend U320 SCSI -n (hardveres raid) fut 1 G memóriával.

( trey | 2004. 11. 05., p – 13:22 )

[quote:d5a7b206de="ghost"]
Amúgy az SQL backend U320 SCSI -n (hardveres raid) fut 1 G memóriával.

Hat az 1GB memoria a mai vilagban mar lassan a munkaallomasokba is keves. SQL szerverbe meg plane. :-)

( Névtelen (nem ellenőrzött) | 2004. 11. 05., p – 13:36 )

[quote:de0613abb7="ghost"]nem tudom hogy az oldalhoz mennyi közöd van de adatbázis ismereteim szerintem 20-30 lekérdezés egy lap előállításához nagyon sok
lehet hogy a portált kellene megvizsgálni először

nem sok.
nekem van olyan intranetes oldalam ami 1000 lekerdezest keszit :)
(mysql)
szerencsere mar kijot a stabill 4.1.7 ami tud subselectet, igy joval kevesebb lesz a lekerdezesek szama.

Megjegyzem egy alap portal ahol minden sql-bol megy, csak a blokkok modulok kiirasanal csinal 20-30 lekerdezest, es akkor meg semmi bonyolult cuccra nem hasznaltuk (mondjuk nem egy konyvelesi intranet renccer)
Jahh valszeg a hup.hu is keszit ennyi lekerdezest, d nem ismerem ezt a CMS-t.

( zsirfeka | 2004. 11. 05., p – 13:41 )

[quote:9933fc2c22="trey"][quote:9933fc2c22="marczi"]
Ha tényleg 20-30 lekérés van laponként, akkor inkább úgy oldd meg, hogy mindkét gépen fusson Postgres + Apache is, és a Postgres-eket replikáld.

Ez mondjuk engem erdekelne... Hogyan lehet replikalni olyan SQL szervert, ahol vannak hozzaszolasok is (pl. egy forum)? Magyarul ha egy idoben egyik frontend-en is hozzaszolnak, es a masikon is, akkor a postgresql ossze tudja fesulni az adatbazisokat (ugye igy a ket backenden kulonbozo tartalom van)? Vagy csak az olyan oldalakra gondolsz, ahol nem interaktiv a dolog. Pl. egy forumnal ez erdekes lehet, olvastam a Salashdoton hogy csinaltak meg, de nem latszik egyszeru menetnek...

en eleg sokat turkaltam postgres-repikacio ugyeben, de mukodo (es nem onleszopassal jaro) megoldast nem nagyon talaltam megfelelot. sok mindent megneztem, de vagy borzalmasan szarul vannak dokumentalva, vagy pedig az alkalmazasokba kell belenyulni (ami sok alkalmazasnal sok munka). remelhetoleg lesz majd official megoldas is, bar tudtommal a 8-asban meg nem.

( ghost | 2004. 11. 05., p – 13:42 )

ez modnjuk megvalósítástól is nagyban függ

mert pl a híreket megcsinálhatod ugy hogy mondjuk 50 hír kerül ki akkor csinálsz egy lekérdezést amire kijön a hirek szövege
meg egyet amire a feladó meg ....

vagy az egészet egy lekérdezésbe teszed és a kimenetet tovább feldolgozod

( Névtelen (nem ellenőrzött) | 2004. 11. 05., p – 13:50 )

[quote:de88f21b47="ghost"]ez modnjuk megvalósítástól is nagyban függ

mert pl a híreket megcsinálhatod ugy hogy mondjuk 50 hír kerül ki akkor csinálsz egy lekérdezést amire kijön a hirek szövege
meg egyet amire a feladó meg ....

vagy az egészet egy lekérdezésbe teszed és a kimenetet tovább feldolgozod

meg azt sem kell csinalnod :)
ugyanis a mysql-ben nem veletlen van lehetoseg ket tabla osszekapcsolasara.
aze az gagyesz ha valaki egy query ciklusaba tesz meg egy query-t amikor lazan osszekapcsolhato a ket tabla valahogy igy:
$results = mysql_query("SELECT * FROM tabla1,tabla2 WHERE (tabla1.user_id = tabla2.id)") or die( mysql_error());

( Névtelen (nem ellenőrzött) | 2004. 11. 05., p – 13:52 )

ghost: amugy nem emiatt lehet sok sqllekerdezes/lekeres eseten, hanem pl:
online userblokk, legfrisebb forumok, menuk, stb...
mind mind minimum 1 lekerdezes, de persze connectalni tobb mint valoszinu, hogy csak egyszer fog az sql-hez a coder :)

( ghost | 2004. 11. 05., p – 13:53 )

[quote:3abbdf0ce1="Oregon"][quote:3abbdf0ce1="ghost"]ez modnjuk megvalósítástól is nagyban függ

mert pl a híreket megcsinálhatod ugy hogy mondjuk 50 hír kerül ki akkor csinálsz egy lekérdezést amire kijön a hirek szövege
meg egyet amire a feladó meg ....

vagy az egészet egy lekérdezésbe teszed és a kimenetet tovább feldolgozod

meg azt sem kell csinalnod :)
ugyanis a mysql-ben nem veletlen van lehetoseg ket tabla osszekapcsolasara.
aze az gagyesz ha valaki egy query ciklusaba tesz meg egy query-t amikor lazan osszekapcsolhato a ket tabla valahogy igy:
$results = mysql_query("SELECT * FROM tabla1,tabla2 WHERE (tabla1.user_id = tabla2.id)") or die( mysql_error());

én is a join ra gondoltam csak probáltam érthetően megfogalmazni (nemrég irtam a prog.hu-ra)

a mysql támogatja a replikálást
http://dev.mysql.com/doc/mysql/en/Replication_FAQ.html

( trey | 2004. 11. 05., p – 14:06 )

[quote:8a9812de0f="zsirfeka"][quote:8a9812de0f="trey"][quote:8a9812de0f="marczi"]
Ha tényleg 20-30 lekérés van laponként, akkor inkább úgy oldd meg, hogy mindkét gépen fusson Postgres + Apache is, és a Postgres-eket replikáld.

Ez mondjuk engem erdekelne... Hogyan lehet replikalni olyan SQL szervert, ahol vannak hozzaszolasok is (pl. egy forum)? Magyarul ha egy idoben egyik frontend-en is hozzaszolnak, es a masikon is, akkor a postgresql ossze tudja fesulni az adatbazisokat (ugye igy a ket backenden kulonbozo tartalom van)? Vagy csak az olyan oldalakra gondolsz, ahol nem interaktiv a dolog. Pl. egy forumnal ez erdekes lehet, olvastam a Salashdoton hogy csinaltak meg, de nem latszik egyszeru menetnek...

en eleg sokat turkaltam postgres-repikacio ugyeben, de mukodo (es nem onleszopassal jaro) megoldast nem nagyon talaltam megfelelot. sok mindent megneztem, de vagy borzalmasan szarul vannak dokumentalva, vagy pedig az alkalmazasokba kell belenyulni (ami sok alkalmazasnal sok munka). remelhetoleg lesz majd official megoldas is, bar tudtommal a 8-asban meg nem.

E teren a MySQL sem jobb... Vannak persze penzes megoldasok...

( koko | 2004. 11. 05., p – 15:57 )

Az apache-od hamarabb fog megtelni mint az SQL-ed.
Persze nemárt odafigyelni pár dologra:
- kverik minimalizálása/összevonása
- indexek ellenőrzése, optimalizálása
- megfelelő tabespace,datatype használata
- megfelelő tabel/index/sort cache/buffer hangolás

Ezek mellett egy threadelt sql simán elbír egy apachenyi kverivel, főleg ha php generálja.

A replikációhoz meg annyit, hogy mysqlt tapasztalatból ajánlhatom, de mintha postgres is ezt hájpolta volna új verziójában.

KJ.