എന്റെ API 4 ms-ൽ പ്രതികരിച്ചു, പക്ഷേ നാവിഗേഷൻ ഇപ്പോഴും പതുക്കെയാണ് അനുഭവപ്പെട്ടത്

SvelteKit-ഉം Rust API-യും ഉപയോഗിച്ച് നിർമ്മിച്ച ഒരു പ്രോജക്റ്റ് മാനേജ്‌മെന്റ് ആപ്പ് ഞാൻ ഡീബഗ് ചെയ്യുകയായിരുന്നു.

എന്റെ ലോക്കൽ മെഷീനിൽ എല്ലാം പെട്ടെന്ന് തന്നെ പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നു. എന്നാൽ VPS-ൽ നാവിഗേഷൻ വളരെ പതുക്കെയാണ് അനുഭവപ്പെട്ടത്. Tickets അല്ലെങ്കിൽ Timeline പോലുള്ള പേജുകൾ തുറക്കാൻ ഒരുപാട് സമയമെടുത്തു. ഒരു ടിക്കറ്റിൽ ക്ലിക്ക് ചെയ്യുമ്പോൾ പ്രിവ്യൂ കാണുന്നതിന് മുൻപ് ശ്രദ്ധേയമായ ഒരു താമസം അനുഭവപ്പെട്ടു.

പ്രശ്നം സെർവറിലാണെന്നാണ് ഞാൻ കരുതിയത്. ഡാറ്റാബേസ് ക്വറികൾ പതുക്കെയാണെന്നോ അല്ലെങ്കിൽ ഒരു ദുർബലമായ VPS ആണെന്നോ ഞാൻ സംശയിച്ചു.

എന്നാൽ അളവുകൾ എന്റെ തെറ്റ് തെളിയിച്ചു.

ഞാൻ ഫീച്ചർ ലിസ്റ്റ് എൻഡ്പോയിന്റ് പരിശോധിച്ചു. വെറും 52 ടിക്കറ്റുകൾക്ക്, API 4 ms-ൽ പ്രതികരിച്ചു. അത് വളരെ വേഗതയുള്ളതായി തോന്നാം. എന്നാൽ റെസ്‌പോൺസ് സൈസ് 354 KB ആയിരുന്നു.

SvelteKit റൂട്ട് പേലോഡും ഇതേ പ്രശ്നം കാണിച്ചു. ഒരു ലളിതമായ ലിസ്റ്റിന് ആ ഡാറ്റാ സൈസ് വളരെ വലുതായിരുന്നു.

പ്രശ്നം വേഗതയല്ലായിരുന്നു. പ്രശ്നം ഡാറ്റയുടെ ഭാരമായിരുന്നു.

മൊത്തം റെസ്‌പോൺസിന്റെ 80% വിവരണങ്ങൾ മാത്രമായിരുന്നു. ലിസ്റ്റ് എൻഡ്പോയിന്റ് ഓരോ ഐറ്റത്തിനും മുഴുവൻ Markdown വിവരണങ്ങളും തിരികെ നൽകുകയായിരുന്നു.

ഇതൊരു സാധാരണ കെണിയാണ്. ലിസ്റ്റ് എൻഡ്പോയിന്റ് ഒരു ഡീറ്റെയിൽ എൻഡ്പോയിന്റായി മാറിയിരുന്നു. ഒരു പേജിന് ലിസ്റ്റ് ആവശ്യമുള്ളപ്പോഴെല്ലാം, അത് ഉപയോഗിക്കാത്ത ഡാറ്റയ്ക്കായി വലിയ വില നൽകേണ്ടി വന്നു.

UI ഉപയോഗമല്ല പേലോഡ് നിശ്ചയിക്കുന്നത്. ലോഡർ റിട്ടേൺ ഷേപ്പ് ആണ് അത് നിശ്ചയിക്കുന്നത്.

നിങ്ങളുടെ ലോഡർ ഒരു ഫുൾ ഒബ്‌ജക്റ്റ് റിട്ടേൺ ചെയ്യുന്നുണ്ടെങ്കിൽ, SvelteKit ആ മുഴുവൻ ഒബ്‌ജക്റ്റിനെയും റൂട്ട് ഡാറ്റയായി സീരിയലൈസ് ചെയ്യുന്നു. നിങ്ങൾ ഒരു ഫീൽഡ് റെൻഡർ ചെയ്യുന്നില്ലെങ്കിൽ പോലും, അത് നെറ്റ്‌വർക്കിലൂടെ കൈമാറ്റം ചെയ്യപ്പെടുന്നു.

