obmedzenia filesystemu UFS2: Too many links

Radim Kolar kolar.radim at gmail.com
Tue Jan 16 09:57:41 CET 2007


> Mam tu cest tahat niekedy obrazky (alebo vobec nejaky content) z jedneho
> portalu, ktory podla vsetkeho ma tieto obrazky ulozene v databaze
> (pravdepodobne nejaky Oracle). Aplikacia je napisana v Jave.  Priemerny
> cas odpovede tohto portalu na request je 3 sekundy. Podla vas je toto
> OK? Podla mna nie.
Podle mych testu umi apache obsluzit cca 1200 statickych stranek/sec.
V praxi toho u nas tezko dosahne, vetsina uzivatelu nema tak rychle
linky aby ten server takto zatizila. V logach jsou spicky okolo
250/sec. Pristup k DB je odhadem 10x pomalejsi (kdyz vyjdu z
benchmarku mysql vs sqlite), coz by melo bohate stacit. Pokud je
potreba pro nalezeni obrazku vice nez jeden SQL dotaz, pouzijte stored
proceduru.

Udelal jsem jednoduchy test se ZODB (coz je dost pomala databaze) a
stroj na kterem trva buildworld+kernel 14 hodin zvladal lehce pres 20
obrazku/sec. Na rychlem stroji bude nejpomalejsi casti procesu stejne
nacitani dat z disku.

> Preto uz prosim nerieste to, ako ukladat obrazky do databazy. Naozaj by
> som take riesenie nenasadil. ;-) Proste pri vysokej navstevnosti nie je
> mozne mat ulozene obrazky v databaze. Nech mate sebelepsie zelezo.
Pokud mate tak vysokou navstevnost, ze to dany stoj nestiha, tak se
proste prida dalsi masina. Dedicated server dnes stoji cca 100
usd/mesic, coz server s vysokou navstevnosti vydela za par hodin.
Databaze umi dnes bezne replikaci/failover/pooling. Navic se tim
podstatne zvysi odolnost aplikace vuci vypadkum, coz je velice zadouci
nebot downtime byva u serveru s vysokou navstevnosti velmi velmi
drahy.



More information about the Users-l mailing list