റോഡ് റണ്ണർ: PHP മരിക്കാൻ വേണ്ടി നിർമ്മിച്ചതല്ല, അല്ലെങ്കിൽ രക്ഷാപ്രവർത്തനത്തിന് ഗോലാംഗ്

ഹലോ, ഹബ്ർ! ഞങ്ങൾ ബദൂവിൽ സജീവമാണ് PHP പ്രകടനത്തിൽ പ്രവർത്തിക്കുന്നു, ഈ ഭാഷയിൽ ഞങ്ങൾക്ക് സാമാന്യം വലിയ ഒരു സിസ്റ്റം ഉള്ളതിനാൽ പ്രകടനത്തിന്റെ പ്രശ്നം പണം ലാഭിക്കുന്ന കാര്യമാണ്. പത്ത് വർഷത്തിലേറെ മുമ്പ്, ഞങ്ങൾ ഇതിനായി PHP-FPM സൃഷ്ടിച്ചു, അത് ആദ്യം PHP-യുടെ ഒരു കൂട്ടം പാച്ചുകളായിരുന്നു, പിന്നീട് ഇത് ഔദ്യോഗിക വിതരണത്തിന്റെ ഭാഗമായി.

സമീപ വർഷങ്ങളിൽ, PHP മികച്ച പുരോഗതി കൈവരിച്ചു: മാലിന്യ ശേഖരണം മെച്ചപ്പെട്ടു, സ്ഥിരതയുടെ തോത് വർദ്ധിച്ചു - ഇന്ന് നിങ്ങൾക്ക് ഒരു പ്രശ്നവുമില്ലാതെ PHP-യിൽ ഡെമണുകളും ദീർഘകാല സ്ക്രിപ്റ്റുകളും എഴുതാം. ഇത് കൂടുതൽ മുന്നോട്ട് പോകാൻ സ്പൈറൽ സ്കൗട്ടിനെ അനുവദിച്ചു: PHP-FPM പോലെയല്ല, റോഡ് റണ്ണർ, അഭ്യർത്ഥനകൾക്കിടയിൽ മെമ്മറി വൃത്തിയാക്കുന്നില്ല, ഇത് അധിക പ്രകടന ആനുകൂല്യങ്ങൾ നൽകുന്നു (ഈ സമീപനം വികസന പ്രക്രിയയെ സങ്കീർണ്ണമാക്കുന്നുവെങ്കിലും). ഞങ്ങൾ നിലവിൽ ഈ ടൂൾ ഉപയോഗിച്ച് പരീക്ഷണം നടത്തുകയാണ്, എന്നാൽ ഞങ്ങൾക്ക് പങ്കിടാൻ ഇതുവരെ ഫലങ്ങളൊന്നുമില്ല. അവർക്കായി കാത്തിരിക്കുന്നത് കൂടുതൽ രസകരമാക്കാൻ, സ്പൈറൽ സ്കൗട്ടിൽ നിന്നുള്ള റോഡ് റണ്ണർ പ്രഖ്യാപനത്തിന്റെ വിവർത്തനം ഞങ്ങൾ പ്രസിദ്ധീകരിക്കുകയാണ്.

ലേഖനത്തിൽ നിന്നുള്ള സമീപനം ഞങ്ങൾക്ക് വളരെ അടുത്താണ്: ഞങ്ങളുടെ പ്രശ്നങ്ങൾ പരിഹരിക്കുമ്പോൾ, ഞങ്ങൾ മിക്കപ്പോഴും PHP, Go എന്നിവയുടെ സംയോജനമാണ് ഉപയോഗിക്കുന്നത്, രണ്ട് ഭാഷകളുടെയും പ്രയോജനങ്ങൾ നേടുകയും മറ്റൊന്നിന് അനുകൂലമായി ഉപേക്ഷിക്കാതിരിക്കുകയും ചെയ്യുന്നു.

ആസ്വദിക്കൂ!

കഴിഞ്ഞ പത്ത് വർഷമായി, ഞങ്ങൾ ലിസ്റ്റിൽ നിന്ന് കമ്പനികൾക്കായി ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിച്ചു ഫോർമുൻ 500, കൂടാതെ 500 ഉപയോക്താക്കളിൽ കൂടുതൽ പ്രേക്ഷകരില്ലാത്ത ബിസിനസ്സുകൾക്കും. ഇക്കാലമത്രയും, ഞങ്ങളുടെ എഞ്ചിനീയർമാർ പ്രധാനമായും പിഎച്ച്പിയിൽ ബാക്കെൻഡ് വികസിപ്പിച്ചെടുത്തു. എന്നാൽ രണ്ട് വർഷം മുമ്പ്, ഞങ്ങളുടെ ഉൽപ്പന്നങ്ങളുടെ പ്രകടനത്തിൽ മാത്രമല്ല, അവയുടെ സ്കേലബിലിറ്റിയിലും എന്തോ വലിയ സ്വാധീനം ചെലുത്തി - ഞങ്ങളുടെ ടെക്നോളജി സ്റ്റാക്കിലേക്ക് ഞങ്ങൾ Golang (Go) അവതരിപ്പിച്ചു.

