Meteor 3.5 ഉപയോഗിച്ച് ഡെവലപ്പർമാർക്ക് ഒരു സിംഗിൾ എൻവയോൺമെന്റ് വേരിയബിൾ വഴി SockJS ഒഴിവാക്കി uWebSockets.js ഉപയോഗിക്കാൻ സാധിക്കും. മെത്തേഡ് കോളുകളെ (method calls) വളരെയധികം ആശ്രയിക്കുന്ന ആപ്പുകൾക്ക് CPU, RAM, ഗാർബേജ് കളക്ഷൻ (garbage-collection) എന്നിവയുടെ ചിലവ് ഗണ്യമായി കുറയ്ക്കാൻ ഇത് സഹായിക്കും.
എന്തുകൊണ്ടാണ് ഈ മാറ്റം പ്രധാനമാകുന്നത്
ലോഞ്ച് ചെയ്ത കാലം മുതൽ, Meteor ഓരോ DDP (Distributed Data Protocol) സന്ദേശവും SockJS വഴിയാണ് കൈമാറിയിരുന്നത്. എല്ലാ ഇടങ്ങളിലും പ്രവർത്തിക്കുന്ന ഒരു JavaScript ഫോളബാക്ക് (fallback) ആണെങ്കിലും, ഉയർന്ന വേഗതയ്ക്കായി രൂപകൽപ്പന ചെയ്തതല്ല ഇത്. പുതിയ റിലീസ് ട്രാൻസ്പോർട്ട് ലെയറിനെ (transport layer) വേർതിരിക്കുകയും, DDP-യുടെ നിബന്ധനകൾ പാലിക്കുന്ന ഏത് WebSocket ഇംപ്ലിമെന്റേഷനും സ്വീകരിക്കുന്ന ഒരു പ്ലഗ്-ഇൻ പോയിന്റ് നൽകുകയും ചെയ്യുന്നു. ലോഞ്ച് സമയത്ത് DDP_TRANSPORT=uws എന്ന് സെറ്റ് ചെയ്യുന്നതിലൂടെ, ഡിഫോൾട്ട് സംവിധാനത്തിന് പകരം ഉയർന്ന ത്രൂപുട്ട് (throughput) നൽകുന്ന C/C++ അധിഷ്ഠിത സെർവറായ uWebSockets.js ഉപയോഗിക്കാൻ സാധിക്കും.
പെർഫോമൻസ് വശങ്ങൾ
റിലീസിനൊപ്പം നൽകിയിട്ടുള്ള ബെഞ്ച്മാർക്കുകൾ സൂചിപ്പിക്കുന്നത്:
- CPU ഉപയോഗം 9% കുറഞ്ഞു
- RAM ഉപയോഗം 11% കുറഞ്ഞു
- Garbage-collection പോസ് സമയം 26% കുറഞ്ഞു
- മൈക്രോ ബെഞ്ച്മാർക്കുകളിൽ ത്രൂപുട്ട് 1.6 മടങ്ങ് വർദ്ധിച്ചു
ഒരു ആപ്ലിക്കേഷൻ ധാരാളം RPC-സ്റ്റൈൽ മെത്തേഡ് കോളുകൾ നടത്തുമ്പോഴാണ് ഈ നേട്ടങ്ങൾ പ്രകടമാകുന്നത്. ആപ്ലിക്കേഷന്റെ ബിസിനസ് ലോജിക് ഒപ്റ്റിമൈസ് ചെയ്തതിന് ശേഷം മാത്രമേ ട്രാൻസ്പോർട്ട് ഒരു തടസ്സമായി (bottleneck) മാറുന്നുള്ളൂ, അതിനാൽ ഈ മാറ്റം സെർവർ ചിലവ് നേരിട്ട് കുറയ്ക്കാൻ സഹായിക്കും.
ഇത് ഇന്ന് എങ്ങനെ പരീക്ഷിക്കാം
പ്രത്യേക ബൈനറി ആവശ്യമില്ല—Meteor 3.5 മാത്രം മതി. ആപ്പ് ഇപ്രകാരം റൺ ചെയ്യുക:
DDP_TRANSPORT=uws meteor run
uWebSockets.js സെർവർ അതിന്റെ സ്വന്തം പോർട്ടിലാണ് (ഡിഫോൾട്ട് 5001) പ്രവർത്തിക്കുന്നത്. ഒന്നിലധികം Meteor ഇൻസ്റ്റൻസുകൾ ഒരേ ഹോസ്റ്റിൽ പ്രവർത്തിക്കുമ്പോൾ, പോർട്ട് സംഘർഷങ്ങൾ (collisions) ഒഴിവാക്കാൻ METEOR_SETTINGS വഴി ഓരോന്നിനും വ്യത്യസ്തമായ uws.port നൽകേണ്ടതുണ്ട്.
ആർക്കൊക്കെ ഗുണമുണ്ടാകും, ആർക്കൊക്കെ വലിയ മാറ്റം അനുഭവപ്പെടില്ല
- RPC-ഭരിതമായ വർക്ക്ലോഡുകൾ (RPC-heavy workloads) – ഓരോ റിക്വസ്റ്റിലും ധാരാളം മെത്തേഡുകൾ വിളിക്കുന്ന സർവീസുകൾക്ക് CPU സൈക്കിളുകളും മെമ്മറിയും ലാഭിക്കാൻ സാധിക്കും, ഇത് സ്കെയിലിംഗ് സമ്മർദ്ദം കുറയ്ക്കുന്നു.
- Pub/Sub-കേന്ദ്രീകൃത ആപ്പുകൾ (Pub/Sub-centric apps) – പബ്ലിഷ്/സബ്സ്ക്രൈബ് പാറ്റേണുകളിലെ മിക്ക ലേറ്റൻസിയും (latency) ഡാറ്റാ-ഡിഫ് (data-diff) കണക്കുകൂട്ടലുകളിൽ നിന്നാണ് വരുന്നത്, ട്രാൻസ്പോർട്ടിൽ നിന്നല്ല, അതിനാൽ വേഗതയിലുള്ള വർദ്ധനവ് നേരിയതായിരിക്കും.
ഈ മാറ്റം ഓപ്ഷണൽ ആണ്; നേറ്റീവ് WebSockets ലഭ്യമല്ലാത്ത സാഹചര്യങ്ങളിൽ ഉപയോഗിക്കുന്നതിനായി SockJS തന്നെ ഡിഫോൾട്ടായി തുടരുന്നു.
ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങളും വെല്ലുവിളികളും
ട്രാൻസ്പോർട്ട് മാറ്റുന്നത് ചെറിയൊരു പ്രവർത്തനപരമായ ഘട്ടം കൂടി കൂട്ടിച്ചേർക്കുന്നു: ഒരു അധിക പോർട്ട് കൈകാര്യം ചെയ്യേണ്ടി വരും, അത് മറ്റ് സർവീസുകളുമായി കൂട്ടിമുട്ടുന്നില്ലെന്ന് ഉറപ്പാക്കേണ്ടതുണ്ട്. uWebSockets.js ഒരു നേറ്റീവ് മോഡ്യൂൾ ആയതുകൊണ്ട്, ബൈനറി ഡിപെൻഡൻസികളുമായി (binary dependencies) ബന്ധപ്പെട്ട സാധാരണ കാര്യങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്—ഡെപ്ലോയ്മെന്റ് ഹോസ്റ്റിൽ ബിൽഡ് ടൂളുകൾ ഉണ്ടായിരിക്കണം, കൂടാതെ ലൈബ്രറിയിലുണ്ടാകുന്ന ഭാവിയിലെ അപ്ഡേറ്റുകൾ ആപ്പിന്റെ കോഡ്ബേസുമായി പരീക്ഷിച്ചു നോക്കേണ്ടതുമാണ്.
Meteor-ന്റെ ട്രാൻസ്പോർട്ട് ലെയറിനെ സംബന്ധിച്ച് ഇനി എന്താണ് വരാനിരിക്കുന്നത്
ഒരു വ്യക്തമായ അതിർവരമ്പ് നൽകുന്നതിലൂടെ, പ്രത്യേക സുരക്ഷാ ആവശ്യങ്ങൾക്കോ, കസ്റ്റം പ്രോട്ടോക്കോൾ എക്സ്റ്റൻഷനുകൾക്കോ, അല്ലെങ്കിൽ കൂടുതൽ പെർഫോമൻസ് ട്യൂണിംഗിനോ വേണ്ടി മറ്റ് ട്രാൻസ്പോർട്ടുകൾ പരീക്ഷിക്കാൻ Meteor ഇപ്പോൾ കമ്മ്യൂണിറ്റിയെ ക്ഷണിക്കുന്നു. തേർഡ് പാർട്ടി ഇംപ്ലിമെന്റേഷനുകൾ എത്ര വേഗത്തിൽ വരുന്നു എന്നത്, ഈ പ്ലഗ്ഗബിൾ മോഡൽ Meteor-ന്റെ ആർക്കിടെക്ചറിന്റെ ഒരു സ്ഥിരമായ ഭാഗമാകുമോ എന്ന് സൂചിപ്പിക്കും.
ചുരുക്കത്തിൽ: Meteor 3.5-ലെ പ്ലഗ്ഗബിൾ DDP ട്രാൻസ്പോർട്ട് ഉപയോഗിച്ച് ഒരു സിംഗിൾ കമാൻഡിലൂടെ പഴയ SockJS സ്റ്റാക്കിന് പകരം uWebSockets.js ഉപയോഗിക്കാം. ഇത് RPC-ഭരിതമായ ആപ്ലിക്കേഷനുകൾക്ക് 1.6 മടങ്ങ് വരെ ഉയർന്ന ത്രൂപുട്ടും വിഭവങ്ങളുടെ ലാഭവും നൽകുന്നു, അതേസമയം ഈ മാറ്റം ആവശ്യമില്ലാത്ത വർക്ക്ലോഡുകൾക്ക് നിലവിലുള്ള സെറ്റപ്പ് മാറ്റമില്ലാതെ തന്നെ ഉപയോഗിക്കാം.