#Gradual latency increase on thumbnails endpoint with format=JPEG

1 messages · Page 1 of 1 (latest)

vivid driftBOT
#

:wave: Hey @distant shuttle,

Thanks for reaching out to us. Please follow the recommended actions below; this will help us be more effective in our support effort and leave more time for building Immich immich.

References

Checklist

  1. :blue_square: I have verified I'm on the latest release(note that mobile app releases may take some time).
  2. :blue_square: I have read applicable release notes.
  3. :blue_square: I have reviewed the FAQs for known issues.
  4. :blue_square: I have reviewed Github for known issues.
  5. :blue_square: I have tried accessing Immich via local ip (without a custom reverse proxy).
  6. :blue_square: I have uploaded the relevant logs, docker compose, and .env files using the buttons below or the /upload command.
  7. :blue_square: I have tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable

(an item can be marked as "complete" by reacting with the appropriate number)

If this ticket can be closed you can use the /close command, and re-open it later if needed.

valid tartan
#

I tried on firefox + chrome, browsing the main timeline, an album timeline and from the asset-viewer

#

And I can't reproduce your issue

#

Can you share your timings ?

#

Oh my bad I thought you were speaking about the timelines

#

Mmmh, I don't have enough albums to test it properly

#

How many albums do you have ?

#

mmmh I guess it's because of the image preload

# 
<AlbumCard
  preload={index < 20}
  {album}
  on:showalbumcontextmenu={(e) => showAlbumContextMenu(e.detail, album)}
/>
#

Weird, in theory it shouldn't affect the timings but it does in practice

#

Ok, I think I found our culprit

#

We're loading the jpeg thumbnail which is a lot larger than the webp thumbnail

#

With the thumbnail delay, all thumbs have the same delay

#

But, even with the jpeg thumb, I don't have the content download delay you have

vapid root
#

I don't think this is unexpected. The large jpegs are probably hitting some bottleneck.

quasi ginkgo
#

What sort of storage are you using @distant shuttle?

valid tartan
#

I'm wondering if it's not a nodejs issue

#

Thumbnails larger than 800 KB take significantly longer to load

quasi ginkgo
#

Seems solid

#

Just wanted to rule out a storage issue :)

valid tartan
#

One easy solution would be to use the webp thumbnail for the album cover

quasi ginkgo
#

Time to rewrite Immich in Elixir :P

desert hatch
#

Bun 🎉

quasi ginkgo
#

Elixir runs on the BEAM as well and is much more pleasant to write ;)

valid tartan
#

On your timeline ?

#

Or still when browsing the album list ?

valid tartan
#

With a custom patch ?

#

Did you tweak the code to load album covers in webp ?

#

What invokes these webp requests?

vapid root
near tree
#

I read somewhere that Chrome limits concurrent requests to a certain domain to 6 and requests above this get put into a queue. I wonder if that could be affecting the latency increase

quasi ginkgo
#

But it's worth trying on firefox anyways

near tree
#

I haven’t tested this specific issue, but in general Immich on Firefox is a lot more stable for me with network stuff. On Chrome it sometimes just hangs and I have to close the tab, but that never happens with Firefox

near tree
#

@distant shuttle To the extent that this is a node issue, you can try Bun by setting the immich-server image to ghcr.io/immich-app/immich-server:pr-7564 . Some pages might not work but the timeline etc. should

near tree
#

Well that's weird 😅 , glad you managed to fix it though

#

The stalling increasing over time is really interesting

#

There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.
So at least when http2 is disabled there does seem to be queueing behavior

#

Right, I think this is just another step in debugging what's going on

#

btw is the behavior in firefox the same?

#

While using HTTP2, request are stalled. Even though 6 sockets/HTTP2 sessions are opened by chrome and seem to be in idle state, chrome is trying to open new socket connections for same domain.
This is causing requests to be stuck in pending state.
Ideally, chrome should either close the idle sessions or continue using the stream by already opened http2 sessions. It works as expected on Firefox.

#

But supposedly it's fixed in 122 and that's the version I'm using, so I'm not sure if it isn't actually fixed or if it's related but not the same issue

quasi ginkgo
#

It's worth downloading ff to try

vapid root
near tree
#

Oh that makes sense. I probably should have based the branch on 1.97