40 മടങ്ങ് വേഗതയേറിയ പ്രകടനത്തോടെ വലിയ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കാൻ Go ഞങ്ങളെ അനുവദിച്ചതായി ഉടൻ തന്നെ ഞങ്ങൾ കണ്ടെത്തി. ഇത് ഉപയോഗിച്ച്, PHP-യിൽ എഴുതിയ നിലവിലുള്ള ഉൽപ്പന്നങ്ങൾ വികസിപ്പിക്കാനും രണ്ട് ഭാഷകളുടെയും ഗുണങ്ങൾ സംയോജിപ്പിച്ച് അവയെ മെച്ചപ്പെടുത്താനും ഞങ്ങൾക്ക് കഴിഞ്ഞു.

Go, PHP എന്നിവയുടെ സംയോജനം യഥാർത്ഥ വികസന പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ സഹായിക്കുന്നതെങ്ങനെയെന്നും അതുമായി ബന്ധപ്പെട്ട ചില പ്രശ്‌നങ്ങൾ ഇല്ലാതാക്കാൻ കഴിയുന്ന ഒരു ഉപകരണമായി അത് എങ്ങനെ മാറിയെന്നും ഞങ്ങൾ നിങ്ങളോട് പറയും. PHP മരിക്കുന്ന മോഡൽ.

നിങ്ങളുടെ ദൈനംദിന PHP വികസന പരിസ്ഥിതി

പി‌എച്ച്‌പിയുടെ ഡൈയിംഗ് മോഡൽ പുനരുജ്ജീവിപ്പിക്കാൻ ഗോ എങ്ങനെ ഉപയോഗിക്കാം എന്നതിനെക്കുറിച്ച് സംസാരിക്കുന്നതിന് മുമ്പ്, നിങ്ങളുടെ സ്റ്റാൻഡേർഡ് പി‌എച്ച്‌പി വികസന അന്തരീക്ഷം നോക്കാം.

മിക്ക കേസുകളിലും, നിങ്ങൾ nginx വെബ് സെർവറിന്റെയും PHP-FPM സെർവറിന്റെയും സംയോജനം ഉപയോഗിച്ചാണ് ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുന്നത്. ആദ്യത്തേത് സ്റ്റാറ്റിക് ഫയലുകൾ നൽകുകയും നിർദ്ദിഷ്ട അഭ്യർത്ഥനകൾ PHP-FPM-ലേക്ക് റീഡയറക്‌ടുചെയ്യുകയും ചെയ്യുന്നു, കൂടാതെ PHP-FPM തന്നെ PHP കോഡ് എക്‌സിക്യൂട്ട് ചെയ്യുന്നു. നിങ്ങൾ Apache, mod_php എന്നിവയിൽ നിന്നുള്ള ജനപ്രിയമല്ലാത്ത കോമ്പിനേഷനാണ് ഉപയോഗിക്കുന്നത്. എന്നാൽ ഇത് അൽപ്പം വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിലും, തത്വങ്ങൾ ഒന്നുതന്നെയാണ്.

PHP-FPM എങ്ങനെയാണ് ആപ്ലിക്കേഷൻ കോഡ് എക്സിക്യൂട്ട് ചെയ്യുന്നത് എന്ന് നോക്കാം. ഒരു അഭ്യർത്ഥന വരുമ്പോൾ, PHP-FPM ചൈൽഡ് PHP പ്രോസസ്സ് ആരംഭിക്കുകയും അഭ്യർത്ഥന വിശദാംശങ്ങൾ അതിന്റെ സംസ്ഥാനത്തിന്റെ ഭാഗമായി കൈമാറുകയും ചെയ്യുന്നു (_GET, _POST, _SERVER, മുതലായവ).

ഒരു PHP സ്ക്രിപ്റ്റ് നിർവ്വഹിക്കുമ്പോൾ അവസ്ഥ മാറ്റാൻ കഴിയില്ല, അതിനാൽ ഒരു പുതിയ സെറ്റ് ഇൻപുട്ട് ഡാറ്റ നേടുന്നതിന് ഒരേയൊരു മാർഗ്ഗമേയുള്ളൂ: പ്രോസസ്സ് മെമ്മറി മായ്‌ക്കുന്നതിലൂടെയും അത് പുനരാരംഭിക്കുന്നതിലൂടെയും.

ഈ എക്സിക്യൂഷൻ മോഡലിന് നിരവധി ഗുണങ്ങളുണ്ട്. മെമ്മറി ഉപഭോഗത്തെക്കുറിച്ച് നിങ്ങൾ കൂടുതൽ വിഷമിക്കേണ്ടതില്ല, എല്ലാ പ്രക്രിയകളും പൂർണ്ണമായും ഒറ്റപ്പെട്ടതാണ്, അവയിലൊന്ന് മരിക്കുകയാണെങ്കിൽ, ബാക്കിയുള്ള പ്രക്രിയകളെ ബാധിക്കാതെ അത് യാന്ത്രികമായി പുനർനിർമ്മിക്കും. എന്നാൽ ആപ്ലിക്കേഷൻ സ്കെയിൽ ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ ഈ സമീപനത്തിന് ദോഷങ്ങളുമുണ്ട്.

