Static தளங்கள் மறுவெளியிடும்போதும் இயங்கிக் கொண்டிருக்கும்

Mythex-இல் static தளத்தை மறுவெளியிடுவது முன்பு நேரடிக் கோப்புகளை முதலில் நீக்கி, பின்னர் புதிய build-ஐ upload செய்தது. எனவே upload நடந்த நேரம் முழுவதும் சில பார்வையாளர்களுக்கு 404 பக்கம் அல்லது scripts காணாமல் போன பக்கம் கிடைத்தது. தோல்வியடைந்த upload தளத்தைக் காலியாகவோ பாதி புதியதாகவோ விட்டிருக்கலாம். இப்போது புதிய build பழையதின் மேல் எழுதப்படுகிறது, பக்கங்கள் கடைசியாகச் செல்கின்றன, மீதமுள்ளவை சில நிமிடங்கள் கழித்து அகற்றப்படுகின்றன. இரண்டாவது திருத்தம், மறுவெளியீடு ஒரு நிமிடத்திற்குப் பதிலாக சில நொடிகளில் தெரியுமாறு செய்கிறது. லோகோ போன்ற கோப்புகளுக்கு அது அதிகபட்சம் ஒரு நாள் ஆகலாம்.

Static தளம் எப்படி வழங்கப்படுகிறது

Static தளம் வெறும் கோப்புகளால் ஆனது: HTML பக்கங்கள், JavaScript, CSS, படங்கள். Mythex-இல் ஒன்றை வெளியிடும்போது, அதை build செய்து, வெளியீட்டை உங்கள் தளத்துக்கான ஒரு கோப்புறையின் கீழ் object storage-க்கு upload செய்கிறோம். பின்னர் அதை ஒரு edge network வழியாக வழங்குகிறோம். அது பார்வையாளர்களுக்கு அருகில் உள்ள சேவையகங்கள். அவை storage-இலிருந்து கோப்புகளை எடுத்து சிறிது நேரம் நகல்களை வைத்திருக்கும். (இது உங்களுக்குப் புதிதாக இருந்தால், CDN என்றால் என்ன என்ற எங்கள் வழிகாட்டி இந்தக் கருத்தை விளக்குகிறது.)

இரண்டு விஷயங்கள் தவறாக இருந்தன: மறுவெளியீடு கோப்புகளை எந்த வரிசையில் மாற்றியது, மற்றும் பழைய நகல்கள் எவ்வளவு நேரம் வைக்கப்பட்டன.

பிரச்சினை 1: upload முதலில் தளத்தைக் காலியாக்கியது

ஒரு மறுவெளியீடு தளத்தின் கோப்புறையில் இருந்த அனைத்தையும் நீக்கிவிட்டு, பின்னர் புதிய build-ஐ upload செய்தது. Upload எடுத்த நேரம் வரை, எங்கள் உள்ளூர் சோதனையில் 250 கோப்புகள் கொண்ட தளத்துக்கு 12 வினாடிகள், edge-இல் ஏற்கனவே cache ஆகாத கோரிக்கை கொண்ட ஒரு பார்வையாளருக்கு 404 கிடைத்தது. அல்லது scripts 404 தரும் ஒரு HTML பக்கம் கிடைத்தது.

தோல்வியடைந்த upload இன்னும் மோசமாக இருந்தது. கோப்புறை ஏற்கனவே காலியாகிவிட்டது. இரண்டு upload வழிகளில் ஒன்றில், தோல்வியடைந்த கோப்புக்கு முன்பே புதிய index.html வந்துவிடலாம். தோல்வி எனக் காட்டப்பட்ட ஒரு வெளியீடு பாதி புதிய தளத்தை நேரடியாக விட்டுவிடலாம்.

சரி: மேலே எழுது, பக்கங்கள் கடைசியாக, பின்னர் நீக்கு

