𝗠𝘆 𝗔𝗣𝗜 𝗥𝗲𝘀𝗽𝗼𝗻𝗱𝗲𝗱 𝗶𝗻 𝟰 𝗺𝘀, 𝗯𝘂𝘁 𝗡𝗮𝘃𝗶𝗴𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗶𝗹𝗹 𝗙𝗲𝗹𝘁 𝗦𝗹𝗼𝘄

SvelteKit மற்றும் Rust API மூலம் உருவாக்கப்பட்ட ஒரு திட்ட மேலாண்மை (project management) செயலியை நான் பிழைத்திருத்தம் (debugging) செய்து கொண்டிருந்தேன்.

எனது உள்ளூர் கணினியில் (local machine), அனைத்தும் உடனடியாக நடந்தது போலத் தோன்றியது. ஆனால் VPS-இல், வழிசெலுத்தல் (navigation) பாரமாக இருந்தது. Tickets அல்லது Timeline போன்ற பக்கங்களைத் திறக்க அதிக நேரம் எடுத்தது. ஒரு டிக்கெட்டை கிளிக் செய்தவுடன், அதன் முன்னோட்டம் (preview) தோன்றுவதற்கு முன் குறிப்பிடத்தக்க தாமதம் ஏற்பட்டது.

பிரச்சனை சர்வரில் தான் என்று நான் நினைத்தேன். மெதுவான தரவுத்தள வினவல்கள் (database queries) அல்லது பலவீனமான VPS தான் காரணம் என்று நான் சந்தேகித்தேன்.

அளவீடுகள் நான் நினைத்ததை தவறு என்று நிரூபித்தன.

நான் feature list endpoint-ஐச் சரிபார்த்தேன். வெறும் 52 டிக்கெட்டுகளுக்கு, API 4 ms-இல் பதிலளித்தது. அது வேகமானதாகத் தோன்றியது. ஆனால் அதன் பதில் அளவு (response size) 354 KB ஆக இருந்தது.

SvelteKit route payload-லும் இதே சிக்கல் தெரிந்தது. ஒரு சாதாரண பட்டியலுக்கு (list) தரவின் அளவு (data size) மிகப்பெரியதாக இருந்தது.

பிரச்சனை வேகம் அல்ல. பிரச்சனை அதன் எடை (weight).

விளக்கங்கள் (descriptions) மட்டுமே மொத்தப் பதிலில் 80% பங்களித்தன. அந்த list endpoint ஒவ்வொரு பொருளுக்கும் முழுமையான Markdown விளக்கங்களை அனுப்பிக் கொண்டிருந்தது.

இது ஒரு பொதுவான பொறி. list endpoint என்பது ஒரு detail endpoint ஆக மாறிவிட்டது. ஒரு பக்கத்திற்குப் பட்டியல் தேவைப்படும் போதெல்லாம், அதற்குத் தேவையில்லாத தரவிற்காகவும் அது விலையைக் கொடுக்க வேண்டியிருந்தது.

UI பயன்பாடு payload-ஐத் தீர்மானிப்பதில்லை. loader-ன் return shape தான் அதைத் தீர்மானிக்கிறது.

உங்கள் loader ஒரு முழுமையான பொருளை (full object) வழங்கினால், SvelteKit அந்த முழுப் பொருளையும் route data-வாக மாற்றுகிறது (serializes). நீங்கள் ஒரு புலத்தை (field) திரையில் காட்டாவிட்டாலும் கூட, அது நெட்வொர்க் வழியாகப் பயணிக்கும்.

சுருக்கத் தரவை (summary data) விரிவான தரவிலிருந்து (detail data) பிரிப்பதன் மூலம் இதை நான் சரிசெய்தேன்.

நான் இரண்டு வெவ்வேறு ஒப்பந்தங்களை (contracts) உருவாக்கினேன்:

• சுருக்கங்களுக்கான ஒரு list contract (ID, title, status, dates). • முழுமையான தகவல்களுக்கான ஒரு detail contract (descriptions, commands).

நான் API-ஐ இரண்டு endpoints-ஆகப் பிரித்தேன்:

  • GET /features (சுருக்கங்களை வழங்குகிறது)
  • GET /features/:id (ஒன்றை முழுமையான விவரங்களை வழங்குகிறது)

முன்பக்கத்தின் (frontend) செயல்பாட்டையும் நான் மாற்றினேன். இப்போது, செயலி சுருக்கத் தரவைப் பயன்படுத்தி பட்டியலை உடனடியாகத் திரையில் காட்டுகிறது. நீங்கள் ஒரு டிக்கெட்டை கிளிக் செய்யும் போது, செயலி ஒரு காலியான கட்டமைப்பைக் (shell) காட்டிவிட்டு, பின்னணியில் (background) அந்தப் பாரமான விரிவான தரவைச் சேகரிக்கிறது.

முடிவுகள் மிகப்பெரிய அளவில் இருந்தன:

• Feature list API: 89.6% குறைவு • Tickets route data: 91.4% குறைவு • OpenSpec docs API: 98.9% குறைவு

தரவுத்தளம் எப்போதும் வேகமாகவே இருந்தது. API மற்றும் பக்கத்திற்கு இடையிலான தரவு ஒப்பந்தம் (data contract) தான் உண்மையானத் தடையாகும் (bottleneck).

பட்டியல் சார்ந்த (list-heavy) செயலிகளுக்கான பாடங்கள்:

  • பதிலளிக்கும் நேரத்தை மட்டும் அளவிடாமல், பதிலின் அளவையும் அளவிடுங்கள்.
  • பட்டியல் மற்றும் விவரத் தரவுப் பேலோடுகளைத் (payloads) தனித்தனித் தேவைகளாகக் கருதுங்கள்.
  • பட்டியல் காட்சியில் (list view) பெரிய உரைத் புலங்களை (large text fields) ஒருபோதும் வழங்காதீர்கள்.
  • உங்கள் SSR லோடர் (loader) உண்மையில் எதை வரிசைப்படுத்துகிறது (serializing) என்பதைச் சரிபார்க்கவும்.
  • விவரத் தரவை லேசி-லோட் (lazy-load) செய்யுங்கள், ஆனால் UI ஷெல்லை (UI shell) உடனடியாகக் காட்டுங்கள்.
  • ஒரு கனமான பேலோடை (heavy payload) மறைப்பதற்காக லோடிங் ஸ்பின்னரை (loading spinner) பயன்படுத்தாதீர்கள்.

ஒரு வேகமான வினவல் (query) வேகமான பக்கத்திற்கு உத்தரவாதம் அளிக்காது.

ஆதாரம்: https://dev.to/ahikmah/my-api-responded-in-4-ms-but-navigation-still-felt-slow-1hk8