ഒരു സാധാരണ PHP പരിതസ്ഥിതിയുടെ പോരായ്മകളും കാര്യക്ഷമതയില്ലായ്മയും

നിങ്ങൾ PHP-യിൽ പ്രൊഫഷണൽ വികസനത്തിൽ ഏർപ്പെട്ടിരിക്കുകയാണെങ്കിൽ, ഒരു പുതിയ പ്രോജക്റ്റ് എവിടെ തുടങ്ങണമെന്ന് നിങ്ങൾക്കറിയാം - ഒരു ചട്ടക്കൂട് തിരഞ്ഞെടുക്കുന്നതിലൂടെ. ഡിപൻഡൻസി ഇഞ്ചക്ഷൻ, ORM-കൾ, വിവർത്തനങ്ങൾ, ടെംപ്ലേറ്റുകൾ എന്നിവയ്ക്കുള്ള ലൈബ്രറികൾ ഇതിൽ അടങ്ങിയിരിക്കുന്നു. തീർച്ചയായും, എല്ലാ ഉപയോക്തൃ ഇൻപുട്ടുകളും ഒരു ഒബ്ജക്റ്റിലേക്ക് സൗകര്യപ്രദമായി ഉൾപ്പെടുത്താം (Symfony/HttpFoundation അല്ലെങ്കിൽ PSR-7). ചട്ടക്കൂടുകൾ രസകരമാണ്!

എന്നാൽ എല്ലാത്തിനും അതിന്റേതായ വിലയുണ്ട്. ഏതൊരു എന്റർപ്രൈസ് ലെവൽ ചട്ടക്കൂടിലും, ഒരു ലളിതമായ ഉപയോക്തൃ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുന്നതിനോ ഒരു ഡാറ്റാബേസ് ആക്സസ് ചെയ്യുന്നതിനോ, നിങ്ങൾ കുറഞ്ഞത് ഡസൻ കണക്കിന് ഫയലുകളെങ്കിലും ലോഡ് ചെയ്യുകയും നിരവധി ക്ലാസുകൾ സൃഷ്ടിക്കുകയും നിരവധി കോൺഫിഗറേഷനുകൾ പാഴ്‌സ് ചെയ്യുകയും വേണം. എന്നാൽ ഏറ്റവും മോശം കാര്യം, ഓരോ ജോലിയും പൂർത്തിയാക്കിയ ശേഷം നിങ്ങൾ എല്ലാം പുനഃസജ്ജമാക്കി വീണ്ടും ആരംഭിക്കേണ്ടതുണ്ട്: നിങ്ങൾ ഇപ്പോൾ ആരംഭിച്ച എല്ലാ കോഡുകളും ഉപയോഗശൂന്യമാകും, അതിന്റെ സഹായത്തോടെ നിങ്ങൾ ഇനി മറ്റൊരു അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യില്ല. മറ്റേതെങ്കിലും ഭാഷയിൽ എഴുതുന്ന ഏതെങ്കിലും പ്രോഗ്രാമറോട് ഇത് പറയുക, അവന്റെ മുഖത്ത് നിങ്ങൾ പരിഭ്രാന്തി കാണും.

PHP എഞ്ചിനീയർമാർ ഈ പ്രശ്നം പരിഹരിക്കാനുള്ള വഴികൾ തേടാൻ വർഷങ്ങളോളം ചെലവഴിച്ചു, മിടുക്കരായ അലസമായ ലോഡിംഗ് ടെക്നിക്കുകൾ, മൈക്രോഫ്രെയിമുകൾ, ഒപ്റ്റിമൈസ് ചെയ്ത ലൈബ്രറികൾ, കാഷെകൾ മുതലായവ. എന്നാൽ അവസാനം, നിങ്ങൾ ഇപ്പോഴും മുഴുവൻ ആപ്ലിക്കേഷനും പുനഃസജ്ജീകരിച്ച് വീണ്ടും വീണ്ടും ആരംഭിക്കേണ്ടതുണ്ട്. (വിവർത്തകന്റെ കുറിപ്പ്: ന്റെ വരവോടെ ഈ പ്രശ്നം ഭാഗികമായി പരിഹരിക്കപ്പെടും പ്രിലോഡുചെയ്യുക PHP 7.4 ൽ)

Go ഉള്ള PHP-ക്ക് ഒന്നിലധികം അഭ്യർത്ഥനകളെ അതിജീവിക്കാൻ കഴിയുമോ?

