Vlákno názorů k článku Reason: programovací jazyk od Facebooku nejen pro webové aplikace od Adam - javascript na kazdy den :)
-
. . (neregistrovaný)
mě by zajímalo jak lidi hlídají javascript aplikace v produkci, dělat post portem analýzu javascript aplikace je dost peklo, stejně tak zjišťovat proč js aplikace stojí, proč má tolik paměti, proč se výrazně zpomalila atd. Facebook a jiní velcí na to mají vlastní closed source nástroje, v open source světě těch nástrojů moc není.
Máte někdo s tím zkušenosti nebo to nikdo neřešíte, restartujete aplikaci když zlobí a jedete dál?
-
spencer (neregistrovaný)
Delal jsem na aplikaci pro financni brookery kde cele MVC bylo ve frontendu a browser se vypinal tak jednou za mesic kdyz se updatoval windows. Takze hlidat memory leaky byla povinnost. Kazdopadne na to neni treba zadne extra nastroje, standardni devtoolsy v Chrome a Firefoxu jsou pomerne bohate + par specializovanych pluginu a jde to. Zadna velka magie to neni. Obvyklym vinnikem byly jquery eventy a nepozornost pri code review jestli pri zahozeni objecktu ci neceho na obrazovce byly vypnuty taky napojene eventy a pod. Mnoho z toho bylo odhaleno i pri testovani, meli jsme worklflow takovy, ze nez sly kody na produkci tak to jeste nejaky tyden jelo na stagingu v zatezovem testu a kdyz pamet nekde nekontrolovane rostla tak uz to Jenkins reportoval.
-
backup (neregistrovaný)
[...] Takze hlidat memory leaky byla povinnost. [...]
[...] nepozornost pri code review [...]
Tohle platilo pred 30 lety, kdy se pouzivaly prehistoricke jazyky jak C. Dnes v moderni dobe tohle prece neni vubec potreba. Moderni programator sahne k pythonu, javascriptu nebo nejakemu funcionalnimu jazyku a vsechny ty problemy minulosti jsou za nej vyreseny. Nakonec, jaky by melo smysl pouzivat moderni programovaci jazyky, kdyby museli programtori jako pred 30 let davat pozor pri code review ??
-
Popravde, reseni tehle veci je proti kompilovanym jazykum uplna pohoda :)
Tech nastroju v dusledku ani neni moc potreba - staci treba Chrome DevTools, to je tak silny nastroj, ze velmi pravdepodobne nebudes potrebovat zadny dalsi pro tyhle bezne problemy (pamet, debugging, rychlost).
A s tim zpomalenim / stanim - v tomhle je velkou vyhodou (ano, je pravda ze v node to 100 % neplati, ale skoro), ze JS je event driven jazyk - tech veci, co mohou aplikaci zastavit, v JS moc nenajdes (vyjimka - nektere node knihovny).Disclaimer: Nerikam, ze Node (ci obecne single threaded async processing model) je lepsi nez jine jazyky / technologie / pristupy, ale ze diky tomu nektere problemy proste nevznikaji a/nebo se lepe debugguji :)
P.S.: Pokud to nahodou nekdo nezna, tak pro ladeni node aplikace v DevTools staci spustit node s parametrem --inspect a pak otevrit chrome://inspect v Chrome a voila.
-
. . (neregistrovaný)
díky, tohle ale v praxi nefunguje, mluvím hlavně o node.js, aplikace v prohlížečích se ladí o trochu lépe, většinou nepracují s příliš daty a neřeší IO, blokující volání lze přes debugger odhalit snadno.
Mluvím o tom, když v node.js (či obecně v js) mi blokuje něco event looopu (parsování 10M jsonu), v téhle době ani --inspect ti nic pořádného neřekne (krom toho --inspect nefunguje řádně na všech verzích, způsobuje pád procesu, má šílené nároky na produkční provoz a nelze ho zapnout již u běžícího procesu).
Dalším velkým problémem, kdy vzniká memory leaky je zapomenutý callback, GC, které nestihlo promazat data, přeplněný IO buffer (input, output). K tomu díky features, react.js a dalším běžně použivaným frameworkům mi callstack moc neřekne, nedokážu se ani snadno dostat k datům z heapdumpu.
Nepomlouvám js (či node.js), nějaké problémy musejí řešit i u jiných prostředí v produkci. Zajímalo mě, jestli někdo nemá nějaké typy. Skončil jsem dopsanými dtrace probes i na nové LTS verze (už to moc nikdo neudržuje), dopsal jsem si vlastní thread pro monitoring GC, detekci zapomenutých callbacků, detekci dlouhých blockových volání atd. Je to ale náročné udržovat a už se tomu tolik nevěnuji. Zajímalo mě, jestli někdo řeší produkční provoz js backendu.
-
Tak na to většinou slouží profilery, ne? Tam zjistím, v jaké funkci mi to tráví čas, dohledat proč je pak už samozřejmě na programátorovi, ale to je u většiny jazyků stejné.
node.js není špatný, napsat prototyp v tom trvá chvilku, ale pohled pod pokličku a náklady na údržbu jsou důvody, proč už jej téměř nepoužíváme. Na jednorázové věci je ale vynikající. -
. . (neregistrovaný)
ano, na to je profiler a testování na nějakém "horké křesle", ale generická či testovací data často neodpovídají produkci, kde sice často podle call stacku, který si vytáhnu z paměti zjistím, na které funkci to vázne, ale už mi chybí ten důvod (mnou zmiňovaný 10M jsonu např.).
Poptával jsem, jestli někdo nezná nějaké out of box řešení pro node.js/js obecně. Souhlasím, že náklady na provoz node.js v produkci jsou dost vysoké kvůli neexistujícímu ekosystému.
-
. . (neregistrovaný)
source mapy jsou primárně pro prohlížeče a primárně pro případ, kdy kód generuješ/kompiluješ. To se zpravidla u servových aplikací nedělá, není totiž potřeba mít vše v jednom souboru a klidně na disku to mohu mít celé rozložené.
Sourcemapy ale moc ničemu nepomůžou, nezlepší mě čitelnost futures konstrukcí z call stacku atd.
-
. . (neregistrovaný)
většina? V jakkých projektech/společnostech pracuješ? Máš nějaký podklady nebo jen posuzuješ podle sebe protože děláš v reactu, coffeescriptu a používáš babel?
Source mapa každopádně není řešením toho co jsem psal, pořád je problém s callstackem u řady async/await frameworků, kde mi nic neřekne :)
-
mmm (neregistrovaný)
čemu říkáš async/await framework? Zrovna kód obsahující async/await musel být ještě nedávno vždy překládán babelem. Node.js a většna prohlížečů stále nepodporuje pokročlejší featury jako async iterátory. Většina npm modulů používá minimálně babel nebo je rovnou napsaná v typescriptu nebo jiném jazyku.
tohle nebude fungovat bez překladu babelem nikde
https://jakearchibald.com/2017/async-iterators-and-generators/
vygenerovaný kód je asi 20x delší a vyznat se v chybovém výpisu bez source map je těžké.
-
. . (neregistrovaný)
chybové výpisy ať si řeší vývojář a ten ať si používá co chce :), já se ptal původně na provoz ze strany administrátora. Async.js třeba žádný generátor nepotřebuje, async/await je v node.js od 7.
Opět tady házíš vycucané argumenty z prstu, píšeš, že většina npm modulů používá babel, podle libraries.io to jsou jednotky procent podle verze, https://libraries.io/npm/babel-core/usage?page=2&requirements=%5E6.1.21
-
mmm (neregistrovaný)
async.js je sračka, která se používala před příchodem promisů. async/await už je podporované všude, ale ještě nedávno tomu tak nebylo a já psal o async iterátorech. Ty jsou až v nodejs 8 a musí se explicitně zapnout. Když chcete fungovat i na starším node a v prohlížeči, musíte použít babel.
-
MarSik (neregistrovaný)
A všechno to co jste popsal se u produkční aplikace typicky nedělá. Snižuje to výkon, rozhodí to časování (co asi udělají timeouty, když zastavíte vlákno v debuggeru?) a je to nebezpečné z hlediska stability.
Povídat si jinak můžu s jakýmkoliv procesem, mám gdb (nebo dokonce gdbserver). A to nemluvím třeba o JVM, kde je vzdálené sledování stavu ještě o krok dál (JMX například).
-
koroptev (neregistrovaný)
ty timeouty nevim, ocekaval bych, ze se zastavi i task queue
gdb bez ladicich informaci (tozn typicky ostry release) ukaze co? disassemblovane instrukce? to se opravdu neda srovnat s povidanim kde k hovoru pouzivam slova popisujici abstrakce jazyka ve kterem jsem vec vyrobil..
-
MarSik (neregistrovaný)
Jak zastavíte expiraci TCP spojení na firewallu? Nebo nějakou úplně jinou aplikaci, která čeká na odpověď? Dnešní distribuované systémy jsou o dost složitější..
Ladicí informace nemusí být součástí běžícího procesu. GDB je umí nahrát i z jiných zdrojů (třeba debuginfo balíčků).
Jak se třeba v Pythonu nebo Ruby připojíte k běžícímu procesu? Jde o to, že zevšeobecnit to na "dynamické jazyky se dobře ladí" je přílišné zjednodušení. Protože třeba Erlang je kompilovaný a umí to, Java je kompilovaná a umí to. Python a Ruby jsou dynamické, skriptovací a přesto to neumí.
