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?
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.
[...] 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.
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í.
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.
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.
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 :)
č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é.
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
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.
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).
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..
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í.