Meteor 3.5 inawawezesha watengenezaji kuacha SockJS na kutumia uWebSockets.js kwa kutumia variable moja ya mazingira (environment variable), ikiahidi kupunguza kwa kiasi kikubwa gharama za CPU, RAM na garbage-collection kwa programu zinazotegemea sana mwito wa njia (method calls).

Kwa nini mabadiliko haya ni muhimu

Tangu kuzinduliwa kwake, Meteor imekuwa ikipitisha kila ujumbe wa DDP (Distributed Data Protocol) kupitia SockJS, ambayo ni njia mbadala ya JavaScript inayofanya kazi kila mahali lakini haikuundwa kwa ajili ya kasi ya juu. Toleo jipya linatenganisha tabaka la usafirishaji (transport layer), likitoa sehemu ya kuunganisha (plug-in point) inayokubali utekelezaji wowote wa WebSocket unaoendana na matarajio ya DDP. Kuweka DDP_TRANSPORT=uws wakati wa kuzindua kubadilisha chaguo la kawaida na uWebSockets.js, seva inayotegemea C/C++ inayojulikana kwa uwezo mkubwa wa usafirishaji (high throughput).

Upande wa utendaji

Vipimo vya utendaji (benchmarks) vilivyotolewa pamoja na toleo hili vinaonyesha:

  • Matumizi ya CPU yamepungua kwa 9 %
  • Matumizi ya RAM yamepungua kwa 11 %
  • Muda wa kusimama wa garbage-collection umepunguzwa kwa 26 %
  • Uwezo wa usafirishaji (throughput) umeongezeka mara 1.6 katika micro-benchmarks

Mafanikio haya huonekana wakati programu inafanya mwito mwingi wa njia za aina ya RPC. Usafirishaji wenyewe unakuwa kikwazo (bottleneck) tu baada ya mantiki ya biashara ya programu kuimarishwa (optimised), hivyo mabadiliko haya yanaweza kuleta matokeo ya moja kwa moja katika kupunguza gharama za seva.

Jinsi ya kuijaribu leo

Hakuna binary tofauti inayohitajika—Meteor 3.5 pekee. Endesha programu kwa:

DDP_TRANSPORT=uws meteor run

Seva ya uWebSockets.js inasikiliza kwenye port yake yenyewe (chaguo la kawaida ni 5001). Wakati mifumo (instances) mingi ya Meteor inapotumia host moja, kila moja lazima ipangiwe uws.port tofauti kupitia METEOR_SETTINGS ili kuepuka migongano.

Nani anafaidika, na nani anaweza asione mabadiliko makubwa

  • Kazi zinazotumia sana RPC – huduma zinazopiga mwito wa njia nyingi kwa kila ombi zitapata nafasi ya kuokoa mizunguko ya CPU na kumbukumbu, hivyo kupunguza shinikizo la kutanua mfumo (scaling).
  • Programu zinazozingatia Pub/Sub – sehemu kubwa ya ucheleweshaji (latency) katika mifumo ya publish/subscribe inatokana na hesabu za data-diff, na si usafirishaji, hivyo ongezeko la kasi ni dogo.

Mabadiliko haya ni ya hiari (opt-in); SockJS inabaki kuwa chaguo la kawaida, ikihifadhi uwezo wa kufanya kazi katika mazingira ambapo WebSockets za asili hazipatikani.

Changamoto na tahadhari

Kubadilisha usafirishaji kunaongeza hatua ndogo ya kiutendaji: kusimamia port ya ziada na kuhakikisha haigongani na huduma nyingine. Kwa sababu uWebSockets.js ni moduli ya asili (native module), inaleta mambo ya kawaida ya utegemezi wa binary—zana za ujenzi (build tools) lazima ziwepo kwenye host ya kuweka programu (deployment host), na updates zozote za baadaye za maktaba hiyo zitahitaji kufanyiwa majaribio dhidi ya kodi ya programu (codebase).

Nini kinafuata kwa tabaka la usafirishaji la Meteor

Kwa kuweka mpaka ulio wazi, Meteor sasa inakaribisha jamii kufanya majaribio na usafirishaji mbadala—iwe kwa mahitaji maalum ya usalama, upanuzi wa itifaki (protocol extensions) maalum, au uboreshaji zaidi wa utendaji. Kuona jinsi utekelezaji wa wahusika wa tatu (third-party implementations) utakavyotokea haraka kutakuonyesha ikiwa mfumo huu wa kuunganisha (pluggable model) utakuwa sehemu ya kudumu ya usanifu wa Meteor.

Muhtasari: Usafirishaji wa DDP wa Meteor 3.5 unaoweza kubadilishwa unakuwezesha kubadilisha mfumo wa zamani wa SockJS na uWebSockets.js kwa amri moja, ukitoa uwezo wa usafirishaji (throughput) wa hadi mara 1.6 zaidi na uokoaji wa rasilimali unaopimika kwa programu zinazotumia sana RPC, huku ukiacha mipangilio iliyopo bila kuguswa kwa kazi ambazo hazihitaji kasi hiyo.