Portál AbcLinuxu, 1. června 2024 16:19
Každopádně, od hlubšího zájmu mě Firebird odrazuje spojením se jménem Borland.
Tak to se klidně můžete začít zajímat, málokde panuje tak jednotný názor, že Borland je neslušné slovo, jako mezi vývojáři Firebirdu. :-) Už název má naznačovat, že smyslem projektu je znovuzrození InterBase z popela (obrazně řečeno), do kteréhož stavu ji přivedl právě Borland.
2. Mé zkušenosti jsou trochu jiné. Používám Firebird v praxi na serveru ČBF (Duron 1200 MHz). Dokud se nezačaly ve větším používat online přenosy, měl 256 MB paměti, teď má 768 MB. Spojení neukončuji, pokud to není nutné, takže běží i desítky dnů. K vyčerpání paměti ještě nedošlo, Tedy vlastně došlo, ale to bylo v době, kdy počet současně otevřených spojení na databázi dosáhl hodnoty 2048 (a i pak ji vyčerpal spíše Apache než Firebird), od omezení MaxClients u Apache na 768 k tomu nedošlo (ale limitujícím faktorem je tu spíše procesor).
3. Rychlost zápisu do BLOBu byla zcela určitě vyšší než vámi uváděných 200 KB/s, a to i u verze 1.5.1, dokonce i u 1.0.3.
Závěr: pokud se nejedná o FUD, podařilo se vám trefit do nějaké chyby, která nastává za určitých speciálních okolností. Bylo by vhodnější snažit se chybu izolovat a reportovat, než pomlouvat projekt v diskusi.
Ad 2. Databáze je proti té vaší relativně malá, má asi 100 MB. Měl jsem i aplikace, kde měla databáze několik GB, ale tam byla většinou zase jednodušší struktura. Persistentní spojení v PHP používám, ale u online přenosů (kde je zátěž nejvyšší) v současné době nekomunikují PHP skripty s databází přímo, ale přes middleware démona (napsaného v C++). Ten démon používá pool spojení, která jsou navázána trvale po celou dobu běhu démona (obvykle od restartu do restartu). Momentálně běží teprve od 25. března (update jádra), ale i tak už to vychází přibližně 300000 transakcí na spojení.
Ad 3. Zkusím udělat nějaké testy, jestli se mi to podaří reprodukovat.
Tiskni Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.