Pár zajímavých odkazů – CSS Lint, PDF v JS, Sleepsort a ORM

CSS Lint Co CSS Lint kontroluje http://csslint.net/about.html A diskuse http://news.ycombinator.com/item?id=2658948 PDF.JS - JS rendererer PDF v Canvasu Technické detaily http://blog.mozilla.com/cjones/2011/06/15/overview-of-pdf-js-guts/ ORM is an anti-pattern A něco odlehčeného Sleepsort GIANT BUG... causing /usr to be deleted... so sorry....

CSS Lint je docela pěkný tool. Ale mám shodný názor jako pár lidí v diskuzi, že některé ty pravidla jsou pouze názorem autora projektu, jak on si myslí, že se píše "správné CSS". Viz třeba #id selektory.

jojo id selectory taky neivm proc bych nepouzival :) co se ORM tyka, tak ja to rikam porad ze je to nejhorsi zpusob jak pristupovat k datum a celkove pracovat s DB :) navenek to vypada pekne, ale spousty nevyhod sem objevil hned jak jsem se snazil udelat cokoliv sloízitejsiho, hned je uplne jasne ze orm posle jakoukoliv optimalizaci do kose...

ORM dela presne to, co ma - mapuje objektovy model na relacni databaze, coz ma samo o sobe vyhody a nevyhody, a ve vetsine pripadu neni vykon tak dulezity. A pokud uz mam vykonovy problem, tak rozhodne nebudu otrocit databazi a nebo rucne nacitat tridy, jenom proto, ze je to rychlejsi. Vetsina vykonovych problemu ma elegantni a high-level reseni - dam priklad: Psat sql dotazy, protoze jsou rychlejsi, je jako kdybych psal bubble sort v assembleru misto v oop, prestoze existuje chytrejsi reseni, ktere je radove rychlejsi i v oop (quick-sort-like algoritmy)

vedouci muzes prosim rozvest teorii o reseni vykonu? docela by me to zajimalo protoze prave nejake skutecne high tech a high level reseni vykonu databaze a celkove prace s obrovskym (rekneme v radech terabajtu) mnozstvim dat resim, ze nepouzivam orm mi celkove pomohlo, spousty veci jsem jiz dokazal dostat do unosnych cisel, ale jsem ochotny udelat prakticky cokoliv (vcetne prenosu dat pryc z sql) abych zarucil efektivnejsi vyuziti strojoveho casu.

muzu, neni na tom nic slozityho - postavis co nejvic high-level architekturu, protoze ta se bude nejlepe udrzovat z dlouhodobeho hlediska pak vezmes profiler, benchmark, etc. a najdes bottleneck (uzke hrdlo) - zjistis, ze je to db, orm, fw, zapomenuty bug, cokoliv, ale krom jineho budes taky vedet, ve ktere konkretni situaci to nastane - napriklad pri dotazovani xxx s yyy podminkou. pokud jde o dotazy, je to easy, proste budes cachovat cele objekty a nejlepe primo v pameti (memcached) pokud jde o update a nebo insert, uz je to horsi, ale reseni je mnoho - od snizeni poctu updatovanych tabulek, pres chytrejsi cache (zapisedo db a zaroven update cache v pameti), az po celkem brutalni zasah - asynchronni zpracovani, neboli messaging. coz v podstate znamena, ze zakaznik klikne na vygenerovani napriklad statistiky xxx za posledni mesic a jelikoz to proste trva dejmetomu 10 minut, tak se vytvori davka, zobrazi se hlaska, ze pozadavek byl zarazen ke zpracovani a ze mu ta statistika bude poslana mailem... nasledne uz potrebujes jenom "workery", ktere budou kontrolovat "frontu" davek a zpracovavat je. diky vice workerum muzes efektivne vyuzit co nejvic procesoru. no a ted celkem obvykly trik, ktery je kombinaci vsech - opet jde o mesicni statistiky, rocni statistiky, etc. ale tentokrat nejsou generovane "na prani", ale kazdy den o pulnoci, kdyz ve firme nikdo neni - no a pak uz staci jenom cachovat vysledky - tentokrat klidne na disku, porad je to radove rychlejsi nez vypocet - a hadej kde se pouziva neco podobneho? windows prefetch, spekulativni vypocty, apod. pokud jsi ochotny opustit php, tak se podivej na gemstone, uplne ti tim odpadne potreba pro orm a celkove je smalltalk rychlejsi nez php tohle vsechno ale samozrejme predpoklada, ze mas "zivou" aplikaci, kde se neco "dela" - kde jsou nejenom objekty, ale probihaji tam i zmeny, updaty, obcas vymazy, etc. - jestlize mas jenom nejakou kupu dat a potrebujes z nich neco dostat, tak je tvuj "high-level" opravdu jenom databaze.

