Varför känns Immich mindre responsivt i olika klienter?

Immich kan kännas långsammare på en klient eftersom rendering på klientsidan, bildavkodning, cachetillstånd och nätverksväg kräver ytterligare arbete efter att servern har svarat.

En familj kan bläddra i samma bibliotek från en webbläsare på en stationär dator, en äldre telefon och en surfplatta, medan Immich-servern, lagringen och databasen förblir oförändrade. En enhet kan ändå öppna tidslinjer eller förhandsvisningar senare, eftersom begäran från början till slut även omfattar arbete utanför servern. Den användbara jämförelsen är därför serverns svarstid kontra den extra tid varje klient lägger på att ta emot, avkoda, cacha och rita upp resultatet.

Klienten ändrar arbetet efter Immichs svar

En Immich-begäran avslutas inte när servern har förberett JSON, en URL till en miniatyrbild eller ett bildsvar. Klienten måste fortfarande bearbeta svaret, uppdatera gränssnittet, schemalägga rendering och reagera på användarinmatning. En snabb server kan därför samexistera med en klient som känns trög när enheten eller webbläsaren lägger extra tid på att omvandla returnerade data till en synlig och interaktiv skärm.

Den skillnaden är särskilt viktig i webbläsare, där JavaScript, händelsehantering, stilberäkning, layout och en stor del av uppritningen konkurrerar om arbete på huvudtråden. Om en äldre telefon eller en belastad webbläsare håller tråden upptagen längre kan tryckningar och rullning släpa efter, även om Immich-API:t blev klart ungefär samtidigt som på en snabbare stationär dator.

Det är därför en jämförelse som bara tittar på serverns CPU eller databasens svarstid missar en del av upplevelsen. ZimaSpaces diskussion om inbyggda klienter och webbläsarklienter visar samma systemprincip: en backend kan leverera data till olika körvägar på klientsidan. För Immich är den första diagnostiska frågan om fördröjningen uppstår innan svaret anländer eller efter att klienten börjar bearbeta det.

Bildrendering kan få snabba svar att kännas långsamma

Skillnaden mellan klienter blir tydligare när man bläddrar bland foton, eftersom ett galleri inte bara består av text och API-metadata. En klient kan begära många miniatyrbilder eller en större förhandsvisning, behålla vissa i minnet, avkoda komprimerade bilddata, skala dem efter visningsområdet och sammanställa flera bilder medan användaren fortsätter att rulla. Mängden och tidpunkten för detta lokala arbete kan skilja sig kraftigt mellan enheter, även när de begär samma Immich-tillgång.

Komprimerade format som JPEG och WebP måste genomgå bildavkodning innan pixlarna kan visas. Snabbare processorer, bättre optimerade avkodare, mer tillgängligt minne och olika webbläsarmotorer kan förkorta detta steg. På en svagare klient kan nätverket bli klart först, medan avkodning och uppritning blir det som användaren faktiskt väntar på.

Den praktiska följden är att en större eller skarpare förhandsvisning inte är gratis bara för att servern snabbt kan skapa den. Bilder med högre upplösning kräver mer avkodat pixelminne samt mer arbete för skalning och uppritning. Om en klient främst blir långsam när fullständiga förhandsvisningar öppnas eller när man snabbt rullar genom täta tidslinjer, medan enkla metadatasidor fortfarande är responsiva, är bildrenderingsvägen en starkare förklaring än en kapacitetsbegränsning i hela servern.

Varmt cachetillstånd ändrar hastigheten vid återbesök

En klient som redan har bläddrat i ett album kan återanvända miniatyrbilder, skript, metadata eller avkodade resurser som en ny klient fortfarande måste hämta och bearbeta. Det gör det andra varvet kortare, men betyder inte att servern plötsligt fick mer kapacitet. Det betyder att en del av begärans väg försvann eftersom klienten började i ett varmare tillstånd än vid det första varvet.

