இறந்த இணைப்புகள் இல்லாமல் தரவுத்தளங்களை எழுப்புதல்

Mythex-இல் வெளியிடப்பட்ட ஆப்களும் அவற்றின் தரவுத்தளங்களும், யாரும் பயன்படுத்தாதபோது தூங்கச் செல்கின்றன. ஒரு ஆப் எழுந்தபோது, அதன் முதல் கோரிக்கையை 10–12 வினாடிகள் வைத்திருந்தது. ஏனெனில் அனைத்தும் தூங்கியபோது இறந்துபோன தரவுத்தள இணைப்புகளை மீண்டும் பயன்படுத்த முயன்றது. இப்போது Spring Boot ஆப்களுக்குத் தூக்கத்தைத் தாங்கும் தரவுத்தள அமைப்புகளைத் தருகிறோம். எந்த stack-இல் கட்டப்பட்ட ஆப்களாக இருந்தாலும் அதே முறையில் கட்டும்படி ஏஜென்ட்டுக்குச் சொல்கிறோம். ஹோஸ்டிங் தளத்தில், எழுந்த பின் வரும் முதல் கோரிக்கை 12.7 வினாடிகளிலிருந்து 2.3 வினாடிகளாகக் குறைந்தது.

ஆப்களும் தரவுத்தளங்களும் ஏன் தூங்குகின்றன

வெளியிடப்பட்ட Mythex ஆப் சில நிமிடங்கள் செயலற்று இருந்தால் இடைநிறுத்தப்படும் ஒரு இயந்திரத்தில் இயங்குகிறது. அதன் தரவுத்தளம் ஐந்து நிமிடம் செயலற்று இருந்தால் தூங்கும், அடுத்த கோரிக்கையில் எழும் serverless Postgres. அமைதியான ஆப்பைக் குறைந்த செலவில் வைத்திருப்பது அதுதான்: தரவுத்தளம் உண்மையில் பயன்படுத்தியதற்கே கட்டணம். தூங்கும் ஆப் compute-க்கு எதுவும் செலவழிக்காது. கட்டணப் பக்கத்தைப் பற்றி தரவுத்தளங்களுக்கு அவை உண்மையில் பயன்படுத்தியதன் அடிப்படையில் கட்டணம் என்ற இடத்தில் எழுதியுள்ளோம்.

சிக்கல் என்னவென்றால், இரண்டும் தனித்தனியாகத் தூங்குகின்றன. இணைப்பு என்றால் என்ன என்பதில் அவை ஒத்துப்போவதில்லை.

அறிகுறி: முதல் வருகை மெதுவாக இருப்பது

பெரும்பாலான server ஆப்கள் connection pool வைத்திருக்கின்றன: தயாராக வைக்கப்பட்ட சில திறந்த தரவுத்தள இணைப்புகள். ஒவ்வொரு கோரிக்கையும் புதிய ஒன்றைத் திறக்கும் செலவைச் செலுத்தாமல் இருக்கும். எப்போதும் இயங்கும் ஆப்புக்கு அது சரியான வடிவமைப்பு.

தூக்கத்துடன் இங்கு நடப்பது:

1. ஆப் இயங்குகிறது, அதன் pool-இல் சில செயலற்ற இணைப்புகள் உள்ளன.
2. யாரும் வருவதில்லை. ஆப்பின் இயந்திரம் இடைநிறுத்தப்படுகிறது — pool அப்படியே இருக்க, உறைந்து.
3. தரவுத்தளம் தூங்கி, ஒவ்வொரு இணைப்பின் தன் பக்கத்தையும் விட்டுவிடுகிறது.
4. ஒரு பார்வையாளர் வருகிறார். ஆப் அப்படியே எழுகிறது. தரவுத்தளத்துக்கு இனி தெரியாத இணைப்புகளை இன்னும் வைத்திருக்கிறது.
5. Pool அவற்றில் ஒன்றைக் கொடுக்கிறது. அதை விட்டுவிடுவதற்கு முன், அது இறந்துவிட்டதா என்பதை — முயன்று காத்திருப்பதன் மூலம் — அறிய வேண்டும்.