സമ്മറി ഡാറ്റയെയും ഡീറ്റെയിൽ ഡാറ്റയെയും വേർതിരിച്ചുകൊണ്ട് ഞാൻ ഇത് പരിഹരിച്ചു.

ഞാൻ രണ്ട് വ്യത്യസ്ത കോൺട്രാക്റ്റുകൾ നിർമ്മിച്ചു:

• സമ്മറികൾക്കായി ഒരു ലിസ്റ്റ് കോൺട്രാക്റ്റ് (ID, title, status, dates). • പൂർണ്ണമായ വിവരങ്ങൾക്കായി ഒരു ഡീറ്റെയിൽ കോൺട്രാക്റ്റ് (descriptions, commands).

ഞാൻ API-യെ രണ്ട് എൻഡ്പോയിന്റുകളായി വിഭജിച്ചു:

  • GET /features (സമ്മറികൾ നൽകുന്നു)
  • GET /features/:id (ഒരു പൂർണ്ണമായ ഡീറ്റെയിൽ നൽകുന്നു)

ഫ്രണ്ട്‌എൻഡ് പ്രവർത്തിക്കുന്ന രീതിയും ഞാൻ മാറ്റി. ഇപ്പോൾ, ആപ്പ് സമ്മറി ഡാറ്റ ഉപയോഗിച്ച് ലിസ്റ്റ് ഉടൻ തന്നെ റെൻഡർ ചെയ്യുന്നു. നിങ്ങൾ ഒരു ടിക്കറ്റിൽ ക്ലിക്ക് ചെയ്യുമ്പോൾ, ആപ്പ് ഒരു ഷെൽ കാണിക്കുകയും പശ്ചാത്തലത്തിൽ ഡീറ്റെയിൽ ഡാറ്റ ശേഖരിക്കുകയും ചെയ്യുന്നു.

ഫലങ്ങൾ വളരെ വലുതായിരുന്നു:

• Feature list API: 89.6% കുറവ് • Tickets route data: 91.4% കുറവ് • OpenSpec docs API: 98.9% കുറവ്

ഡാറ്റാബേസ് എപ്പോഴും വേഗതയുള്ളതായിരുന്നു. API-യും പേജും തമ്മിലുള്ള ഡാറ്റാ കോൺട്രാക്റ്റായിരുന്നു യഥാർത്ഥ തടസ്സം.

ലിസ്റ്റുകൾ കൂടുതലുള്ള ആപ്പുകൾക്കുള്ള പാഠങ്ങൾ:

  • റെസ്‌പോൺസ് സമയം മാത്രമല്ല, റെസ്‌പോൺസ് സൈസും അളക്കുക.
  • ലിസ്റ്റ്, ഡീറ്റെയിൽ പേലോഡുകളെ വ്യത്യസ്തമായി പരിഗണിക്കുക.
  • ലിസ്റ്റ് വ്യൂവിൽ ഒരിക്കലും വലിയ ടെക്സ്റ്റ് ഫീൽഡുകൾ ഉൾപ്പെടുത്തരുത്.
  • നിങ്ങളുടെ SSR ലോഡർ യഥാർത്ഥത്തിൽ എന്താണ് സീരിയലൈസ് ചെയ്യുന്നത് എന്ന് പരിശോധിക്കുക.
  • ഡീറ്റെയിൽ ഡാറ്റ ലേസി-ലോഡ് ചെയ്യുക, എന്നാൽ UI ഷെൽ ഉടൻ തന്നെ കാണിക്കുക.
  • വലിയൊരു പേലോഡിനെ മറയ്ക്കാൻ ഒരു ലോഡിംഗ് സ്പിന്നർ ഉപയോഗിക്കരുത്.

വേഗതയേറിയ ഒരു ക്വറി കൊണ്ട് മാത്രം ഒരു പേജ് വേഗതയേറിയതാകുമെന്ന് ഉറപ്പില്ല.

ഉറവിടം: https://dev.to/ahikmah/my-api-responded-in-4-ms-but-navigation-still-felt-slow-1hk8