Verkliga webbläsarstudier visar att cache-träffrekvensen varierar mellan webbläsare, versioner, enheter och tidpunkter. De exakta Facebook-procentsiffrorna är inget Immich-riktmärke, men mekanismen är viktig: två klienter kan nå samma server med olika lokal cachehistorik. En stationär webbläsare med varm cache kan därför verka betydligt mer responsiv än en nyinstallerad telefonapp utan att det bevisar att någon av klienterna i sig är snabbare.

Cache skapar också missvisande före- och eftertester. Om samma album uppdateras flera gånger kan hämtning och bearbetning försvinna från senare körningar, så den snabbaste körningen mäter ofta återanvändning snarare än en representativ familjebelastning. Om målet är att jämföra klienter bör du registrera både en kall eller nyöppnad väg och en upprepad väg. Skillnaden mellan dem är i sig användbara bevis på hur mycket varje klient är beroende av lokal återanvändning.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

När klients skillnader inte längre förklarar fördröjningen

Skillnader mellan klienter slutar vara den främsta förklaringen när flera i övrigt olika klienter blir långsammare samtidigt under samma belastning. Om en webbläsare på en stationär dator, en telefon och en surfplatta alla väntar längre på tidslinjedata eller förhandsvisningar samtidigt som serverns CPU, lagringens svarstid, databasaktivitet eller nätverksutnyttjande ökar, har den gemensamma infrastrukturen blivit en mer sannolik begränsning för responsiviteten än någon enskild klientimplementation.

Ändpunktsmätning bör omfatta mer än den komponent som är enklast att mäta. En latensanalys från Datadog visar att svarstid tur och retur kan omfatta nätverksöverföring, proxyservrar, anslutningspooler och avkodning i applikationen utanför själva databasen. Samma princip gäller för Immich: ett friskt databasmått kan inte utesluta fördröjning någon annanstans mellan begärans början och ett uppritat resultat.

Ett användbart gränstest är symmetri. Om bara en klient är långsam medan en annan på samma lokala nätverk och i samma album förblir snabb, bör klientkörning, cachelagring eller lokalt nätverk väga tyngre i bedömningen. Om alla klienter passerar samma latensgräns ungefär samtidigt, särskilt under import, generering av miniatyrbilder, säkerhetskopiering eller annan aktivitet på värden, har förklaringen flyttats från klientvariation mot en gemensam begränsning i server, lagring eller nätverk.

Använd ett kontrollerat klienttest för att hitta gränsen

Välj ett representativt album och håll serverversion, nätverksplats, konto, bildmängd och bakgrundsjobbens tillstånd konstanta. Testa varje klient en i taget och registrera tre observerbara tider: den inledande tidslinjeladdningen, öppningen av samma stora förhandsvisning och en snabb rullning genom ett fastställt fotointervall. Notera också om servern visar en resursökning under varje körning, eftersom en klientjämförelse är ogiltig om backend-belastningen ändras mellan mätningarna.

Kör varje klient en gång från ett medvetet kallt tillstånd och sedan igen direkt efteråt. Prestandatester skiljer vanligtvis mellan resultat för första visningen och upprepad visning, eftersom fyllda cacher tar bort arbete från senare begäranden. För Immich visar skillnaden från kallt till varmt tillstånd hur mycket återanvändning förändrar upplevelsen, medan skillnaden mellan klienter under samma cacheförhållanden synliggör sådant som mer sannolikt är lokalt för enheten eller applikationen.

Betrakta en skillnad som klientspecifik först när den upprepas i minst tre körningar och den snabbare klienten fortsätter att vara snabbare medan server- och nätverksförhållandena förblir jämförbara. Om alla klienter försämras samtidigt bör du sluta finjustera klienten och undersöka den gemensamma vägen. Om endast bildintensiva åtgärder skiljer sig åt bör du fokusera på avkodning och rendering. Om skillnaden bara syns vid den första körningen är cachetillstånd – inte hållbar serverkapacitet – den mer hållbara slutsatsen.