Spring Boot ஆப்பில், அந்த இறந்த இணைப்புகளைச் சரிபார்ப்பது முதல் கோரிக்கையை சுமார் 10 வினாடிகள் தடுத்தது. பின்னர் "Connection is not available" என்ற பிழையுடன் அது தோல்வியடைந்தது. பார்வையாளருக்கு தளம் வெறுமனே தொங்கியது, பின்னர் ஒரு பிழை காட்டியது.

Spring ஆப்கள் ஏன் மிக மோசமாகப் பாதிக்கப்பட்டன

Spring Boot ஒரு பிரபலமான Java framework. அது இயல்பாக HikariCP என்ற connection pool-ஐப் பயன்படுத்துகிறது. எவ்வளவு செயலற்ற இணைப்புகளை வைத்திருப்பது உட்பட, அந்த pool-ஐ அமைப்புகளிலிருந்து Spring கட்டமைக்க முடியும்.

ஆனால் Mythex ஒவ்வொரு ஆப்புக்கும் தரவுத்தளத்தை postgresql://user:pass@host/db வடிவில் ஒற்றை DATABASE_URL ஆகக் கொடுக்கிறது. Spring அந்த வடிவத்தை நேரடியாகப் படிக்க முடியாது. எனவே Mythex-இல் கட்டப்பட்ட Spring ஆப்கள் அந்த URL-ஐப் பகுப்பாய்வு செய்து குறியீட்டிலேயே தங்கள் சொந்த pool-ஐக் கட்டின. கைமுறையாகக் கட்டப்பட்ட pool, Spring-இன் spring.datasource.* அமைப்புகள் அனைத்தையும் புறக்கணிக்கிறது. சரியான pool அமைப்புகள் யாருக்குத் தெரிந்திருந்தாலும், அவை செயல்படக்கூடிய இடமே இல்லை.

சரி, பகுதி 1: Spring பயன்படுத்தக்கூடிய அமைப்புகள்

ஒரு திட்டத்தில் தரவுத்தளம் இருந்தால், Spring நேரடியாகப் படிக்கும் சூழல் மாறிகளையும் இப்போது தருகிறோம்:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME மற்றும் SPRING_DATASOURCE_PASSWORD. இவை DATABASE_URL-இலிருந்து மாற்றப்படுகின்றன. URL வேறு சொல்லாவிட்டால் SSL தேவை.
• தூக்கத்தைத் தாங்கும் pool அமைப்புகள்:

செயலற்ற இணைப்புகள் எதுவும் வைத்திருக்கப்படாததால், எழுந்த ஆப் இறந்தவற்றின் வழியாக நடப்பதற்குப் பதிலாக ஒரு புதிய இணைப்பைத் திறக்கிறது.

இந்த சூழல் மாறிகள் இருக்கும்போது, Spring pool-ஐத் தானே கட்டமைக்கிறது, அமைப்புகள் பொருந்துகின்றன. திட்டம் தானாக அமைத்த எதுவும் எப்போதும் வெற்றி பெறும். காணாமல் போனதை மட்டுமே நிரப்புகிறோம். Spring அல்லாத ஆப்கள் இந்த சூழல் மாறிகளைப் புறக்கணிக்கின்றன.

கிட்டத்தட்ட எதையும் செய்யாமல் போன விவரம்

Spring சூழல் மாறிகளை தன் அமைப்புகளுக்கு, எளிதில் தவறாகப் போகும் ஒரு விதியின்படி வரைபடமிடுகிறது. minimum-idle அமைப்பை SPRING_DATASOURCE_HIKARI_MINIMUMIDLE என்று எழுத வேண்டும். கோடுகள் நீக்கப்பட்டு, சொற்கள் ஒன்றாக இணைக்கப்பட்டு. இயற்கையாகத் தோன்றும் SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE என்று எழுதினால், அது வேறு, இல்லாத ஒரு அமைப்புக்கு (minimum.idle) செல்கிறது. அது அமைதியாகப் புறக்கணிக்கப்படும்.

அப்படிப்பட்ட தவறு ஒவ்வொரு மதிப்பாய்வையும் கடந்துவிடும், production-இல் எதையும் செய்யாது. எனவே ஒரு சோதனை மதிப்புகள் அமைக்கப்பட்டுள்ளனவா என்றும், எந்த மாறியும் அடிக்கோடு பிரித்த வடிவில் இல்லை என்றும் இரண்டையும் உறுதிப்படுத்துகிறது.