1. முதலில் நீக்காதீர்கள். புதிய build பழையதின் மேல் upload செய்யப்படுகிறது.
2. பக்கங்களுக்கு முன் assets. ஒரு பக்கம் தனக்குத் தேவைப்படும் scripts மற்றும் styles-ஐக் குறிப்பிடுவதால், பக்கங்கள் கடைசியாகச் செல்கின்றன. புதிய பக்கங்கள் வரும் வரை, பார்வையாளர்களுக்கு பழைய பக்கம் கிடைக்கும். அது பழைய assets-ஐக் குறிப்பிடும், அவை இன்னும் இருக்கும். புதிய பக்கங்கள் வந்ததும், அவை குறிப்பிடும் புதிய assets ஏற்கனவே இடத்தில் இருக்கும்.
3. மீதமுள்ளவற்றை பின்னர் அகற்றுங்கள். Upload-க்கு முன், தளம் எதனால் ஆனது என்பதைப் பட்டியலிடுகிறோம். வெற்றிகரமான upload-க்கு மூன்று நிமிடங்கள் கழித்து, அந்தப் பட்டியலில் உள்ள, புதிய build மீண்டும் எழுதாத எதுவும் நீக்கப்படும். மூன்று நிமிடம் என்பது edge-இலும் உலாவியிலும் ஒரு பக்கம் cache ஆகக்கூடிய 60 வினாடிகளை விட நீளமானது. எனவே பழைய பக்கத்தை இன்னும் வைத்திருக்கும் பார்வையாளர் அது குறிப்பிடும் assets-ஐக் கண்டுபிடிக்க முடியும்.
4. சந்தேகம் இருந்தால், எதையும் நீக்காதீர்கள். Upload-க்கு முன் பட்டியல் தோல்வியடைந்தால், எதுவும் நீக்கப்படாது. மீதமுள்ள கோப்புகள் தீங்கற்றவை, அடுத்த வெளியீடு அவற்றைச் சுத்தம் செய்யும். அங்கு என்ன இருந்தது என்று தெரியாமல் நீக்குவதுதான் தளம் காலியாவதற்கான வழி.

இப்போது தோல்வியடைந்த upload முந்தைய தளத்தை சரியாக இருந்தபடியே விட்டுவிடுகிறது.

உண்மையான upload script, உண்மையான upload route மற்றும் storage serving, cold edge cache கொண்டு வரும் பார்வையாளர்கள் ஆகியவற்றைப் பயன்படுத்தி உள்ளூரில் இதை முனையிலிருந்து முனை வரை சோதித்தோம். பழைய குறியீட்டில், மறுவெளியீட்டின் போது 91-இல் 55 வருகைகள் உடைந்தன. தோல்வியடைந்த வெளியீட்டின் போது 92-இல் 61 உடைந்தன. புதிய குறியீட்டில், இரண்டு upload வழிகள், ஒரு தோல்வியடைந்த upload மற்றும் அதன் பின் வந்த வெளியீடு ஆகியவற்றை உள்ளடக்கிய சுமார் 3,500 வருகைகளில் 0 உடைந்தன. சரியாக மீதமுள்ள கோப்புகள் மட்டுமே நீக்கப்பட்டன.

பிரச்சினை 2: மறுவெளியீடு தெரிய மிக நேரம் எடுத்தது

Upload நன்றாக நடந்தபோதும், மாற்றங்கள் தோன்ற மெதுவாக இருந்தது. Edge ஒரு பக்கத்தின் நகலை 60 வினாடிகளும், மற்ற ஒவ்வொரு கோப்பின் நகலையும் ஒரு நாளும் வைத்திருந்தது. உலாவிகளுக்கும் அதையே சொன்னது. logo.png, எழுத்துரு, அல்லது public/ கோப்புறையில் இருந்து எதுவும் போன்ற நிலையான பெயர் கொண்ட கோப்புகள் மறுவெளியீட்டுக்குப் பின் ஒரு நாள் வரை பழைய பதிப்பைக் காட்டலாம்.

சரி: build-க்குக் கீழே கோப்பு நகல்கள்

Edge ஒரு தளம் எங்கே இருக்கிறது என்று எங்கள் API-இடம் கேட்கும்போது, பதிலில் இப்போது ஒவ்வொரு வெளியீடும் இறங்கும்போது மாறும் ஒரு build marker உள்ளது. Edge தனது நகல்களை அந்த marker-இன் கீழ் பதிவு செய்கிறது. எனவே edge-இன் 30 வினாடி தேடல் காலாவதியானவுடன் ஒரு வெளியீடு முற்றிலும் புதிய cache keys தொகுப்பாகிவிடுகிறது. பழைய நகல்கள் மீண்டும் கண்டுபிடிக்கப்படுவதே இல்லை. எனவே edge ஒரு நாள் வரை நகல்களை வைத்திருக்கலாம். அவற்றை மாற்றிய வெளியீட்டைத் தாண்டி ஒருபோதும் வழங்காது.

உலாவிகளுக்கு இரண்டு வெவ்வேறு விதிகள் கிடைக்கின்றன:

