Sziasztok!
Fejlesztőink haladnak a korral, és fő websitunkat Next.JS alapokra helyezték. Server side rendering-el, amit lehet cachelve.
Sajnos erős lassulások, tapasztalhatóak magas load időnként.
Nyilván a fejlesztés a HW bővítés irányába mutat ami indokolt lehet, de szeretnék megerősítést kapni. Viszont a next nem túl elterjedt, így releváns infókat a HW igényekről nem találtam. Talán itt! :D
Jelenleg a VPS szeletünk: 10 mag (Xeon Gold), 25G memóriával, SSD alapokon.
Simán lehet hogy overbooking miatt csak látszólag van "nagy" mozgásterünk.
Szóval a kérdésem, van köztetek olyan aki szolgáltat Next-el? Ha igen, milyen HW van alatta, milyen terhelések stb
Köszönöm szépen aki segít!
UPDATE 2024.05.09:
Először is köszönöm szépen a rengeteg építő jellegű tanácsot! Nem gondoltam volna, hogy ekkora topic születik ebből a témából :)
A dev szerveren már működik az nginx load balancer, jelenleg a header optimalizásában vagyok elmélyülve.
NodeJS több szálasítás is működik.
Megkértem a fejlesztőt, hogy profilozza az app-ot, bízok benne hogy egyértelmű javulást láthatunk majd a rendszer bevezetése után.
Ha a dev-en minden OK, megy a prod szerverre és kiderül hogy bírja a terhelést.
De az sem baj, ha nem bírja, így nagyon könnyen vonható be plussz feldolgozó a load balancernek köszönhetően.
Szóval ismét köszönöm, majd közlök eredményeket :)
Hozzászólások
Node.js alatt megy? Ha nézed a szerver terhelését, használja a node.js az összes processzort?
Node.js alapból egyetlen szálon megy, ha többet is akarsz, több példányban is el kell indítani, elé pedig kell egy terheléselosztó.
JS backend fantasztikus "előnye", hogy egyetlen szálon megy és ha ex-PHP kóderek dolgoznak, nagy esély van rá, hogy nem aszinkron, eseményvezérelt kódot írnak, így nagy lassulások lesznek, ha kieresztitek a felhasználók felé.
Azért írtam, hogy ez "előny", mert automatikusan skálázódó felhős infrastruktúrák szolgáltatói hatalmas pénzeket keresnek ezen.
Szervusz!
Köszi szépen, hogy segítesz!
Tényleg 1 szálon megy :/
Megpróbálom cluster módban elindítatni, meglátjuk mit kezd vele.
Vicces tény, hogy az oldalak elő-cachelését kikapcsolva reszponzívabb lett az oldal és csökkent a terhelés.
Nagyjából 4.000 ilyen oldal van.
Ezek szerint a háttérben fut ez a folyamat, míg próbálja a kéréseket is lekezelni?
Nem tudom, hogy írták meg az alkalmazást, de ha tud olyat, hogy a generált oldalakhoz beállítja a HTTP header-ben, hogy mennyi ideig érvényesek, akkor célszerű az előtte levő reverse proxyban (ha van előtte pl. nginx) beállítani a cache-elést. Sokkal gyorsabb lesz.
Ez nagyobb falatnak tűnik. Utána olvasok. Köszönöm szépen neked!
Így van, ez a helyes irány.
Még akkor is ha azt mondod hogy van olyan oldalad amit "szuper aktuálisan" akarsz tartani (de nem user specifikus) akkor arra is mondhatod hogy legyen cachelve 1-10 másodpercig. Amíg cachelve van addig kiszolgál sokezer kérést másodpercenként az nginx. Közben a háttérben nyugodtan legyárthatod az újat.
Gábriel Ákos
Igen, és ha egyébként user specifikus, de csak annyiban, hogy 1-2 dolog függ a belépett usertől (pl. kosár ikon egy számmal, vagy a belépett felhasználó adatai), azt generálhatja egy apró Javascript kliens oldalon.
"Hydration"-nek szokták hívni ezt a működési módot.
Pár gondolat amin érdemes végig menni:
Nem kell mindent server side render-elni, mert erősen CPU intenzív folyamat.
Elegendő lehet a SEO-ra optimalizált dolgokra megcsinálni, de a private area-ra (user setting panel, password change, etc.) kikell kapcsolni. Ezeket elegendő a kliensen kiszámolni.
Ami statikus tartalom arra bekell beállítani, hogy build időben generálja le azokat.
Ha vannak teljesen cache-elhető page-ek akkor azt érdemes az alkalmazáson kívül cache-elni valami CDN-en. Nyílván a megfelelő routing path egy kritérium ehhez.
Cluster módban futtasd az alkalmazást, hogy minden magot kitudjon használni az alkalmazás.
Érdemes egy reverse proxy-t tenni az alkalmazás elé és NodeJS helyett inkább rábízni a static fájlok kiszolgálását. Pl.: nginx elég jó ebben és a NodeJS pedig csinálja csak az SSR-t.
SZervusz!
Köszönöm, hogy segítesz! :)
Nem kell mindent server side render-elni, mert erősen CPU intenzív folyamat.
Elegendő lehet a SEO-ra optimalizált dolgokra megcsinálni, de a private area-ra (user setting panel, password change, etc.) kikell kapcsolni. Ezeket elegendő a kliensen kiszámolni.
Egyeztettem a fejlesztővel igen, ezek már így működnek.
Ami statikus tartalom arra bekell beállítani, hogy build időben generálja le azokat.
Sajnos közel 0 statikus oldalunk van. Minden dinamikusan generálódik.
Ha vannak teljesen cache-elhető page-ek akkor azt érdemes az alkalmazáson kívül cache-elni valami CDN-en. Nyílván a megfelelő routing path egy kritérium ehhez.
Igen, ezek így működnek jelenleg is.
Cluster módban futtasd az alkalmazást, hogy minden magot kitudjon használni az alkalmazás.
Ez az ami eddig nem így volt. Ma este kiderül, nagyon-nagyon bízunk a sikerben.
Érdemes egy reverse proxy-t tenni az alkalmazás elé és NodeJS helyett inkább rábízni a static fájlok kiszolgálását. Pl.: nginx elég jó ebben és a NodeJS pedig csinálja csak az SSR-t.
Sajnos nem nagyon vannak statikus dolgaink.
Köszönöm mégegyszer!
"Köszönöm, hogy segítesz! :)"
Nincs mit, szívesen. Remélem sikerül megoldani a problémát. :)
A fentiek alapján azt gondolom, hogy eléggé rendben vagytok.
Amit az SSR-ről érdemes tudni, hogy nagyon CPU igényes.
Egy kisebb e-commerce site render-je a az általad említett hardware-en cache-ek nélkül szerintem nem több 8-13 RPS-nél.
A megfelelő cache-elés ezen drámaian tud javítani de hamar eljön az idő amikor kell még vasat venni.
"Érdemes egy reverse proxy-t tenni az alkalmazás elé és NodeJS helyett inkább rábízni a static fájlok kiszolgálását. Pl.: nginx elég jó ebben és a NodeJS pedig csinálja csak az SSR-t.
Sajnos nem nagyon vannak statikus dolgaink. "
Itt lehet nem voltam elég egyértelmű.
A build mappában általában van egy static könyvtár amit a kliensnek szán a framework.
Ebben vannak a kigenerált Media/CSS/JS fájlok amit a böngészőnek kell letöltenie a szerverről és végrehajtani.
Általában a /_next/static-ra kell feloldani. Ezt a feladatot ellehet venni a Node-tól és oda adni az nginx-nek jó cache beállításokkal.
Az nginx sokkal jobb ebben, mint a Node. Illetve a NextJS jól állítja be a cache-t, akár átlehet venni a beállításait.
Úgy látom van CDN-etek, így az nem feltétlen probléma ha még is a Node szolgálja ki.
Érdemes lehet egy pillantást vetni az access log-okra, hogy tényleg jól cache-elődik-e a CDN-en.
Ezt lehet jó hosszú időre cache-elni, mert csak deployment-enként szabadna változniuk és a fájlnevek a tartalom alapján generált hash-ek. Ha változik a tartalom akkor változik a fájlnév is.
... és amikor a háttérben még adatbázis lekérdezéseket is csinál, na akkor kezdődik az igazi rémálom.
Párhuzamosan futó full-table-scan-ek, egymást lockoló update query-k.
Egyik se derül ki soha a babzsákfejlesztő ssd-s laptopján.
Gábriel Ákos
Mármint HTTP reqeuest / sec? Mi a franc van ennek a belsejében, abakusz?
Egész biztos vagyok abban, hogy nagyon sok statikus dolgotok van amit simán ki lehet szolgálni egy revproxy-ból, egyáltalán nem kell hogy a nodejs foglalkozzon vele.
Gábriel Ákos
Még egy tipikus hiba: amikor valami apró szarság változik egy oldalon belül de a "babzsákfejlesztő" biztos ami tuti legeneráltatja az egész oldalt.
Hiszen nála így is "azonnal megjelenik".
Gábriel Ákos
Profiloztátok már az alkalmazást, hogy mi miatt van magas erőforrásigény? Melyik requestek kiszolgálásánál stb.
Szerver profilozás már történt, NodeJS befűzése Zabbix alá folyamatban van.
Szerintem a teljesítmény profilozásra gondolt profilerrel. Amit a programozók szoktak csinálni, már amikor rákényszerülnek: profilerrel megmérik, hogy a programnak melyik részei mennyi %-ban dolgoznak és a nagyfogyasztókat keresve megtalálják a program szűk keresztmetszeteit. A jó hír az, hogy a legtöbb alkalmazásban ha még sosem volt profilozva (és babzsákfejlesztők csinálták), akkor van benne néhány könnyen javítható szűk keresztmetszet, amit megjavítva 5x lesz a teljesítmény (a 80-20-as szabály szerint). Ezt kell megcsinálni: profilozni az alkalmazást és kijavítani a szűk keresztmetszeteket. Persze ez a programozó dolga. Ha még eddig nem menekült el a programozó, akkor van esély :-)
Ha már a szűk keresztmetszetek ki lettek irtva, akkor vagy elég gyors lesz a program, vagy jön a fejvakarás, onnantól sokkal nehezebb. Akkor szoktak jönni az ötletek, hogy íjruk újra valami másban, ami gyorsabban tud futni. De ez így azonnal az újraírás után nem jönne ki jól a menedzsment előtt.
"Ha még eddig nem menekült el a programozó, akkor van esély :-)"
Lehet ha megemlíteném az itt többször is elhangzott "babzsákfejlesztő" jelzőt már nem segítene oly lelkesen. :D
Kihívásnak kell felfogni. Illetve a körülményekből sejthető, hogy a fejlesztőnek nincs tapasztalata a kérdésben, mert ha lenne akkor nem minket kérdeznél. Tehát végső soron jogos a kritika, még ha az internet névtelensége miatt túlzottan érdesen is van megfogalmazva. Növesszen vastag arcbőrt és tanuljon! Az élesbe állás a projekt legérdekesebb része, ne itt adja fel! Ameddig a főnök hajlandó finanszírozni addig érdemes csinálni, mert ha sikerül a kudarcot sikerbe fordítani az minden szempontból értékes tapasztalat lesz számára.
Egyébként meg gabrielakos-ra érdemes ebben a topikban hallgatni szerintem, mert neki konkrét tapasztalata is van. Én viszont nem webes területen vagyok főleg, pont a tömeges kiszolgálásban nincsen tapasztalatom, csak az elméletet tudom. Amit én mondtam az igaz ugyan, de a cache-elés után maximum második legfontosabb dolog lehet. Ha sikerül a lekérések jó részét cache-elni, akkor nagyságrendileg fog nőni a kiszolgálható kérések száma.
Tehát a rövid válasz az hogy nem.
Gábriel Ákos
websitunkat -> website-unkat
rendering-el -> renderinggel
cachelve -> cache-elve
A temanyito helyett is, köszönöm a segítséged!
Ezzel a hozzászólásoddal frankón előremozdítottad a topikot a megoldás megtalálásában!
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
nyelvtan-naci-skodas
skoda?
Hogy a banatba ne!
Talan az elektromodulator dva-ba ultunk be cseh moziban, es ott volt egy mondat/sohaj az angol beszedben, amit magyarul ugy lehetne mondani, hogy "kár". Noh, ott a cseh felirat annyi volt, hogy: skoda.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Igazad van, köszönöm!
Next-el -> Nexttel
Szia!
Microservice architektúrát használtok vagy egy nagy app az egész?
Ha microservice architektúrát használtok, akkor VM esetében pm2-vel lehet érdemes futtatni, természetesen cluster módban. Ha gondoljátok át lehet tenni az egészet Kubernetesre, ami miatt elosztottabb lesz a rendszer és könnyebben skálázható.
A fejlesztő nézze meg, hogy lehet-e aszinkron futást belevinni, ahogy fentebb is írták.
Azt fontos tudni, hogy az "Akármilyen".JS-re való váltás nem mindig hoz teljesítmény növekedést. Illetve nem minden alkalmazás darabolható fel értelmesen microservice-ekre. Sok helyen inkább divat, de a végén kiderül, hogy drágább, mint a régi rendszer. Egy jó PoC meg tudja mutatni, hogy mit érdemes Javascriptbe és mit nem migrálni.
Az erőforrás felhasználást ki kell mérni az egyes app-oknál és az után adni neki limitet. Ha a limit túl magas, akkor nem jut másik microservice több erőforráshoz, pedig kéne neki. Ha túl alacsony, akkor belassul a microservice. A PM2-re lehet telepíteni a pm2-metrics csomagot, amivel lehet exportálni a CPU és memória használatot (per App) Prometheus-ba. Prometheus és Grafana párossal remekül lehet nézni az adatokat. A méreshez javasolt egy teszt, amivel ki lehet hajtani a rendszert és utána van esély a jó CPU és memória limit hasznalatára.
Azt nézzétek meg, hogy van-e barmilyen vírusvédelem a rendszeren, mert a JS sok kicsi fájllal dolgozik és a kettő együtt is meg tudja pörgetni a gépet.
Sajnos Zabbix-szal való összedrótozással nincs tapasztalatom. Találtam megoldást, de évek óta nem fejlesztik, így a linket nem tenném ide.
Ha már megvannak az alapok és megy az egész, akkor lehet gondolkodni, hogy lesz az egész stateless, csomagolás Docker image-be és mehet Kubernetesre. Ha van egy futó környezet, akkor jöhet hozzá egy kis GitOps szemlélet, egy FluxCD vagy ArgoCD a deployment automatizáláshoz, de ne szaladjunk ennyire előre...
Kubernetes az kell oda mindenképpen. Esetleg még egy kafkát bele lehetne varázsolni?
Gábriel Ákos
inkabb irjak ujra az egeszet Rust-ban. de szigoruan babcsak fotelekben!
Kimaradt a tm! Sajnos így nem hiteles...
Nem kell oda mindenképpen. Ahogy írtam egy lehetőség. De látom sikerült megfogni a lényeget...
_egy_ darab nextjs site-ról van szó. Hol látsz te itt microservice-t?
Gábriel Ákos
Poe törvénye akcióban: csak sejtem, hogy irónia, de nem vagyok benne egészen biztos ;-)
Lehet, hogy nem bloat keretrendszerben kellett volna összekényelmeskedni az újrafeltalált kereket a babzsákfejlesztőidnek?
kormod nem tort be cicafiju, hogy nyiss egy topicot a hajtuidet dobalni? :D
Ó mitugrászkám, hát milyen gyorsan ideett a fene. :D
mpomdja a kis picsogo faszkalap akinek senki sem kerdezte a velemenyet. Szakmai tanacsot kertek - ami nem csoadlok hogy te nem tudtal megadni, mert a picsogason es onmagad felszopasan kivul nem sok mindenhez ertesz. :D
ne hogy megsertodj kiscica :D
Mintha téged kérdeztek volna kismajom.
"Szóval a kérdésem, van köztetek olyan aki szolgáltat Next-el? Ha igen, milyen HW van alatta, milyen terhelések stb " vs. "Lehet, hogy nem bloat keretrendszerben kellett volna összekényelmeskedni az újrafeltalált kereket a babzsákfejlesztőidnek?"
es ez mindent el is mond kiscsiko rolad :D
amugy nem is neki valaszoltam, hiszen en nem kepzelem magam egy mindnhato kis kocsognek mint amilyen te vagy, hanem neked te kis picsogo pöcök :D
Ez OP korral™ haladó™ fejlesztőiről mond el mindent.
Ami választ én adtam OP-nak az tartalmaz egy lehetséges okot arra, miért lassú a bloat keretrendszerben írt bloatware. Én viszont téged nem kérdeztelek, kedves mitugrász kismajom fórumtársam. Ettől függetlenül ideokádhadtad a mitugrászkodásod, szóval addig örülj, amíg szabad véleménynyilvánítás van.
jajj de sok a szoismetles...megint fel kell utnod a szinonima szotaradat, mert almaositoan uncsi vagy :D ...nosza talalj ki valamit a mitugrasz helyett - ok tudom hogy nem vagy valami nagy koponya, de megis...igy olyan veled a csorta mintha egy disznot neznek a sajat mocskaban fetrengeni a retorika mocsaraban, es valjuk be, ki akarna odaig leereszkedni :D
Minek, ha tökéletesen jellemez téged, kismajom?
Sajnálom, hogy ilyen beteg fantáziád van.
Jobb kérdés az, hogy ki akarna hozzád. Én köszönöm, de nem.
Nem a bloat keretrendszerrel van a baj hanem a hozzá-nem-értéssel.
Gábriel Ákos
A bloat keretrendszerrel is baj van, de az igaz, hogy a benne való kényelmeskedés a hozzánemértésből következik.
Turbo Pascal 4 Backend!
Amilyen backend kódokat már láttam, nem lenne sokkal rosszabb Turbo Pascalban :D
Nem kell Turbo Pascal. Egy normálisan megírt PHP7 vagy PHP8 kód is valószínűleg szarráverné a NextJS-es bloatware-t.
Ha ráteszed a megfelelő headereket, beállítod a cache validity-t, eléteszel egy nginx-et vagy még jobb egy CDN akkor a munka 95%-t már elvégezted.
Tök mindegy hogy milyen backend van mögötte.
Azt kell látni hogy ez nagyrészt operations feladat, nem developer.
Ha a developer szarul implementál és emiatt nem lehet cachelni akkor megint tudjuk hogy mit kell csinálni és kinek.
Óriási hibája ezeknek a frameworköknek hogy azt a látszatot keltik hogy ami ebből kijön az production ready.
Pedig nem az.
Semmi amit eddig ebben a témában elmondtam nem új, 15 éve is pont így volt.
Gábriel Ákos
Ha az alap optimalizáció meg van és még profilozni kell az alkalmazást akkor prod-ra nálam bevált a New Relic.
Gyarkorlatilag 1 dev júzerrel szinte ingyen van.
Hátránya, hogy egy kicsit pilóta vizsgás a UI-ja.