Predstavujem wisdomtech blog (diskuse)

[J]

V cem je to jine nez tisice jinych blogovacich systemu? Jako jednoduchy projekt kde jste si zkusil sve dovednosti je to asi fajn.

[mirec]

V čom je to iné je napísané v blogu :)

[mirec]

Teda aby som nebol len taký stručný, je to hlavne kombinácia vlastností. Vie to to, čo potrebujem a je to prispôsobené pre technologický blog. Napríklad kombinovanie zvýrazňovania syntaxe som nevidel nikde. Taktiež spolupráca s nginx je dosť špecifická a nevidel som takto implementované cachovanie prakticky nikde. Možno na to ľudia majú dobrý dôvod, aby cachovali iným spôsobom ;)

[J]

Takze ani jeden z tech tisicu blogovacich systemu neni kompatibilni s vasimi pozadavky? Asi bych se citil hodne vyjimecny. V US by vam rikali ze mate “special needs”. U blogovaciho systemu resit z pohledu uzivatele jestli to bezi za nginx nebo apache nebo ululu web server je nesmysl. Nenchte se odradit, jako cviceni programovani je to skvele. Jeste se zeptam, ta firma kterou jste meli nabizela tenhle produkt? A skrachovala proc?

[mirec]

Takze ani jeden z tech tisicu blogovacich systemu neni kompatibilni s vasimi pozadavky?

Nenašiel som nič vhodné.

U blogovaciho systemu resit z pohledu uzivatele jestli to bezi za nginx nebo apache nebo ululu web server je nesmysl.

Píšem o špecifickom technickom riešení. Tu ide o to, že dosahovaná rýchlosť odpovede servera a počet obslúžených požiadaviek je rovnaký, ako pri statickom generátore webu bez nevýhod statického generátora. Takú rýchlosť dosahujem len preto, že webserver priamo cachuje požiadavky a webová aplikácia len premazáva vhodné časti cache. Na to, aby to fungovalo musí webová aplikácia spolupracovať s webovým serverom a preto explicitná požiadavka na nginx.

Jeste se zeptam, ta firma kterou jste meli nabizela tenhle produkt?

Nie, začal som to písať pol roka po ukončení činnosti. Ani neviem, aký by sme za tým mali biznis model.

A skrachovala proc?

Neskrachvala. Posledné roky sme zisk zhruba zdvojnásobovali. Ak by som mal extrapolovať odhadovaný zisk z posledného roku (keďže sme ho neukončili) bolo by to cca 150 000 - 200 000 € / 2 ľudia s prognózou rastu.

[J]

A to srovnani ze nedosahuje rychlosti jste delal jak? Ja jenom ze mame u klienta nginx ktery obsluhuje ~5k pozadavku/s kontinualne ze dvou stroju a ta aplikace je dynamicka. Libi se mi vase mentalni cviceni kolem toho vyvoje, nenechte se mnou odradit, tady jsem za debila.

[mirec]

Ak použijem nginx len ako reverzné proxy a nechám SSL inej službe, potom na 1 jadre mám 61499.78 [#/sec], na jednom stroji celkovo asi 3M požiadaviek/s.

[mirec]

Vlastne ani neviem prečo na to reagujem. Nechcel som, aby sa to zvrhlo na porovnávanie veľkosti penisu. Jednoducho aj v blogu to píšem, že som si chcel vyskúšať niektoré veci s tým, že to bude kanón na vrabca. Výkon porovnateľný so statickým generátorom by sa hodil pri behu na veľmi slabom stroji, alebo ak by sa niektorý z článkov dostal napríklad vysoko na hacker news, ale to neočakávam (aj keď plánujem články písané anglicky).

[kacer_Donald]

Prave naopak. nginx sa masivne pouziva pre svoje cachovacie vlastnosti v CDN na distribuciu obsahu.

[_]

Tak hlavne ze mate CEO xD Proc nejsi CTO?

[mirec]

Ah text som skopíroval zo starého webu a upravil som ho len u seba. Pôvodne som tam mal CTO :) Áno, trochu prehnané na firmu s 2 stálymi vývojármi a pár ďalšími ktorí prichádzali a odchádzali.

[xsubway]

Palec nahoru! Drž se a vylepšuj a vykašli se na negativní reakce prokrastinujících gerontů .-)

[J]

Asi jsem geront, ale jak presne vykepsite hovno kdyz na nej nasypete lentilky?

[_]

Co je to "vykepcsit", ty hnidopichu?

[J]