no muj nejvetsi problem je prave to ze se data v databzi meni strasne casto (prakticky temer kazda akce uzivatele, kterych muze byt tisice online, neco meni v databazi), ale vnuknul si mi napad presunout jeste data, ktera jsou postradatelna a svym zpusobem docasna a nejsou na 100% nutna drzet v databazi, ciste do memcache, jejich upravy a nacitani by pak bylo extrremne rychle, cehoz asi potrebuju dosahnout v tech kritickych sekcich, jen by me zajimalo jak se memcache bude tvarit na takove mnozstvi zaznamu a dat :)) . Jen ten pruser pri vypadku serveru bude trochu mrzet :) ale pro vykon to asi obetuju... Jinak gemstone vypada slibne, urcite se na nej podivam, ale uprimne prepisovat celou aplikaci by bylo silene, snad se mi podari udelat dostatecne upravy v php... program samotny podle me nema zadne znatelne uzke hrdlo, spis mam problem s databazi, kde tece strasne moc dat a hlavne update/insert dotazy jsou bohuzel v urcitych pripadech uz velmi neefektivni :)

program samotny podle me nema zadne znatelne uzke hrdlo

tak je to pomale a nebo neni? :) prvni pravidlo optimalizace je neoptimalizovat, druhe pravidlo je nejdriv merit, potom optimalizovat - je rozdil, kdyz hadas a kdyz vis.

ze se data v databzi meni strasne casto

to zni jako penny aukce - a tam je nejlepsi podvadet - kdyz se nad tim zamyslis, tak proc bys mel pri kazdem requestu neco vykreslovat? pokud to neni zavisle na uzivateli, tak to vykresli jenom jednou a uloz, pri zmene prekresli a uloz - treba do memcached a nebo na disk v pripade ajaxu - o "servirovani" te konkretni casti se pak muze starat primo apache vcetne E-tagu. co vlastne programujes?

neni to penny aukce a je zcela nutne kazdy request zpracovat, vyhodnotit data a vratit vysledek, kdyby to slo jinak, milerad to udelam ale tohle skutecne musi byt presne, nejde nic odhadovat ani prumerovat ani randomizovat :) prvni citovanou vetu jsem myslel tak, ze algoritmy uzite primo v programu jsou v poradku a nemam s nimi vykonnostni problem, problemy mam v soucasne dobe jen na mistech dotazu na databazi :) kazdopadne svym prispevkem jsi mi pomohl, proste jsem do toho cucel moc dlouho a pomalu uz pozapominal co a jak delat, zase si me trochu vratil do reality :) ted uz to snad nejak ukociruji ;)

tak to jsem rad, preju hodne stesti :)

problemy mam v soucasne dobe jen na mistech dotazu na databazi

I databáze mají svoje bottlenecky. Nevím, co všechno jsi zkoušel, ale zapni si slow query log (nebo obdobu, podle toho, jakou DB používáš). Zapnout: http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html Analyzovat: http://dev.mysql.com/doc/refman/5.1/en/mysqldumpslow.html Seřaď si výstup podle total query time a average query time, oba dohromady ti řeknou to nejdůležitější mysqldumpslow -s t mysqldumpslow -s at Další nástřel: Zkoušeli jste na problém hodit víc HW? SSD je prý úplné kouzlo při IO blokování. Rozdělit tabulky na často a zřídka se měnící sloupce (update řádku totiž invaliduje cache pro celou tabulku)? Replikace? Sharding?

Díky, mysql slow query log samozrejme znam a pouzivam, jinak HW mame rekl bych naddimenzovany, problem celkove byl spis v nespravnem uzivani databaze kde stacila cache apod. celkove se sice pres databzi porad musi prohanet stovky az tisice dotazu do minuty a to neluvim o selectech kterych je samotnych jeste vic, ale podarilo se je vyborne optimalizovat nehlede na jejich cachovani, problem bylk spis s castmi systemu, kde museli probihat analyzy z ulozenyc dat, ale spousty dat se povedlo presunouit ciste do cache, uz ted muzu rict ze je to hodne znat, databazi se vyborne ulevilo a vetsina prace se presunula do pameti. Navic sem misto ciste prace v pameti udelal ze se Xty pozadavek ulozi data z cache do databaze takze i pri vypadku energie pripadne jinych chybach na serveru uzivatele neprijdou o vsechny data ale pravdepodobne jen o malkinkou cast.¨a pretso to dotazy zredukovalo na velmi unosnou mez. samozrejme jeste tam je par veci, ktere budu muste doresit, ale uz to nei tak kriticke, ja potreboval vyresit prave tu nejkritictejsi cast a tu jsem vyresil prave diky memcache, za takove nakopnuti patri prave dik vedoucimu, jak jsem mel jen ty jedny oci, tak jsem uplne opomnel tak zrejmou vec jako je moznost tyhle temer docasna data nacpoat do pameti a nemuset pracovat s databazi :)