சரி, பகுதி 2: மற்ற எல்லா stack-களும்

Spring மட்டுமே pool கொண்ட framework அல்ல. ஒவ்வொரு மொழியிலும் உள்ள ஒவ்வொரு நூலகத்தையும் நாங்கள் முன்கூட்டியே கட்டமைக்க முடியாது. எனவே உங்கள் ஆப்பை எழுதும் Mythex ஏஜென்ட், எந்த stack-க்கும் ஒரு நிலையான அறிவுறுத்தலைப் பெறுகிறது: வெளியிடப்பட்ட ஆப்களும் அவற்றின் தரவுத்தளங்களும் செயலற்று இருக்கும்போது தூங்குகின்றன. எனவே வைக்கப்பட்ட ஒரு இணைப்பு அடுத்த கோரிக்கையில் இறந்திருக்கலாம். அது:

• எந்த செயலற்ற தரவுத்தள இணைப்பையும் திறந்து வைக்கக்கூடாது, அல்லது பயன்படுத்தும் முன் ஒவ்வொன்றையும் சரிபார்க்க வேண்டும்,
• இணைப்புப் பிழையில் ஒருமுறை மீண்டும் முயல வேண்டும், மற்றும்
• DATABASE_URL-ஐ பகுப்பாய்வு செய்து தன் சொந்த pool-ஐக் கட்டாமல், சூழலில் தளம் வழங்கும் தரவுத்தள அமைப்புகளைப் பயன்படுத்த வேண்டும்.

கடைசிப் புள்ளி பகுதி 1-உடன் வட்டத்தை நிறைவு செய்கிறது. வழங்கப்பட்ட அமைப்புகளில் கட்டப்பட்ட ஆப், தூக்கத்தைத் தாங்கும் கட்டமைப்பை தானாகப் பெறுகிறது.

முடிவு

நாங்கள் வெளியிடப்பட்ட ஆப்களை இயக்கும் ஹோஸ்டிங் தளத்தில் அளவிட்டபோது, எழுந்த பின் வரும் முதல் கோரிக்கை 12.7 வினாடிகளிலிருந்து 2.3 வினாடிகளாக குறைந்தது.

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

• தூங்கும் ஒவ்வொரு அடுக்கும் எது தப்பிப் பிழைக்கும் என்பதில் ஒத்துப்போக வேண்டும். உறைந்த ஆப்பும், தூங்கும் தரவுத்தளமும் ஒவ்வொன்றும் நியாயமான ஒரு முடிவை எடுத்தன. ஒன்றாகச் சேர்ந்தபோது, ஆப் இனி உண்மையாக இல்லாத நிலையை வைத்துக்கொண்டு எழுந்தது.
• எப்போதும் இயங்கும் சர்வர்களுக்கு வடிவமைக்கப்பட்ட இயல்புநிலைகள், பூஜ்ஜியத்துக்கு அளவிடும் ஆப்களுக்குப் பொருந்தாது. சுற்றியுள்ள அனைத்தும் குளிர்ந்துவிடும்வரை இணைப்புகளை சூடாக வைத்திருப்பது நல்ல யோசனைதான்.
• Frameworks-க்கு அவற்றின் தரவை அவற்றின் சொந்த வடிவத்தில் கொடுங்கள். எங்களுக்கு ஒரு URL எளிமையாக இருந்தது. ஆனால் அது ஒவ்வொரு Spring ஆப்பையும் தன் சொந்த கட்டமைப்பைப் புறக்கணிக்கும் pool-ஐ கைமுறையாக எழுதத் தள்ளியது.
• ஒரு அமைப்பு framework படிக்கும் எழுத்துப்பிழையில் இருக்கிறதா என்று சோதியுங்கள். தவறான பெயரில் சரியான மதிப்பு எதையும் செய்யாது, அமைதியாக.

Mythex-இல் தரவுத்தளங்கள் எப்படி வேலை செய்கின்றன என்று புதியவராக இருந்தால், தரவுத்தள ஆவணங்களைப் பாருங்கள். Postgres என்றால் என்ன என்ற எங்கள் விளக்கமும் உதவும்.