Nikdy nedelate preklepy hnidopichu?

[_]

Dělám, ale nekibicuju. Si vyber jedno debile.

[J]

Proc?

[_]

Protože nasypání lentilek na hlavu ti nepomůže

[kolcon]

Moc nechapu na co potrebuje k tem ovcim dalsi redakcni system nebo co to ma byt.

Kdyby to aspon psal nejakym normalnim jazykem.

[dolik.rce]

Nestačilo by na to čištění cache proxy_cache_purge? Samozřejmě na separátním rozhraní, nevystaveném do internetu, aby to nemohl smazat kdokoliv. Z aplikace by to pak stačilo provolat při změně obsahu.

[mirec]

Stačilo, ale táto direktíva je len v komerčnej verzii.

[Lenny_]

https://github.com/magiclen/nginx-cache-purge

Tohle samozřejmě řeší spousta lídí, takže alternativa existuje.

[mirec]

Vďaka za info. Ja som predtým pozeral na ngx_cache_purge, ale ten nevie wildcardy. nginx-cache-purge je celkom zaujímavý hack. Spustiť binárku priamo cez nginx ma nenapadlo.

[Max]

Mně také ne, otázkou je, zda to nebude mít nějaký nepěkný overhead.
Zdar Max

[Max]

Alternativa k prdu, řekl bych. Fakt chceš řešit kompilaci a údržbu vlastního Nginx, postavit na tom všechno a pak řešit ještě údržbu modulů (vývoj, bezpečnostní testy apod.), až autor pluginu skončí, jako skončili všichni ostatní (stačí se podívat, kolik modulů je na githubu bez údržby a progressu)?
Já se toho bojím, jak čert kříže, proto jsem do toho nikdy nakonec nešel. Přijde mi to, že si člověk vytváří problémy, místo jejich řešení.
Zdar Max

[Max]

Počkat, teď na to koukám, to nevypadá jako standardní modul, který se kompiluje s Nginx. To vypadá o stupínek líp, než jsem předpokládal.
Zdar Max

[mirec]

Áno, je to externá binárka, ktorú nginx volá. "Moduly" sú samozrejme v nginx problematické, keďže je to monolit, ale toto je omnoho lepšie riešenie.

Na druhej strane pre moje jednoduché použitie mi stále pripadá jednoduchšie namontovať cache adresár s upravenými právami a premazávať ho než expoznúť purge URL na 127.0.0.1 a robiť interný request.

[trekker.dk]

...protože není nic lepšího než sahat programu do dat, se kterými právě pracuje.

[mirec]

Je to linux. Mazanie nerobí žiaden truncate, iba unlink, takže súbor je stále dostupný a nemodifikovaný, kým ho nginx neuzavrie.

[trekker.dk]

TOCTOU

[trekker.dk]

Ale jinak v pohodě, místo řešení, které je dělané přímo pro software, se kterým pracujete, radši používáte něco, co jste si ubastlil sám. Na to máte samozřejmě právo a nenechte se v tom mnou rozptylovat, nejspíš vám to jednou nevybouchne do obličeje.

[mirec]

Ako som už písal, na komerčnú verziu nginx sa mi nechce prechádzať a v open source verzii táto možnosť nie je. Jediná alternatíva, ktorá sa tu spomína funguje ako extra binárka, ktorá maže súbory bez notifikácie webservera, čo je presne to isté, čo robím ja, akurát v mojom prípade bez extra HTTP requestu a separátnej binárky.

[trekker.dk]

Té "extra binárce" se obvykle říká modul.

[xxxs]

snazis sa ho presvedcit, ze je so svojim riesenim nespokojny?

[trekker.dk]

Ne, soudruhu, nesnažím

[mirec]

Tak budiž, môžme to volaať modul.

Len pre zaujímavosť ktorá externá binárka je považovaná u vás za modul? Je alsactl modul awesome wm keď som ju používal na nastavenie hlasitosti? Alebo sa dá považovať za modul len tá externá binárka, ktorá bola špecificky napísaná pre daný softvér, napríklad môj vlastný nástroj pre nastavenie hlasitosti, ktorý som písal presne za účelom toho, aby som ho volal z awesome?

Mimochodom keď sa už bavíme o nginx-cache-purge, vážne toto nepovažujem za dobrý nápad hlavne keď stránkovanie, ktoré je súčasťou cache key používa binárnu serializáciu. Odporúčaný kód by prestal fungovať napríklad v momente keby sa mi do cache_key dostala medzera.

