Vaše tipy pro zrychlení a optimalizaci PHP/MySQL

13. 10. 2007 14:14:03

Nedávný kolaps databáze u hostingu a následná suspendace účtu :andel: mě donutili zamyslet se nad optimalizací provozu mých skriptů a databází. Nejsem programátor, jen pouhý slepovač kódů, nicméně napadly mě tyhle tipy:

- při sql dotazech nepoužívat SELECT * (pokud to jde)

- používat v tabulkách Indexy

- nastavit Cron pro opravu a optimalizaci tabulek

- v php používat mysql_free_result

- místo mysql_numrows použít SELECT COUNT()

Přidejte další vaše tipy, jak se vyhnout situaci, kdy koukáte na vytížení serveru a vidíte "Server Load 130 (8 cpus)" :andel:

13. 10. 2007 14:14:03

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24258

toshi

(4 hodnocení)

13. 10. 2007 14:34:42

to už musí bejt safra velká databáze ne ? :)

- pdo->prepare() u často opakovaných dotazů

- sql cache !

- cachovat přímo výstupy ze skriptů ?

13. 10. 2007 14:34:42

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24257

Martin Schlemmer

(36 hodnocení)

13. 10. 2007 16:35:03

- indexy

- cache výstupů

13. 10. 2007 16:35:03

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24256

Jakub Stacho

(20 hodnocení)

13. 10. 2007 17:46:25

- Pokud ten rozdíl dělá jeden-dva sloupce, tak SELECT * není zas takové zlo.

- mysql_free_result má význam možná u nějakých dlouhoběžících skriptů nebo u nepředstavitelně rozsáhlých tabulek. Pokud se zavolá pár řádků před koncem skriptu, nemá to žádný význam.

- optimalizace tabulky má efekt jen po nějakých rozsáhlých změnách tabulky (je to něco podobného, jako defragmentace HDD). Dělat to každý den je zbytečnost.

- SELECT COUNT rozhodně ano.

- Cache výstupů rozhodně ano. Odpadne tím prakticky veškerá zátěž serveru. V PHP se to nejběžněji dělá přes output buffer.

13. 10. 2007 17:46:25

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24255

Veros

(1 hodnocení)

13. 10. 2007 19:57:59

- Zamýšlet se nad časovou složitostí použitých algoritmů (complexity matters). U cizích algoritmů aspoň přečíst a zamyslet se, jestli to nejde efektivněji.

- Nastavovat hlavičky Cache-control (Etag, a další) i pro dynamické stránky - je-li to možné. (srovnával jsem teď počet přístupů s cachováním a bez. Přestože se cachují zejména kaskádové styly a grafika, počet dotazů klesl na polovinu).

- Věci, které se nemusí dělat hned, udělat až za chvíli. (Místo odeslání e-mailu strčím e-mail do interní fronty a pošlu je najednou z plánovače). Neušetří to sice moc čas procesoru, ale uživatel má rychlejší odezvu.

- Profilovat a koukat, kde přesně to drhne.

- A jak už tady padlo: Pokud můžeš, tak předpočítané výsledky ukládat do cache a využívat. (I proto mám rád pro web dlouho běžící procesy. Takový bumbrlíček má třeba 100MB, ale ušetří si spoustu sahání do databáze, protože si je drží v paměti).

--Věroš

13. 10. 2007 19:57:59

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24254

paia

15. 10. 2007 15:07:41

optimalizaci databaze a dotazu resim v ramci svyho diskuzniho fora vpodstate neustale a dosel jsem ke stejnym vysledkum. akorat to cachovani jaksi aplikovat nemuzu, protoze zrovna ten dotaz, ktery to nejvic zatezuje a zpomaluje musi jet na aktualnimi daty, ktery se meni prakticky kazdou vterinu.

15. 10. 2007 15:07:41

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24253

Fuck You

(1 hodnocení)

16. 10. 2007 07:11:33

Vzít si profiler, najít úzké hrdlo a na to se zaměřit. Když pojedeš takhle poslepu, tak si jenom přiděláváš práci.

Pokud jsi si jistý, že to zdržuje práce s DB, tak si loguj dotazy, pak si zjisti jak rychle se provádí a uvidíš, které potřebují předělat. Pokud používáš MySQL 5, nauč se používat views.

16. 10. 2007 07:11:33

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24252

Jersák Martin

(23 hodnocení)

16. 10. 2007 10:47:35

Napsal tracy;16569

- mysql_free_result má význam možná u nějakých dlouhoběžících skriptů nebo u nepředstavitelně rozsáhlých tabulek. Pokud se zavolá pár řádků před koncem skriptu, nemá to žádný význam.

Má smysl vždycky i s mysql_close, i když je to poslední řádek zdrojáku. :nono: Stává se, že určité procento požadavků zůstane "viset" a blokuje stroj. Když některá aplikace žere železo na plno moje první optimalizace je vždy zkontrolování vyprazdňování paměti.

- další tip: používání "LIMIT" v sql dotazech, také šetří železo.

16. 10. 2007 10:47:35

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24251

mallat

16. 10. 2007 10:53:51

Všemožné rady tu už padly, ale zaměřil bych se na pár bodů pokud se dostane do křížku s opravdu velkou DB a máte potíže s výkonem.

Pokud provádíte select/insert/update je dobré částečně porozumnět tomu, jak to pro nás ta chudinka dělá a si nejzajímavější je,

- podmínka se vyhodnocuje zleva doprava, zaleží tedy na pořadi.

- rychleji se hledá v číslech, než v řetězci

- při insertu/update se indexy musi vytvorit

- optimalizujte dotazy, indexy (zde si dovolím jednu radu, dle poučky "lépe se hledá v číslech" mějme v tabulce např. url a potřebujem v nich hledat, do tabulky se přidá pomocnej sloupec s CRC32 daného url a a select pak má v podmince crcurl=CRC32('http://examle.com/') AND url='http://examle.com/' ), připadně použijte předbagrování dat (typicky pro součty za období a podobně, kdy si můžete skovávat sumy např po týdnech a k nim přičítat jen aktuální)

- s indexama to nepřehánějte, pokud do tabulky i vkládáte

- rozdělte tabulky na ty do kterých vlkládáte a na ty z kterých vybíráte, mezi nima přenášejte data dávkově a případně předzpracujte

- zadumejte, jestli Vám nestačej tabulky typu MyISAM (Non-transaction-safe), nebo potřebujete InnoDB (Transaction-safe). InnoDB jsou řádově pomalejší pro insert/update (kdo nevěří, muže si to sám lehce odzkoušet)

Jiste se najde spoustu dalších věcí, ale to je to co mě zrovna napadlo.

16. 10. 2007 10:53:51

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24250

dysmusax

(9 hodnocení)

16. 10. 2007 10:57:26

Dneska se na diggu objevil zajímavý článek 40 Tips for optimizing your php Code

16. 10. 2007 10:57:26

https://webtrh.cz/diskuse/vase-tipy-pro-zrychleni-a-optimalizaci-php-mysql#reply24249

Jakub Stacho

(20 hodnocení)

16. 10. 2007 12:37:46

Napsal jersywoo;16746
Má smysl vždycky i s mysql_close, i když je to poslední řádek zdrojáku. Stává se, že určité procento požadavků zůstane "viset" a blokuje stroj.

Vycházím z php dokumentace: