rychlost databází

Využiji toto téma pro položení ještě jedné otázky.Jedná se opět o rychlost databází.Když na svém PC měřím rychlost vykonávání skriptu, tak většina stránek se načítá za cca 10-50ms s použitím databází. Pokud bych ovšem v některých případech, kde by to bylo možné použil zápisy do klasického php souboru místo toho, abych měl naprostou většinu dat v databázi tak se načítání zrychlí cca 500 násobně!Samozřejmě se dost často bez databází neobejdu, takže nahrazení by bylo možné tak na 30% stránek, při extrémní práci by se šlo dostat dokonce i mnohem výše (75%) ovšem stránka by byla velmi složitá, spousta věcí by se poměrně špatně aktualizovala a celá aplikace by dost ztratila na přehlednosti.Jde mi o náročnost na server, pravděpodobně výpočetní čas není jediné o co jde ale ostatní parametry jsou při obou způsobech stejné, jednotlivé stránky mají velikost většinou velmi malou (10-100kB)Je mi jasné, že se to nedá nijak paušalizovat, jde mi spíše o to, abych při vyšší návštěvnosti nepotřeboval zbytečně drahé hostingy, na které by si projekt třeba těžko nebo zbytečně vydělával.mám na mysli, aby mi např. při návštěvnosti // jen příklady jak bych si to zhruba při podobné rychlosti načítání představoval.200 UIP/1200 zobrazení stačil běžný hosting (50Kč/měsíc)1000 UIP/6000 zobrazení stačil levný VPS (okolo 200 Kč/měsíc)5000 UIP/30 000 zobrazení stačil dražší VPS (500-750 Kč/měsíc)

Používejte nástroje k tomu, k čemu jsou určené, a neřešte hlouposti. Data se ukládají do DB, logika se řeší v aplikaci. Rychlost se netestuje na domácím PC s jediným uživatelem. Premature optimization is the root of all evil.

databaze je nejlepsi uloznou dat kterou muzete pouzit (mluvim o datech textovych, ciselnych, datumy apod. v zadnem pripade o souborech apod.) to ze vam doma na pocitaci jede nacitani dat rychleji ze souboru je dano tim ze doma na vasem pocitaci neni zadna zatez, ve vysledku ale na serveru pojede disk jako sroub a tak se databazova cache v pameti samozrejme osvedci a situace se uplne otoci oproti vasemu soucasnemu testovani ;) nehlede na to ze dokud nemate obri databaze a navstevnost v tisicich, desetitisich nebo treba i vic tak jakekoliv kolisani v radech milisekund nemuzete poznat na vyslednem case/vykonu :)

Pokial sa ale data zobrazuju tie iste. Tak by som skor sa zaujimal nad pouzitim nejakej cache. Atd. Kazdopadne ked to budu relativne jednoduche veci. nema vyznam menit nieco ine namiesto mysql.

nordic: Každý rozumný databázový engine si výsledky dotazů ukládá do vlastní cache, takže opakovaný stejný dotaz tahá data z cache a nemusí sahat přímo do DB.

nejvice casu zabere pripojovani se do databaze. Pokud vytvaris spojeni do databaze na kazde strace, tak prepsat aplikaci, aby se pripojovala jen jednou na zacatku.

Napsal xdream;623192

nejvice casu zabere pripojovani se do databaze. Pokud vytvaris spojeni do databaze na kazde strace, tak prepsat aplikaci, aby se pripojovala jen jednou na zacatku.

tohle neni pravda, zvlast pokud mas databazi na stejnym stroji jako apache tak je pripojeni uplne zanedbatelne

Napsal xdream;623192

nejvice casu zabere pripojovani se do databaze. Pokud vytvaris spojeni do databaze na kazde strace, tak prepsat aplikaci, aby se pripojovala jen jednou na zacatku.

Mohl bys to prosim dolozit nejakymi testy nebo cisly? Protoze o necem takovem jsem v zivote neslysel a prijde mi to jako pekna hloupost. Pripojeni na DB je odeslani jmena hesla a db vrati overeni ano/ne, zatimco jen k vykonani SQL dotazu se musi provest overeni pripojeni, prekompilace SQL (kontrola syntaxe), naplanovani a optimalizace spusteni, spusteni SQL, ulozeni vracenych vysledku a poslani vysledku. Nejak si nedovedu predstavit situaci kdy by tohle vsechni zabralo mene casu nez pripojeni na DB (Pokud teda nemas DB nekde na pomale lince na druhem konci sveta, coz je ale pak jasny problem rozlozeni infrastruktury)