local exitStatus = os.execute("/usr/local/bin/nginx-cache-purge /path/to/cache 1:2 "..ngx.var.my_cache_key)

[trekker.dk]

Tak budiž, môžme to volaať modul.

Ne tak můžeme, jako měli bychom, když je to modul a ne externí binárka. Nebo případně sdílený objektový soubor, kdybychom chtěli přeložit to ".so"

[mirec]

No ako .so sa to ani nedá preložiť. Jedine ako binárka, ktorú nginx zavolá ak dostane request na URL adrese, ktorú si určím. V postate sa to spôsobom volania podobá CGI. Je podľa tejto terminológie CGI modul webservera?

[trekker.dk]

No ako .so sa to ani nedá preložiť.

V pohodě, když trváte na téhle binárce, tak jo. Já bych i tak použil modul.

[mirec]

Lenže ono je to spustiteľná binárka, ktorej je jedno, či ju spustím cez os.execute("/usr/local/bin/nginx-cache-purge") pomocou luy bežiacej v nginxe, alebo cez os.system("/usr/local/bin/nginx-cache-purge") v mojej webovej aplikácii. Ten program nemá žiadnu závislosť na nginx, nepreberá jeho kontex, akurát má v názve nginx. Keby sa to explicitne zakompilovalo do nginx, alebo dynamicky načítalo z .so, alebo aspoň preberalo kontext tak automaticky použijem pomenovanie "modul".

[trekker.dk]

To je všechno pěkné. A klidně si z těch dvou víceméně ekvivalentních řešení spouštění toho programu vyberte, které se vám líbí víc. Já bych zvolil možnost jinou, a to modul.

[Člověk z Horní Dolní]

Díky za představení wisdomtech blogu.

[JiK]

je to pekne, za mne palec nahoru. Kolik casu trva neco takoveho napsat (a vymyslet)?

[mirec]

Blog v djangu s administráciou, viacerými užívateľmi, užívateľskými profilmi, rss, skoro celá funkcionalita - cca 2h (na youtube mám staré video django blog za 15 minút, ale to nemá tagy, kategórie atď).

A teraz tá zábavná vec - detaily. Niečo ako pravidlo 10 - 90 akurát ešte omnoho horšie:

Zvýrazňovanie syntaxe - bolo by to pár minút keby som nechcel spojiť 2 markupy. Kvôli tomu som ten kúsok kódu ladil a mlátil skoro celý deň.

Stránkovanie - tu som robil kurzorové stránkovanie s vlastnou binárnou serializáciou. Teoreticky by som mohol trochu zefektívniť veľkosť kľúčov, keby som dátové typy automaticky odvodil z modelu, ale to by som musel hrabať na privátne API djanga a to som nechcel. Celkovo to boli 3 dni roboty. Kurzorové stránkovanie je tu absolútne zbytočné. Hodí sa pri desaťtisícoch položiek čo nie je tento prípad. Chcel som to však pre iný projekt a existujúce implementácie sú naprd. Existuje implementácia, ktorá je efektívna a vracia, že vždy existujú stránky next / prev, alebo existuje implementácia, ktorá vie zistiť existenciu next / prev ale robí 3 dotazy namiesto 1. Moja implementácia je správna a používa vždy 1 select. Ale ako hovorím, úplne zbytočná optimalizácia, ktorú som chcel do projektu, kde je naopak žiadúca.

Generovanie obrázkov - 2 dni roboty vrátane komunikácie s upstreamom (musel som pretláčať vlastné patche do generátora thumbnailov a aj tak som ho ohýbal tak, že to až nie je pekné).

Cachovanie nginx - pol hodiny

Dizajn - nekonečné množstvo úprav a drobností s ktorými som nebol spokojný, písanie vlastného nástroja na rekompresiu fontov, testovanie desiatok fontov, výber tých, ktoré vyzerajú dosť dobre a majú primeranú veľkosť, odhadom tak 4 dni

No a potom je tu nejaké to benchmarkovanie kvôli jednému užívateľovi v diskusii, ktorý musel machrovať s 5k requestmi na 2 serveroch. Tak som chcel vyskúšať koľko zvládnu 2 servrery u mňa a je to cca 6M. Nakoniec aj samotný blog nie je práve najpomalší, môj notebook s AMD Ryzen 5850u zvládne vyše 50k requestov / s bez cachovania pri drobnej úprave vstavaného WSGI v djangu. Takže tu som sa hral len tak možno 2h. Zo zvedavosti.