Pomale nacitani stranek (php, mysql)
Zdravim, mel bych dotaz na rychlost nacitani stranek.
Mam udelane jednoduche zkusebni stranky v php, opravdu jednoduche. Nacitam par zaznamu z mysql db z male tabulky (velikost tabulky ~600 zaznamu), na sloupec dle podminky vyberu mam vytvoreny index. S prihlednutim na dane skutecnosti tzn. zadna slozita stranka a zadna velke tabulky, nacteni stranky mnohdy trva i nekolik sekund, coz me pripada dooost pomale. Mam i stranku na spravu, pres celou jen spustim drop, create a naliti dat tabulky insert a nez se stranka dokonci trva i pres minutu! Jsem zacatecnik, nevim kde delam chybu, ale vse me to pripada doooost tezkopadne! Na jinem hostingu jsem to zatim nezkousel, snazim se najit chybu nejdrive u sebe, jenze nevim kde ji hledat... Kde mohu co zoptimalizovat? Dekuji za rady
Ted insert 600 zaznamu trval 8minut, coz me opravdu pripada pomale
Mam udelane jednoduche zkusebni stranky v php, opravdu jednoduche. Nacitam par zaznamu z mysql db z male tabulky (velikost tabulky ~600 zaznamu), na sloupec dle podminky vyberu mam vytvoreny index. S prihlednutim na dane skutecnosti tzn. zadna slozita stranka a zadna velke tabulky, nacteni stranky mnohdy trva i nekolik sekund, coz me pripada dooost pomale. Mam i stranku na spravu, pres celou jen spustim drop, create a naliti dat tabulky insert a nez se stranka dokonci trva i pres minutu! Jsem zacatecnik, nevim kde delam chybu, ale vse me to pripada doooost tezkopadne! Na jinem hostingu jsem to zatim nezkousel, snazim se najit chybu nejdrive u sebe, jenze nevim kde ji hledat... Kde mohu co zoptimalizovat? Dekuji za rady
Ted insert 600 zaznamu trval 8minut, coz me opravdu pripada pomale
Problém bude v MySQL (na webzdarma je témeř permanentně přetížená), oveřit si to můžeš přidáním dodatečných výstupů mezi různé části skriptu s microtime(). Pokud si nejsi jistý vlastní tvorbou, stejně bych ti tuto kontrolu s vypisováním spotřebovaného času (alespoň pro jednou) doporučil.
Takže optimalizoval bych databázi, a to použitím sqlite místo MySQL.
___
Mimochodem, vytvoření indexu nad slopcem/sloupci ještě neznamená, že jej požadovaný dotaz bude schopný využít. Závisí taky na vlastním dotazu.
Takže optimalizoval bych databázi, a to použitím sqlite místo MySQL.
___
Mimochodem, vytvoření indexu nad slopcem/sloupci ještě neznamená, že jej požadovaný dotaz bude schopný využít. Závisí taky na vlastním dotazu.
Jo, to ja si hlidam, jen me to zarazilo, naplneni 600 zaznamu 8minut! Je fakt, ze to nacitani stranky je nekdy svizne a nekdy zustane trcet, je to fakt bida.. Ja jen hledam, jestli delam chybu nekde ja, nebo je to systemove. Dekuji za dalsi rady
Jinak dotazy, co delam jsou trivialni, a vzdy vybiram jen polozky (sloupce), co potrebuji, zadne slozite a spojite dotazy s hromadou podminek
Složité dotazy s různými joiny problém nebývají, zejména u tak drobných tabulek. Potíže spíš způsobují často opakované dotazy, například víc než 5 dotazů na jedno zobrazení stránky.
Tabulku do 1000 řádek obvykle nemá moc smysl indexovat, pro méně než 100 řádek mohou indexy dotazy dokonce zpomalit. Inserty do indexovaných tabulek jsou pomalejší vždycky.
Tabulku do 1000 řádek obvykle nemá moc smysl indexovat, pro méně než 100 řádek mohou indexy dotazy dokonce zpomalit. Inserty do indexovaných tabulek jsou pomalejší vždycky.
<HTML>Já mám taky radu, ovšem moderátorskou. Neposílej příspěvky do fóra dvakrát. Děkuji.</HTML>
Za dvojity prispevek se omlouvam.
Ani me nejde o inserty, naplnim tabulku (to se me podari tak na potreti) a pak uz je jen pro selecty, ale to nacitani me trapi, je to opravdu pomale.
Nevim, asi to zkusim na jinem webhostingu, pro porovnani...
Ani me nejde o inserty, naplnim tabulku (to se me podari tak na potreti) a pak uz je jen pro selecty, ale to nacitani me trapi, je to opravdu pomale.
Nevim, asi to zkusim na jinem webhostingu, pro porovnani...
Aha, jeste k tomu prispevku
takze problem muze nastat, kdyz plnim postupne daty tak, ze provadim napr. 5 i kdyz jednoduchych selectu na jedno zobrazeni?
takze problem muze nastat, kdyz plnim postupne daty tak, ze provadim napr. 5 i kdyz jednoduchych selectu na jedno zobrazeni?
Teda, naloudovat tabulku 600 radky je opravdu neco ukrutneho... tohle vzdavam
Jestli děláš nějakou diskografii, tak na to by měl SQLite skutečně stačit a s výkonem budeš velmi spokojen. Navíc si můžeš celou databázi vyrobit třeba u sebe a nakopírovat ji jako obyčejný soubor.
Pro představu se mi stránky používající SQLite renderují za 1-2 ms. Upload několika miliónů záznamů není problém.
V MySQL je lepší použít jeden složitější SELECT než 5 jednoduchých. Klidně i z různých tabulek s použitím UNION ALL. Vyplatí se to zejména v případech, kdy výstup takového dotazu je relativně krátký.
SQLite naopak velmi dobře snáší i časté dotazy, na WZ mi zvládá něco přes 30000 jednoduchých SELECTů/s.
Pro představu se mi stránky používající SQLite renderují za 1-2 ms. Upload několika miliónů záznamů není problém.
V MySQL je lepší použít jeden složitější SELECT než 5 jednoduchých. Klidně i z různých tabulek s použitím UNION ALL. Vyplatí se to zejména v případech, kdy výstup takového dotazu je relativně krátký.
SQLite naopak velmi dobře snáší i časté dotazy, na WZ mi zvládá něco přes 30000 jednoduchých SELECTů/s.
Dik za radu, zkusim na to kouknout, jelikoz tohle me fakt neba. Nebudu mit zadne velke tabulky a nebudu delat zadne slozite dotazy (teda zatim s tim nijak nepocitam).
Já naopak počítám s tím, že si do SQLite budu časem ukládat třeba i obrázky. Důvodem je hlavně bezpečnost uploadu před útoky na souborový systém.
Tak k tomu SQLite, jen strucne, co je potreba, abych ho mohl na WZ pouzit?
Stručně? Naučit se pracovat s PDO:
http://www.php.net/manual/en/book.pdo.php
Databáze SQLite je jen obyčejný soubor. Je dobré ho dát do samostatného adresáře s právy 707 a do něj ještě .htaccess zakazující do adresáře přístup. Takových databází můžeš mít, kolik se ti zlíbí (omezeno jen velikostí prostoru na WZ). Většinou však stačí jedna. Dotazovacím jazykem je téměř kompletní množina SQL.
SQLite má proti MySQL navíc například podporu cizích klíčů, dají se dělat složitější dotazy a umí pracovat s uživatelskými funkcemi. Také umí transakce (to, co dělá MySQL, je trapnost sama). Umí fulltext a R-stromy, i když na WZ jsem tyto vlastnosti zatím netestoval. Skvělé je používání parametrizovaných dotazů (další vlastnost, kterou MySQL na WZ neumí).
Nevýhodou je např. horší práce s národními texty (problémy s řazením podle abecedy), ale dá se to obejít. Nedělá typovou kontrolu dat, což je výhodou i nevýhodou současně.
http://www.php.net/manual/en/book.pdo.php
Databáze SQLite je jen obyčejný soubor. Je dobré ho dát do samostatného adresáře s právy 707 a do něj ještě .htaccess zakazující do adresáře přístup. Takových databází můžeš mít, kolik se ti zlíbí (omezeno jen velikostí prostoru na WZ). Většinou však stačí jedna. Dotazovacím jazykem je téměř kompletní množina SQL.
SQLite má proti MySQL navíc například podporu cizích klíčů, dají se dělat složitější dotazy a umí pracovat s uživatelskými funkcemi. Také umí transakce (to, co dělá MySQL, je trapnost sama). Umí fulltext a R-stromy, i když na WZ jsem tyto vlastnosti zatím netestoval. Skvělé je používání parametrizovaných dotazů (další vlastnost, kterou MySQL na WZ neumí).
Nevýhodou je např. horší práce s národními texty (problémy s řazením podle abecedy), ale dá se to obejít. Nedělá typovou kontrolu dat, což je výhodou i nevýhodou současně.
Zitra na to kuknu.
a toto? http://php.net/manual/en/book.sqlite.php
a toto? http://php.net/manual/en/book.sqlite.php
To je manuál pro SQLite verze 2. Pro mne je to nezajímavá záležitost, protože neumí parametrizované dotazy, bez kterých si už nedovedu práci s SQL databází představit.
PDO pracuje s verzí 3, která je podle mne mnohem lepší a má proti dvojce vychytávky těžkého kalibru.
Můžeš je vyzkoušet a porovnat.
PDO pracuje s verzí 3, která je podle mne mnohem lepší a má proti dvojce vychytávky těžkého kalibru.
Můžeš je vyzkoušet a porovnat.
hloupe, ale nejak se v tom motam, jak otestuji, ze to probehlo ok?
$sql = 'DROP TABLE '.$tbl;
$res = $db -> exec($sql);
if $res OK;
else ERR; ?jenze to je i kdyz je spatny prikaz i kdyz to propehne
$sql = 'DROP TABLE '.$tbl;
$res = $db -> exec($sql);
if $res OK;
else ERR; ?jenze to je i kdyz je spatny prikaz i kdyz to propehne
http://www.php.net/manual/en/pdo.exec.php
exec() vrací počet ovlivněných záznamů. Pro smazání tabulky nevhodné. Je potřeba použít metodu query() nebo dvojicí prepare() a execute(). Výsledek se pak dá zjistit metodou errorCode().
exec() vrací počet ovlivněných záznamů. Pro smazání tabulky nevhodné. Je potřeba použít metodu query() nebo dvojicí prepare() a execute(). Výsledek se pak dá zjistit metodou errorCode().
Jasny, trochu jsem se v tom motal, ale musim rict, ze pro me pouziti je to bomba! Zatim jsem teda resil jen create a plneni tabulek, ale faaak vedle mysql jak nebe a dudy... Uvidime jestli neprijdou jeste nejake zaludnosti, ale kdyztak zase Vas pozadam o radu... jdu se prokousavat dale... Moc dekuji za pomoc
Rádo se stalo. Aspoň bude na WZ další spokojený uživatel, který mi (snad) pomůže s osvětou, že databáze není jen MySQL.
Jen pro zajímavost: Na WZ běhají ještě další 4 databáze, které málokdo používá. Dají se najít v phpinfo().
Jen pro zajímavost: Na WZ běhají ještě další 4 databáze, které málokdo používá. Dají se najít v phpinfo().
Tak dalsi asi hloupost, jde zadavat cesta k souboru takto?
$dbh = new PDO("sqlite: ../pokus/data.sbd"); nebo
$dbh = new PDO("sqlite: pokus/data.sbd");
DB: safe_mode/open_basedir prohibits opening pokus/data.sbd
$dbh = new PDO("sqlite: ../pokus/data.sbd"); nebo
$dbh = new PDO("sqlite: pokus/data.sbd");
DB: safe_mode/open_basedir prohibits opening pokus/data.sbd
Ještě jsem při otvírání databáze nezkoušel dávat mezeru za dvojtečku, v dokumentaci není. Možná tam být může, ale nejsem si tím jist.
Adresář "pokus" by měl mít práva 707. Defaultně je 755 a to je špatně. Je nutné to příkazem chmod změnit. Soubor s databází by měl mít práva 606.
Adresář "pokus" by měl mít práva 707. Defaultně je 755 a to je špatně. Je nutné to příkazem chmod změnit. Soubor s databází by měl mít práva 606.
Ok,chyba byla na me strane, ani tak neslo o tu mezeru, ale o cestu,uz se me pletou ruce.
Takze bezpecnost pristupu k datum je definovana dle nastavenych pristupovych prav k souboru, ze?
jeste mam dotaz, ja mam nadefinovany create
"CREATE TABLE pokustabulky (
ppiv VARCHAR(20) PRIMARY KEY NOT NULL,
jmeno VARCHAR(50) NOT NULL,
fyjmeno VARCHAR(50) NULL,
vznik INT NULL, atd...atd...
ale nekde jsem videl jen
"CREATE TABLE pokustabulky (
ppiv TEXT PRIMARY KEY NOT NULL,
jmeno TEXT NOT NULL,
fyjmeno TEXT NULL,
vznik INTEGER NULL, atd...atd...
co je lepsi?
Takze bezpecnost pristupu k datum je definovana dle nastavenych pristupovych prav k souboru, ze?
jeste mam dotaz, ja mam nadefinovany create
"CREATE TABLE pokustabulky (
ppiv VARCHAR(20) PRIMARY KEY NOT NULL,
jmeno VARCHAR(50) NOT NULL,
fyjmeno VARCHAR(50) NULL,
vznik INT NULL, atd...atd...
ale nekde jsem videl jen
"CREATE TABLE pokustabulky (
ppiv TEXT PRIMARY KEY NOT NULL,
jmeno TEXT NOT NULL,
fyjmeno TEXT NULL,
vznik INTEGER NULL, atd...atd...
co je lepsi?
Bezpečnost přístupu k datům se dá zajistit dvěma způsoby:
- databázový soubor pojmenuješ třeba .htdata.sqlite - soubory začínající ".ht" nedokáže Apache zobrazit, ale přes Apache jsou přístupné
- v adresáři s daty vyrobíš soubor .htaccess tak, aby zakázal Apache do toho adresáře vstoupit
SQLite nezná datový typ VARCHAR. Místo něho použij TEXT nebo BLOB. Délku není nutné rezervovat, limit je necelý 1 GB.
Jako primární klíč doporučuji typ
INTEGER PRIMARY KEY AUTOINCREMENT
Automaticky se sloučí se systémovým ID, ušetří se tím trochu místa. ppiv může být UNIQUE, tím se mu vytvoří index typu hash a můžeš podle něj rychle vyhledávat.
- databázový soubor pojmenuješ třeba .htdata.sqlite - soubory začínající ".ht" nedokáže Apache zobrazit, ale přes Apache jsou přístupné
- v adresáři s daty vyrobíš soubor .htaccess tak, aby zakázal Apache do toho adresáře vstoupit
SQLite nezná datový typ VARCHAR. Místo něho použij TEXT nebo BLOB. Délku není nutné rezervovat, limit je necelý 1 GB.
Jako primární klíč doporučuji typ
INTEGER PRIMARY KEY AUTOINCREMENT
Automaticky se sloučí se systémovým ID, ušetří se tím trochu místa. ppiv může být UNIQUE, tím se mu vytvoří index typu hash a můžeš podle něj rychle vyhledávat.
Oprava: Soubory začínající ".ht" nedokáže Apache zobrazit, ale přes PHP jsou přístupné.
Nové příspěvky
Žádosti o obnovení odstavených domén
sspklimky.wz.cz - smazání
Detailní návod na připojení přes Total Commander
nefukční HTTPS s balíčkem základ
SPF a DKIM záznam
FTP server
Propojení PHP a MySQL
Přenos domény
Obnova webu
pomalá odezva webu
Obnovení webu
Tarif zdarma definitivně nepoužitelný kvůli HTTP/HTTPS - druhá část
Dotaz na bod podmínek "využívat poskytnutý prostor jako uložiště pro soubory, zejména pokud k nim nevede odkaz ze stránek a odkazovat se na ně z jiného serveru;
Překročení datového limitu
prosím můj účet přesunout na nejnovější server kvůli automatická instalaci Wordpressu
Nechodí mi email na obnovu hesla
nový web a hostíng
zrušení přesměrování
HTTP
obrazy.unas.cz
DNSSEC u přesunuté domény
Načítací kolečko při nové objednávce domény
Nefunguje domena s WWW
502 bad gateway
Přechod ze zadarmové domény na placenou
Další témata
STATUS
FTP
HTTP
SQL
PHP
© 2002 - 2024 Web zdarma s.r.o. — zvládnete to sami