Napsal duben;623207

Mohl bys to prosim dolozit nejakymi testy nebo cisly? Protoze o necem takovem jsem v zivote neslysel a prijde mi to jako pekna hloupost. Pripojeni na DB je odeslani jmena hesla a db vrati overeni ano/ne, zatimco jen k vykonani SQL dotazu se musi provest overeni pripojeni, prekompilace SQL (kontrola syntaxe), naplanovani a optimalizace spusteni, spusteni SQL, ulozeni vracenych vysledku a poslani vysledku. Nejak si nedovedu predstavit situaci kdy by tohle vsechni zabralo mene casu nez pripojeni na DB (Pokud teda nemas DB nekde na pomale lince na druhem konci sveta, coz je ale pak jasny problem rozlozeni infrastruktury)

Je to stara bezne znama vec, zda ma aplikace pouzivat jen jedno pripojeni (nebo pool) do databaze, nebo si kazdy skript otevira svoje pripojeni. Dnes uz je to bezne skryto frameworkem, ktery to dela za nas.Hledej na webu persistend database connection. Trebahttp://developers.sun.com/databases/articles/mysql_php2.html#5

Pripojeni na DB je odeslani jmena hesla a db vrati overeni ano/ne

no to neni, samozrejme zalezi na typu databaze, ale server musi pro kazde pripojeni rezervovat zdroje a to neco stojiSamozrejme pokud delas do DB jeden dotaz, ktery minutu, tak te rezie na pripojeni do databaze nemusi stresovat.

xdream perzistentni pripojeni dela vetsinou vic problemu nez uzitku a pouzival bych ho skutecne jen pokud by mysql byla na jinem stroji na pomale lince... porad trvam an tom ze pripojeni k mysql je oproti dalsi praci s ni uplne zanedbatelne

xdream, opět nebudu souhlasit. Persistend connection způsobuje spoustu problémů, pokud se zapomene ukončit spojení, není ošetřené ukončení spojení při spadnutí scriptu, nebo script běží dlouho, pak je po celou dobu alokováno na serveru jedno připojení, kterých je ale omezené množství a právě údržba takového spojení bere mnohem víc paměti, kterou by mohlo používat jiné připojení. Na opravdu hodně vytížených DB pak něco takového může vést k vyčerpání volných kapacit. Přesně jak píše Aleš Jiříček, jeho využítí má praktický význam v naprosto jiném případě než jako optimalizační výkonový prostředek. Často se zmiňuje u webhostingu, když nějaké PHP přetěžuje DB, že vytváří moc connection na DB s doporučením na pezistentní připojení. Jenže to je většinou cesta do pekel. Už jenom proto, že nadměrný počet připojení co zatěžuje MySQL v takovou chvíli vypovídá v 99 procentech případů o špatně napsaném přístupu do DB a špatném návrhu DB, takže ve výsledku script dlouho blokuje právě připojení (které v té době ani není perzistentní), nebo není ošetřené uzavření connections (v nějaké větvi se na to zapomene) a prodleva mezi automatickým schozením a proti ručnímu close connection pak není zanedbatelné. To co říkáš, že je známá věc a že to řeší framework není pravda. Nevím kolik frameworků používáš a kolik z nich jsi studoval uvnitř. Ale většina frameworků a MySQL class používá open connection, pak se na této connection používají spouštění dotazů a na konci se spojení zavře. To ale není perzistentní ... to je jen navázání spojení a pak využívání jeho ID identifikátoru pro spouštění. A to je něco jiného než udělat open connection s parametrem persistend.Pokud narážíš na to, aby se před každým vyvolaným dotazem nedělalo open_connection, mysql_query, close_connection ... a to se neopakovalo třeba 10x na zavolání stránky. Tak to je snad samozřejmé, že takhle se to nedělá. A pokud to tak někdo dělá tak nezná ani rozumné základy práce s DB.