• Hash செய்யப்பட்ட build வெளியீடு: உள்ளடக்கம் மாறும்போதெல்லாம் பெயர் மாறும் assets/index-CzLcxDO8.js போன்ற கோப்புகள் ஒரு வருடம் cache ஆகும், மேலும் immutable எனக் குறிக்கப்படும். அந்தப் பெயரில் அது ஒருபோதும் பழையதாக இருக்காது.
• மற்ற அனைத்தும்: பக்கங்களும் லோகோ போன்ற நிலையான பெயர் கோப்புகளும் no-cache எனக் குறிக்கப்படுகின்றன. அதாவது "பயன்படுத்துவதற்கு முன் சரிபார்". எதுவும் மாறவில்லை என்றால், பதில் உடல் இல்லாத சிறிய 304 Not Modified. இப்போது உலாவியின் If-None-Match சோதனையை நாங்கள் மதிக்கிறோம்.

இரண்டையும் வேறுபடுத்துவதற்கு கவனம் தேவை. public/assets/-இலிருந்து நகலெடுக்கப்பட்ட கோப்பு தன் சொந்தப் பெயரைத் தக்கவைக்கும். assets/logo.png-ஐ ஒரு வருடம் cache செய்தால், பழைய லோகோ ஒரு வருடத்திற்குப் பூட்டப்பட்டுவிடும். எனவே ஒரு கோப்பு build வெளியீட்டுக் கோப்புறையில் இருந்தால் மற்றும் அதன் பெயரில் சாதாரண சொல் அல்லாமல் hash போலத் தோன்றும் ஒரு பகுதி இருந்தால் மட்டுமே அது hashed எனக் கருதப்படும்.

உள்ளூரில், புதிய பக்கமும் லோகோவும் வெளியீடு நேரலைக்கு வந்த 6 வினாடிகளுக்குப் பின் தெரிந்தன. முன்பு பக்கத்துக்கு 60 வினாடிகளும் லோகோவுக்கு ஒரு நாளும் ஆனது.

வழியில் செய்த இரண்டு சிறிய திருத்தங்கள்

• HEAD கோரிக்கைகளிலிருந்து வெற்றுப் பக்கங்கள். HEAD கோரிக்கை பக்கத்தின் body இல்லாமல் headers-ஐக் கேட்கிறது. அந்த வெற்று பதில்களை நாங்கள் cache செய்து கொண்டிருந்தோம். எனவே அந்தப் பக்கத்திற்கு அடுத்த பார்வையாளர் வெற்றுப் பக்கத்தைப் பெற்றார். இப்போது HEAD பதில்கள் cache செய்யப்படுவதில்லை.
• "இங்கு ஒன்றுமில்லை" என்பதற்கு ஒரு உண்மையான பக்கம். எந்த ஆப்பும் இல்லாத முகவரி முன்பு "இந்த வெளியிடப்பட்ட ஆப் offline அல்லது இணைப்பு கிடைக்கவில்லை" என்ற எளிய உரையை 502 பிழைக் குறியீட்டுடன் தந்தது. இப்போது அது "இங்கு ஆப் இல்லை" என்ற சரியான பக்கத்தை, 404 நிலையுடன், உரிமையாளருக்கு Mythex-க்குத் திரும்பும் வழியுடன் தருகிறது. அறியப்படாத தனிப்பயன் domains-உம் இதே பக்கத்தைப் பெறுகின்றன.

இதிலிருந்து நாங்கள் எடுத்துக்கொண்டவை

• வரிசையும் சரியான தன்மையின் ஒரு பகுதி. ஒரே கோப்புகளை வேறு வரிசையில் upload செய்தால், உடைந்த தளத்துக்கும் வேலை செய்யும் தளத்துக்கும் இடையிலான வேறுபாடு உருவாகிறது.
• தாமதமாக நீக்குங்கள், உங்களுக்குத் தெரிந்ததை மட்டும். Upload-க்கு முன் எடுத்த பட்டியலைக் கொண்டு நீக்குவது பாதுகாப்பானது. Upload முடியும் என்று நம்பி ஒரு கோப்புறையைக் காலியாக்குவது பாதுகாப்பானது அல்ல.
• நேரத்தால் அல்ல, பதிப்பால் cache செய்யுங்கள். காலாவதி நேரங்கள் உள்ளடக்கம் எப்போது மாறும் என்பதைப் பற்றிய யூகம். Build-உடன் மாறும் ஒரு key ஒரு உண்மை.

தொடர்புடையது: மறுவெளியீடு செய்யும்போதும் உங்கள் வெளியிடப்பட்ட ஆப் இயங்கிக் கொண்டிருக்கும். வெளியிடுவது பற்றி மேலும் ஆவணங்களில்.