ഏതാനും മിനിറ്റുകൾ (മണിക്കൂറുകൾ അല്ലെങ്കിൽ ദിവസങ്ങൾ വരെ) നീണ്ടുനിൽക്കുന്ന PHP സ്ക്രിപ്റ്റുകൾ എഴുതാൻ സാധിക്കും: ഉദാഹരണത്തിന്, ക്രോൺ ടാസ്ക്കുകൾ, CSV പാഴ്സറുകൾ, ക്യൂ ബസ്റ്ററുകൾ. അവയെല്ലാം ഒരേ സാഹചര്യത്തിനനുസരിച്ച് പ്രവർത്തിക്കുന്നു: അവർ ഒരു ടാസ്‌ക് വീണ്ടെടുക്കുകയും അത് നടപ്പിലാക്കുകയും അടുത്തതിനായി കാത്തിരിക്കുകയും ചെയ്യുന്നു. ചട്ടക്കൂടും ആപ്ലിക്കേഷനും ലോഡുചെയ്യുന്നതിന് നിരവധി അധിക ഘട്ടങ്ങൾ ആവശ്യമായതിനാൽ വിലയേറിയ മില്ലിസെക്കൻഡുകൾ ലാഭിക്കുന്ന കോഡ് മെമ്മറിയിൽ വസിക്കുന്നു.

എന്നാൽ ദീർഘകാല സ്ക്രിപ്റ്റുകൾ വികസിപ്പിക്കുന്നത് അത്ര എളുപ്പമല്ല. ഏതെങ്കിലും പിശക് പ്രക്രിയയെ പൂർണ്ണമായും ഇല്ലാതാക്കുന്നു, മെമ്മറി ലീക്കുകൾ കണ്ടെത്തുന്നത് നിങ്ങളെ ഭ്രാന്തനാക്കുന്നു, നിങ്ങൾക്ക് ഇനി F5 ഡീബഗ്ഗിംഗ് ഉപയോഗിക്കാൻ കഴിയില്ല.

PHP 7-ന്റെ പ്രകാശനത്തോടെ സ്ഥിതി മെച്ചപ്പെട്ടു: വിശ്വസനീയമായ ഒരു മാലിന്യ ശേഖരണം പ്രത്യക്ഷപ്പെട്ടു, പിശകുകൾ കൈകാര്യം ചെയ്യുന്നത് എളുപ്പമായി, കേർണൽ വിപുലീകരണങ്ങൾ ഇപ്പോൾ ചോർച്ചയിൽ നിന്ന് സംരക്ഷിക്കപ്പെട്ടിരിക്കുന്നു. ശരിയാണ്, എഞ്ചിനീയർമാർ ഇപ്പോഴും മെമ്മറിയിൽ ശ്രദ്ധാലുവായിരിക്കുകയും കോഡിലെ സംസ്ഥാന പ്രശ്‌നങ്ങളെക്കുറിച്ച് ബോധവാന്മാരായിരിക്കുകയും വേണം (ഇവയെക്കുറിച്ച് വിഷമിക്കേണ്ടതില്ലാത്ത ഭാഷയുണ്ടോ?). എന്നിട്ടും, PHP 7-ൽ, കുറച്ച് ആശ്ചര്യങ്ങൾ നമ്മെ കാത്തിരിക്കുന്നു.

ദീർഘകാല PHP സ്ക്രിപ്റ്റുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന മാതൃക സ്വീകരിക്കാനും HTTP അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നത് പോലെയുള്ള കൂടുതൽ നിസ്സാരമായ ജോലികളിലേക്ക് അത് പൊരുത്തപ്പെടുത്താനും അതുവഴി ഓരോ അഭ്യർത്ഥനയ്ക്കും ആദ്യം മുതൽ എല്ലാം ലോഡുചെയ്യേണ്ടതിന്റെ ആവശ്യകത ഇല്ലാതാക്കാനും കഴിയുമോ?

ഈ പ്രശ്‌നം പരിഹരിക്കുന്നതിന്, HTTP അഭ്യർത്ഥനകൾ സ്വീകരിക്കാനും ഓരോ തവണയും അത് നശിപ്പിക്കാതെ തന്നെ PHP വർക്കർക്ക് ഓരോന്നായി കൈമാറാനും കഴിയുന്ന ഒരു സെർവർ ആപ്ലിക്കേഷൻ നടപ്പിലാക്കേണ്ടതുണ്ട്.

ശുദ്ധമായ PHP (PHP-PM) അല്ലെങ്കിൽ C എക്സ്റ്റൻഷൻ (Swoole) ഉപയോഗിച്ച് ഞങ്ങൾക്ക് ഒരു വെബ് സെർവർ എഴുതാൻ കഴിയുമെന്ന് ഞങ്ങൾക്കറിയാമായിരുന്നു. ഓരോ രീതിക്കും അതിന്റേതായ ഗുണങ്ങളുണ്ടെങ്കിലും, രണ്ട് ഓപ്ഷനുകളും ഞങ്ങൾക്ക് അനുയോജ്യമല്ല - ഞങ്ങൾക്ക് കൂടുതൽ എന്തെങ്കിലും വേണം. ഞങ്ങൾക്ക് ഒരു വെബ് സെർവറിനേക്കാൾ കൂടുതൽ ആവശ്യമുണ്ട് - PHP-യിലെ "ഹാർഡ് സ്റ്റാർട്ട്" എന്നതുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങളിൽ നിന്ന് ഞങ്ങളെ രക്ഷിക്കാൻ കഴിയുന്ന ഒരു പരിഹാരം ലഭിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിച്ചു, അതേ സമയം നിർദ്ദിഷ്ട ആപ്ലിക്കേഷനുകൾക്കായി എളുപ്പത്തിൽ പൊരുത്തപ്പെടുത്താനും വികസിപ്പിക്കാനും കഴിയും. അതായത്, ഞങ്ങൾക്ക് ഒരു ആപ്ലിക്കേഷൻ സെർവർ ആവശ്യമാണ്.

ഇതിന് സഹായിക്കാൻ പോകുമോ? ഭാഷ പ്രയോഗങ്ങളെ ഒറ്റ ബൈനറികളാക്കി കംപൈൽ ചെയ്യുന്നതിനാൽ അതിന് കഴിയുമെന്ന് ഞങ്ങൾക്ക് അറിയാമായിരുന്നു; അത് ക്രോസ്-പ്ലാറ്റ്ഫോമാണ്; HTTP-യിൽ പ്രവർത്തിക്കുന്നതിന് അതിന്റേതായ, വളരെ ഗംഭീരമായ, സമാന്തര പ്രോസസ്സിംഗ് മോഡലും (കൺകറൻസി) ലൈബ്രറിയും ഉപയോഗിക്കുന്നു; അവസാനമായി, ആയിരക്കണക്കിന് ഓപ്പൺ സോഴ്‌സ് ലൈബ്രറികളും ഇന്റഗ്രേഷനുകളും ഞങ്ങൾക്ക് ലഭ്യമാകും.

രണ്ട് പ്രോഗ്രാമിംഗ് ഭാഷകൾ സംയോജിപ്പിക്കുന്നതിനുള്ള ബുദ്ധിമുട്ടുകൾ

രണ്ടോ അതിലധികമോ ആപ്ലിക്കേഷനുകൾ പരസ്പരം എങ്ങനെ ആശയവിനിമയം നടത്തുമെന്ന് നിർണ്ണയിക്കുക എന്നതായിരുന്നു ആദ്യപടി.

ഉദാഹരണത്തിന്, ഉപയോഗിക്കുന്നത് അത്ഭുതകരമായ ലൈബ്രറി അലക്സ് പാലെസ്ട്രസിന് PHP, Go പ്രക്രിയകൾക്കിടയിൽ മെമ്മറി പങ്കിടൽ നടപ്പിലാക്കാൻ കഴിയും (അപ്പാച്ചെയിലെ mod_php പോലെ). എന്നാൽ ഈ ലൈബ്രറിയിൽ ഞങ്ങളുടെ പ്രശ്നം പരിഹരിക്കുന്നതിനുള്ള അതിന്റെ ഉപയോഗം പരിമിതപ്പെടുത്തുന്ന സവിശേഷതകൾ ഉണ്ട്.

സോക്കറ്റുകൾ/പൈപ്പ് ലൈനുകൾ വഴിയുള്ള പ്രക്രിയകൾ തമ്മിലുള്ള പരസ്പരബന്ധം നിർമ്മിക്കുന്നതിന്, കൂടുതൽ സാധാരണമായ മറ്റൊരു സമീപനം ഉപയോഗിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഈ സമീപനം കഴിഞ്ഞ ദശകങ്ങളിൽ അതിന്റെ വിശ്വാസ്യത തെളിയിക്കുകയും ഓപ്പറേറ്റിംഗ് സിസ്റ്റം തലത്തിൽ നന്നായി ഒപ്റ്റിമൈസ് ചെയ്യുകയും ചെയ്തു.

ആരംഭിക്കുന്നതിന്, പ്രോസസ്സുകൾക്കിടയിൽ ഡാറ്റ കൈമാറ്റം ചെയ്യുന്നതിനും ട്രാൻസ്മിഷൻ പിശകുകൾ കൈകാര്യം ചെയ്യുന്നതിനുമായി ഞങ്ങൾ ഒരു ലളിതമായ ബൈനറി പ്രോട്ടോക്കോൾ സൃഷ്ടിച്ചു. ഏറ്റവും ലളിതമായ രൂപത്തിൽ, ഇത്തരത്തിലുള്ള പ്രോട്ടോക്കോൾ സമാനമാണ് നെറ്റ്സ്ട്രിംഗ് с നിശ്ചിത വലിപ്പമുള്ള പാക്കറ്റ് തലക്കെട്ട് (ഞങ്ങളുടെ കാര്യത്തിൽ 17 ബൈറ്റുകൾ), അതിൽ പാക്കറ്റിന്റെ തരം, അതിന്റെ വലിപ്പം, ഡാറ്റാ സമഗ്രത പരിശോധിക്കുന്നതിനുള്ള ബൈനറി മാസ്ക് എന്നിവയെക്കുറിച്ചുള്ള വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു.

ഞങ്ങൾ ഉപയോഗിച്ച PHP വശത്ത് പാക്ക് ഫംഗ്ഷൻ, ഒപ്പം Go വശത്ത് - ഒരു ലൈബ്രറി എൻകോഡിംഗ്/ബൈനറി.

ഒരു പ്രോട്ടോക്കോൾ മതിയാകില്ലെന്ന് ഞങ്ങൾക്ക് തോന്നി - അതിനാൽ ഞങ്ങൾ വിളിക്കാനുള്ള കഴിവ് ചേർത്തു PHP-യിൽ നിന്ന് നേരിട്ട് സേവനങ്ങൾ net/rpc-ലേക്ക് പോകുക. ഇത് പിന്നീട് വികസനത്തിൽ ഞങ്ങളെ വളരെയധികം സഹായിച്ചു, കാരണം ഞങ്ങൾക്ക് ഗോ ലൈബ്രറികളെ PHP ആപ്ലിക്കേഷനുകളിലേക്ക് എളുപ്പത്തിൽ സംയോജിപ്പിക്കാൻ കഴിയും. ഈ ജോലിയുടെ ഫലം കാണാൻ കഴിയും, ഉദാഹരണത്തിന്, ഞങ്ങളുടെ മറ്റ് ഓപ്പൺ സോഴ്‌സ് ഉൽപ്പന്നത്തിൽ ഗോരിഡ്ജ്.

ഒന്നിലധികം PHP തൊഴിലാളികൾക്കിടയിൽ ടാസ്‌ക്കുകൾ വിതരണം ചെയ്യുന്നു

ഇന്ററാക്ഷൻ മെക്കാനിസം നടപ്പിലാക്കിയ ശേഷം, പി‌എച്ച്പി പ്രോസസ്സുകളിലേക്ക് ടാസ്‌ക്കുകൾ എങ്ങനെ ഏറ്റവും കാര്യക്ഷമമായി കൈമാറാമെന്ന് ഞങ്ങൾ ചിന്തിക്കാൻ തുടങ്ങി. ഒരു ടാസ്ക് എത്തുമ്പോൾ, അത് പൂർത്തിയാക്കാൻ ആപ്ലിക്കേഷൻ സെർവർ ഒരു സ്വതന്ത്ര തൊഴിലാളിയെ തിരഞ്ഞെടുക്കണം. ഒരു ജോലിക്കാരൻ/പ്രക്രിയ ഒരു പിശകോടെ അവസാനിക്കുകയോ "മരിക്കുകയോ" ചെയ്‌താൽ, ഞങ്ങൾ അത് ഒഴിവാക്കുകയും പകരം പുതിയൊരെണ്ണം സൃഷ്‌ടിക്കുകയും ചെയ്യുന്നു. തൊഴിലാളി/പ്രക്രിയ വിജയകരമായി പൂർത്തിയാക്കിയിട്ടുണ്ടെങ്കിൽ, ടാസ്‌ക്കുകൾ നിർവഹിക്കാൻ ലഭ്യമായ തൊഴിലാളികളുടെ കൂട്ടത്തിലേക്ക് ഞങ്ങൾ അത് തിരികെ നൽകും.

ഞങ്ങൾ ഉപയോഗിച്ച സജീവ തൊഴിലാളികളുടെ ഒരു കുളം സംഭരിക്കുന്നതിന് ബഫർ ചെയ്ത ചാനൽ, അപ്രതീക്ഷിതമായി "മരിച്ച" തൊഴിലാളികളെ പൂളിൽ നിന്ന് നീക്കംചെയ്യുന്നതിന്, പിശകുകളും തൊഴിലാളി സംസ്ഥാനങ്ങളും ട്രാക്കുചെയ്യുന്നതിനുള്ള ഒരു സംവിധാനം ഞങ്ങൾ ചേർത്തു.

തൽഫലമായി, ബൈനറി രൂപത്തിൽ അവതരിപ്പിക്കുന്ന ഏത് അഭ്യർത്ഥനകളും പ്രോസസ്സ് ചെയ്യാൻ കഴിവുള്ള ഒരു പ്രവർത്തിക്കുന്ന PHP സെർവർ ഞങ്ങൾക്ക് ലഭിച്ചു.

ഞങ്ങളുടെ അപ്ലിക്കേഷന് ഒരു വെബ് സെർവറായി പ്രവർത്തിക്കുന്നതിന്, ഇൻകമിംഗ് എച്ച്ടിടിപി അഭ്യർത്ഥനകളെ പ്രതിനിധീകരിക്കുന്നതിന് ഞങ്ങൾ വിശ്വസനീയമായ ഒരു PHP നിലവാരം തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്. ഞങ്ങളുടെ കാര്യത്തിൽ ഞങ്ങൾ വെറുതെ രൂപാന്തരപ്പെടുത്തുക ഫോർമാറ്റിലേക്ക് പോകുന്നതിൽ നിന്ന് net/http അഭ്യർത്ഥന PSR-7അതിനാൽ ഇന്ന് ലഭ്യമായ മിക്ക PHP ചട്ടക്കൂടുകളുമായും ഇത് പൊരുത്തപ്പെടുന്നു.

PSR-7 മാറ്റമില്ലാത്തതായി കണക്കാക്കപ്പെടുന്നതിനാൽ (സാങ്കേതികമായി അത് അങ്ങനെയല്ലെന്ന് ചിലർ പറയും), ഡെവലപ്പർമാർ അഭ്യർത്ഥനയെ ഒരു ആഗോള സ്ഥാപനമായി അടിസ്ഥാനപരമായി പരിഗണിക്കാത്ത ആപ്ലിക്കേഷനുകൾ എഴുതേണ്ടതുണ്ട്. ഇത് ദീർഘകാല PHP പ്രക്രിയകളുടെ ആശയവുമായി നന്നായി യോജിക്കുന്നു. ഇതുവരെ പേരിട്ടിട്ടില്ലാത്ത ഞങ്ങളുടെ അന്തിമ നിർവ്വഹണം ഇതുപോലെ കാണപ്പെട്ടു:

റോഡ് റണ്ണർ അവതരിപ്പിക്കുന്നു - ഉയർന്ന പ്രകടനമുള്ള PHP ആപ്ലിക്കേഷൻ സെർവർ

ഞങ്ങളുടെ ആദ്യ ടെസ്റ്റ് ടാസ്‌ക് API ബാക്കെൻഡ് ആയിരുന്നു, അത് ഇടയ്‌ക്കിടെ അപ്രതീക്ഷിതമായ അഭ്യർത്ഥനകൾ (സാധാരണയിലും കൂടുതൽ തവണ) അനുഭവപ്പെട്ടു. മിക്ക കേസുകളിലും nginx മതിയായിരുന്നുവെങ്കിലും, ലോഡിൽ പ്രതീക്ഷിക്കുന്ന വർദ്ധനയ്ക്കായി സിസ്റ്റം വേഗത്തിൽ സന്തുലിതമാക്കാൻ ഞങ്ങൾക്ക് കഴിയാത്തതിനാൽ ഞങ്ങൾ പതിവായി 502 പിശകുകൾ നേരിട്ടു.

ഈ പരിഹാരം മാറ്റിസ്ഥാപിക്കുന്നതിന്, 2018-ന്റെ തുടക്കത്തിൽ ഞങ്ങൾ ഞങ്ങളുടെ ആദ്യത്തെ PHP/Go ആപ്ലിക്കേഷൻ സെർവർ വിന്യസിച്ചു. ഉടനെ ഞങ്ങൾക്ക് അവിശ്വസനീയമായ ഒരു പ്രഭാവം ലഭിച്ചു! 502 പിശക് പൂർണ്ണമായും ഒഴിവാക്കുക മാത്രമല്ല, സെർവറുകളുടെ എണ്ണം മൂന്നിൽ രണ്ട് കുറയ്ക്കാനും ഞങ്ങൾക്ക് കഴിഞ്ഞു, എഞ്ചിനീയർമാർക്കും ഉൽപ്പന്ന മാനേജർമാർക്കും ധാരാളം പണവും തലവേദനയും ലാഭിച്ചു.

വർഷത്തിന്റെ മധ്യത്തോടെ, ഞങ്ങൾ ഞങ്ങളുടെ പരിഹാരം പൂർത്തിയാക്കി, MIT ലൈസൻസിന് കീഴിൽ GitHub-ൽ പ്രസിദ്ധീകരിക്കുകയും അതിനെ വിളിക്കുകയും ചെയ്തു. റോഡ് റണ്ണർ, അതുവഴി അതിന്റെ അവിശ്വസനീയമായ വേഗതയും കാര്യക്ഷമതയും ഊന്നിപ്പറയുന്നു.

റോഡ് റണ്ണറിന് നിങ്ങളുടെ ഡെവലപ്‌മെന്റ് സ്റ്റാക്ക് എങ്ങനെ മെച്ചപ്പെടുത്താനാകും

അപേക്ഷ റോഡ് റണ്ണർ അഭ്യർത്ഥന PHP-യിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ JWT പരിശോധന നടത്താൻ Go വശത്ത് Middleware net/http ഉപയോഗിക്കാൻ ഞങ്ങളെ അനുവദിച്ചു.

ബിൽറ്റ്-ഇൻ ആർ‌പി‌സിക്ക് നന്ദി, വിപുലീകരണ റാപ്പറുകൾ എഴുതാതെ തന്നെ നിങ്ങൾക്ക് പി‌എച്ച്‌പിയ്‌ക്കായി ഏത് ഗോ ലൈബ്രറികളുടെയും എപിഐ തുറക്കാനാകും. ഏറ്റവും പ്രധാനമായി, പുതിയ എച്ച്ടിടിപി ഇതര സെർവറുകൾ വിന്യസിക്കാൻ റോഡ് റണ്ണർ ഉപയോഗിക്കാം. PHP-യിൽ ഹാൻഡ്‌ലറുകൾ ലോഞ്ച് ചെയ്യുന്നത് ഉദാഹരണങ്ങളിൽ ഉൾപ്പെടുന്നു AWS Lambda, വിശ്വസനീയമായ ക്യൂ ബസ്റ്ററുകൾ സൃഷ്ടിക്കുകയും കൂട്ടിച്ചേർക്കുകയും ചെയ്യുന്നു gRPC ഞങ്ങളുടെ അപേക്ഷകളിലേക്ക്.

PHP, Go കമ്മ്യൂണിറ്റികളുടെ സഹായത്തോടെ, ഞങ്ങൾ പരിഹാരത്തിന്റെ സ്ഥിരത വർദ്ധിപ്പിച്ചു, ചില ടെസ്റ്റുകളിൽ ആപ്ലിക്കേഷൻ പ്രകടനം 40 മടങ്ങ് വരെ വർദ്ധിപ്പിച്ചു, ഡീബഗ്ഗിംഗ് ടൂളുകൾ മെച്ചപ്പെടുത്തി, സിംഫണി ചട്ടക്കൂടുമായുള്ള സംയോജനം നടപ്പിലാക്കി, HTTPS, HTTP/ എന്നിവയ്ക്കുള്ള പിന്തുണ ചേർത്തു. 2, പ്ലഗിനുകൾ, PSR-17.

തീരുമാനം

വേർഡ്പ്രസ്സ് പ്ലഗിനുകൾ എഴുതാൻ മാത്രം നല്ല, വേഗത കുറഞ്ഞതും ബുദ്ധിമുട്ടുള്ളതുമായ ഭാഷയായി PHP യുടെ കാലഹരണപ്പെട്ട കാഴ്ചയിൽ ചില ആളുകൾ ഇപ്പോഴും കുടുങ്ങിക്കിടക്കുന്നു. പി‌എച്ച്‌പിക്ക് ഒരു പരിമിതി ഉണ്ടെന്ന് ഈ ആളുകൾ പറഞ്ഞേക്കാം: ആപ്ലിക്കേഷൻ ആവശ്യത്തിന് വലുതാകുമ്പോൾ, നിങ്ങൾ കൂടുതൽ “പക്വമായ” ഭാഷ തിരഞ്ഞെടുക്കുകയും നിരവധി വർഷങ്ങളായി കുമിഞ്ഞുകൂടിയ കോഡ് ബേസ് തിരുത്തിയെഴുതുകയും വേണം.

ഇതിനെല്ലാം ഞാൻ ഉത്തരം നൽകാൻ ആഗ്രഹിക്കുന്നു: വീണ്ടും ചിന്തിക്കുക. PHP-യ്‌ക്കായി നിങ്ങൾക്ക് മാത്രമേ എന്തെങ്കിലും നിയന്ത്രണങ്ങൾ സജ്ജമാക്കാൻ കഴിയൂ എന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു. നിങ്ങളുടെ ജീവിതകാലം മുഴുവൻ ഒരു ഭാഷയിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ചാടാൻ കഴിയും, നിങ്ങളുടെ ആവശ്യങ്ങൾക്ക് അനുയോജ്യമായത് കണ്ടെത്താൻ ശ്രമിക്കുക, അല്ലെങ്കിൽ നിങ്ങൾക്ക് ഭാഷകളെ ഉപകരണങ്ങളായി ചിന്തിക്കാൻ തുടങ്ങാം. PHP പോലുള്ള ഒരു ഭാഷയുടെ പോരായ്മകൾ യഥാർത്ഥത്തിൽ അതിന്റെ വിജയത്തിന് കാരണമായേക്കാം. Go പോലെയുള്ള മറ്റൊരു ഭാഷയുമായി നിങ്ങൾ ഇത് സംയോജിപ്പിച്ചാൽ, നിങ്ങൾ ഒരു ഭാഷയിൽ മാത്രം പരിമിതപ്പെടുത്തിയിരിക്കുന്നതിനേക്കാൾ കൂടുതൽ ശക്തമായ ഉൽപ്പന്നങ്ങൾ സൃഷ്ടിക്കാൻ നിങ്ങൾക്ക് കഴിയും.

Go, PHP എന്നിവയുടെ സംയോജനത്തിൽ പ്രവർത്തിച്ചതിനാൽ, ഞങ്ങൾ അവരെ സ്നേഹിക്കുന്നുവെന്ന് പറയാം. ഞങ്ങൾ ഒന്നിനെ മറ്റൊന്നിനായി ത്യജിക്കാൻ ഉദ്ദേശിക്കുന്നില്ല, പകരം ഈ ഡ്യുവൽ സ്റ്റാക്കിൽ നിന്ന് കൂടുതൽ മൂല്യം നേടാനുള്ള വഴികൾ തേടുക.

UPD: RoadRunner-ന്റെ സ്രഷ്ടാവിനെയും യഥാർത്ഥ ലേഖനത്തിന്റെ സഹ-രചയിതാവിനെയും ഞങ്ങൾ സ്വാഗതം ചെയ്യുന്നു - ലചെസിസ്

അവലംബം: www.habr.com