Cum se remediază pierderea memoriei ws și socket.io?

Am citit că există o scurgere de memorie în ambele module node.js websocket ws și socket.io. Există de ani de zile și mă întreb cum să o repar.

Este menționat în cele ce urmează, pentru a numi câteva:

• https://github.com/socketio/socket.io/issues/2427 (inchis dar fara solutie)
• https://github.com/socketio/socket.io/issues/3477 (setarea perMessageDeflate: false aparent ajută, dar cauza principală este o problemă cu fragmentarea, care aparent nu este cauzată de bibliotecile websocket sau de nod, ci de modul în care sunt rulate și pot fi rezolvate prin preîncărcarea jemalloc)
• https://github.com/nodejs/node/issues/8871#issuecomment-250915913 (aceeași soluție oferită aici)
• https://github.com/websockets/ws/issues/804 (se pare că problema este rezolvată doar setând perMessageDeflate la false - fără jemalloc)

Având în vedere că acum este 2021, setarea cheii perMessageDeflate la fals și, probabil, preîncărcarea jemalloc este încă cea mai bună soluție?

Înțelegerea mea rudimentară a acestei probleme este următoarea (nu mă cita pe mine despre ea):

• modulul ws node.js (adică modulul websockets) și modulul socket.io node.js folosesc ambele un alt modul numit zlib.Acest modul este responsabil pentru comprimarea oricăror mesaje atunci când sunt trimise prin websocket.
• modulul zlib a avut în trecut o problemă legată de fragmentarea memoriei, care imită o scurgere de memorie (adică nu este de fapt o scurgere de memorie, ci fragmentarea memoriei).
• compresia mesajelor este dezactivată implicit pe server, dar activată implicit pe client (de exemplu, browser). Dacă îl dezactivăm, modulul zlib nu este folosit, ceea ce va elimina problema fragmentării memoriei.
• Pentru a dezactiva compresia pe client (de exemplu, browser), dăm perMessageDeflate introduceți valoarea codului serverului fals. Acesta este:

const wss = new WebSocket.Server({ server:httpsServer, perMessageDeflate: false });

Evident, aceasta nu este o soluție pentru persoanele care doresc să-și comprima mesajele. Dar merită menționat că:

• problema fragmentării memoriei cu zlib a fost aparent rezolvată PARȚIAL cu https://github.com/websockets/ws/pull/1204 dar pare să fie încă o problemă; și
• beneficiul comprimării mesajelor mici, cum ar fi bucăți mici de text, a fost dezbătut. Unii afirmă chiar că comprimarea mesajelor mici va încetini lucrurile. Dacă lucrați cu date mai mari, cum ar fi imagini sau videoclipuri, puteți obține succes comprimându-le singur (adică fără ws/socket.io/zlib) înainte de a le trimite printr-un websocket.

De asemenea, unii au remarcat că setarea perMessageDeflate: false reduce doar problema, dar nu rezolvă în totalitate problema. Ți-aș îndrepta atenția asupra acestei discuții, unde se spune că UNELE utilizarea reziduală și constantă (adică nu în creștere) a memoriei de la deschiderea și închiderea websocket-urilor este normală (apropo, nu spun neapărat că acest lucru este corect): https://github.com/websockets/ws/issues/804#issuecomment-302612661

În ceea ce privește preîncărcarea Jemalloc, nu se pare că aceasta rezolvă problema. Deși, dacă codul de mai sus nu funcționează, cu siguranță merită să te uiți (sau să încerci).

Așa este preMessageDeflate: fals cea mai buna solutie acum? Din intelesul meu as spune ca da.

Dacă cineva are corecții sau mai multe informații despre asta, vă rugăm să adăugați.