Web CGI + Postgres user/role legjobb megoldás

Adott egy webes adat nyilvántartó/feldolgozó program.

Apache ( minden process külön szál ) cgi, fastcgi + Postgres ( tranzakció kezeléssel ). Postgres adatbázis user/role: 5 db, program felhasználó több mint 100 fő, cgi fájl: 100 db, fastcgi: 300 db ( főleg ajax kommunikáció ). Sima cgi nyitja/zárja az adatbázis kapcsolatot, fastcgi esetén folyamatosan nyitva. A felhasználók folyamatosan használják mind a 3-400 db fájlt, jogosultságuk szerint.

Kérdés: mi a legjobb megoldás az adat kiszolgálás kapacitás/gyorsaság szempontjából:

- ha az adott cgi/fastcgi mindig ugyanazt a Postgres usert/role-t használja az adat kapcsolat felépítéséhez, vagy pedig

- ha ugyanarra az adatbázis jogosultságra létrehozok több Postgres usert is, és a cgi/fastcgi váltogat az egyes Postgres userek között, és mindig másik usert használ az adatkapcsolat felépítéséhez.

Arra keresem a választ, hogy ahhoz képest: ha a cgi-k folyamatosan csak egy user nevében építik fel a kapcsolatot, és egy user/role nevében érkezik egyszerre többszáz kérés, segíti-e a gyorsaságot az, ha több userre lebontva érkeznek az adott esetben konkurens kérések.

Hozzászólások

Szerintem jobban jársz, ha újraírod. Több libet, patternt, bármit találsz bármelyik problémádra, mint a 20 éve még jónak gondolt megoldásra épített cuccoddal. Azóta fejlődtek a nyelvek és az OS-ek is, processzen belül is tudod hatékonyan kezelni cgivel/fastcgivel megoldott problémákat.

Ugyanaz a szerver fogja kiszolgálni, ugyanannyi erőforrással. Miért segítene ha több user nevében csatlakozol?

Connection pool legyen. 
Az tök mindegy hogy hány user nevében jön x kérés, sőt, cache szempontból talán jobb is ha egy user nevében jön.
Több mint valószínű hogy a postgres-t lehet tuningolni, kevesen szoktak érteni hozzá.

zászló, zászló, szív

Arra keresem a választ, hogy ahhoz képest: ha a cgi-k folyamatosan csak egy user nevében építik fel a kapcsolatot, és egy user/role nevében érkezik egyszerre többszáz kérés, segíti-e a gyorsaságot az, ha több userre lebontva érkeznek az adott esetben konkurens kérések.

Ez így teljesen mindegy.

Amivel lényegi eredményt érhetnél el, az az, hogy a felépített connection nem bomlik le minden kérés kiszolgálása után, és épül fel egy új, mert a connection eldobásával eldobsz mindent, ami gyorsítaná ugyanazt a lekérdezést ugyanazon az adatbázison. De szerintem ilyen környezetben az értelmes connection pool kb. lehetetlen küldetés.

Milyen nyelv? Célszerűnek látszik valami framework alá betuszkolni ami legalább adna db connection poolt.

zászló, zászló, szív