#Cold start: 3s delay before server connection on local network (Android app)

1 messages · Page 1 of 1 (latest)

tiny marlin
#

When using the TraceArr Android app, on a fresh start (“cold start”), it consistently takes ~3 seconds before the app connects to the server.

On the web UI, connecting/loading is almost instant. This is all local network (LAN) traffic.

On app startup, the Android app should connect to the server nearly instantly on the local network (similar to web UI). Im also using Tautulli app and that is instantly. Same with plex dash (and thats even through internet)

Its not that i cant wait 3 seconds but it feels unneccasary. Something is not right

terse tigerBOT
# tiny marlin When using the TraceArr Android app, on a fresh start (“cold start”), it consist...

Thanks for opening a support thread!
Please include the following so we can help:

Required Information

• Tracearr version
• Environment (Docker, LXC, Unraid, etc.)
• Docker compose file
• Logs (pastebin.com) or screenshots

Describe The Issue

• Expected behavior
• Actual behavior
• Steps to reproduce

Read The Docs

Docs · Logs · FAQ

tiny marlin
#

Supervised v1.4.20-beta3. I think my experience with the delay of a few seconds is "normal" behavior. But i dont think its a good experience.

#

Opening the tracearr through my mobile browser is instantly. So why the delay when using the app?

#

Be aware this issue is when doing a cold app start . Not running in background

onyx mural
#

do you have External URL set?

#

what url did you use to access tracearr when you clicked generate qr?

#

can you do a screen recording showing the delay?

tiny marlin
#

Internal url/local ip. I can make a screen recording but its easy to reproduce. Close TraceArr from the background or restart your phone and start the app. Its around 2 or 3 seconds before you see any details

onyx mural
#

that unfortunately answers none of the questions i asked

tiny marlin
#

Oke

#

I think it answer all

#

External url no

#

192.168.2.252. My internal ip

#

To be precise

#

Look if you say we cant reproduce im fine. Then its on me

onyx mural
#

i didnt say that

#

i'm just asking questions

tiny marlin
#

I think its the handshake duration

onyx mural
#

if you could do a screen recording, i can compare with mine.

tiny marlin
#

Oke. Let me figuren it out 😀

#

One moment

#

Hope this helps

onyx mural
#

thanks, i'll take a look. it wont be right now as its close to my bed time

tiny marlin
#

At least i know how to make screen records

#

No issue, takes your time

#

Not urgent

onyx mural
#

can you tell me your android OS ver?

tiny marlin
#

16

#

Samsung

onyx mural
#

thanks

tiny marlin
#

No issue. Thanks for your help

#

By the way; love your application. Well done

gritty quiver
#

I mean it takes 1/4 that amount of time on Samsung s8

#

(Hardware from 2017)

onyx mural
#

my splash screen takes 1 second less, and my app opens up to data already loaded on the dashboard. OP's video shows it sitting there "Loading..." after a 3 second splash screen. something isnt right on his side

gritty quiver
#

Yeah I’d say slow internet, server or phone

onyx mural
#

local API shuldnt take that long to fetch data

gritty quiver
#

But on a 9 year old phone it’s way faster

onyx mural
#

i suspected maybe dns lookup time, but hes using an IP address he said

gritty quiver
#

I mean this is not the launch experience on any test device

onyx mural
#

it really could be anything from network issues, reverse proxies, under resourced image,

gritty quiver
#

If we spend debugging it it’s ultimately going to be finding issues in your server, phone, or network

#

But the app is not the problem here

#

Hell it could be launching from an SD card

tiny marlin
#

The thing is, it would also be slow using a browser and that isnt the case. Its instant when using a browser. I have a samsung S24 ultra

onyx mural
#

not necessarily, there could be something different between devices

tiny marlin
#

Let me readd the device again. Just to be sure

onyx mural
#

like where is the docker container actually hosted

#

on the same PC you are browsing to it from?

#

reverse proxies in the way? did you set external_url? or a url prefix?

#

whats your wifi like? dns? routing?

#

there are just so many variables

#

we have established its not a problem with the mobile app itself, but rather your environment

#

if it were the app, we could reproduce it

#

if you can help us reproduce it, we can look at it further

tiny marlin
#

Its all on the local network.

#

Another issue

#

I just revoked access

#

But i still have access with my app

onyx mural
#

that should not be possible

tiny marlin
#

I know

onyx mural
#

are you sure the app is pointing to that instance of tracearr?

tiny marlin
#

I refreshed a couple of time. I only have one instance running

onyx mural
#

you can always just logout from the app and it will forget it

#

top left menu -> settings -> Disconnect

tiny marlin
#

Yeah i know. But this is a bug, so its more for you guys 😀

#

Even a cold app boot would still make connection

onyx mural
#

in the web app, did you hit Revoke All, or the trash can icon next to the device?

tiny marlin
#

Revoke all

#

Im a developer myself. Not that this mean anything, but im not a default user

onyx mural
#

i can actually reproduce that one. its probably the JWT expiry, we can look into that one

#

that is obviously separate to your slowness issue

tiny marlin
#

I will readd the device and renstal rhe app

#

Same. I really think you can reproduce it. If the app is in the background its fast. Instant connection. If you do a cold start (meaning kill the app from your background process) it takes 3 seconds.

#

So you know its really internal

onyx mural
#

i have tested it several times, using both internal url and a remote tracearr instance hosted in the US (im in EU). i cant reproduce your slowness

#

iv deleted the app, clean install, wiped data, killed it etc

tiny marlin
#

Oke then i dont know. If no other users has this issue then thats it then.

onyx mural
#

i'm just not sure what we can do if we cant reproduce it

tiny marlin
#

Nothing. Thats my rule also with my own app. If i cant reproduce it, i cant help 😀

#

Is there a way to enter debug mode in supervised?

#

Or a way to see incoming connections on application layer

onyx mural
#

you just need to set LOG_LEVEL=debug - for incoming connections that would be a docker thing

#

you would need some packet sniffer on the docker host

tiny marlin
#

oke i did. the good news is, its not the app. when i make a connection i see instantly the incoming traffic in tracearr.log and the app just wait for the data to retrieve. The best guess i can make is supervised loves much resources and the memory/cpu allocation thats managed by superviser itself is sometimes struggling. For your info: my docker containers are running on a synology with 20GB memory and all containers on SSD.

In short: sometimes superviser sent the data back fast, and sometimes not so fast.. so i need to check that out a little bit more, when i have time.

"level":30,"time":1772626409479,"pid":47,"hostname":"tracearr","serverId":"81c5bf4e-a399-4016-8953-6bec6def435d","dataLength":28,"firstItem":{"at":1772626408,"timespan":6,"hostCpuUtilization":12.366,"processCpuUtilization":0.458,"hostMemoryUtilization":35.301,"processMemoryUtilization":1.758},"msg":"Server statistics fetched"} {"level":30,"time":1772626409480,"pid":47,"hostname":"tracearr","reqId":"req-2v","res":{"statusCode":200},"responseTime":30.00639820098877,"msg":"request completed"} {"level":30,"time":1772626409675,"pid":47,"hostname":"tracearr","reqId":"req-2w","req":{"method":"GET","url":"/api/v1/sessions/active?serverId=81c5bf4e-a399-4016-8953-6bec6def435d","host":"192.168.2.152:3000","remoteAddress":"192.168.2.52","remotePort":50914},"msg":"incoming request"}

#

so ive limited memory usage on container level and the issue is fixed.. dont know why, perhaps its even luck. but it works

gritty quiver
tiny marlin
#

sure.
Server: Containers: 22 Running: 20 Paused: 0 Stopped: 2 Images: 185 Server Version: 24.0.2 Storage Driver: btrfs Btrfs: Logging Driver: db Cgroup Driver: cgroupfs Cgroup Version: 1 Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs db fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: io.containerd.runc.v2 runc Default Runtime: runc Init Binary: docker-init containerd version: fea6458b8abe502f6228eab2e5a6678fcb5c3fb0 runc version: 0320c58 init version: ed96d00 Security Options: apparmor Kernel Version: 4.4.302+ Operating System: Synology NAS (containerized) OSType: linux Architecture: x86_64 CPUs: 4 Total Memory: 19.39GiB Name: Pazzie ID: 7722cf1c-05fa-4b84-b4cd-5e3ce65b5984 Docker Root Dir: /volume2/@docker

#

tracearr: image: ghcr.io/connorgallopo/tracearr:supervised-next container_name: tracearr hostname: tracearr domainname: tracearr.lan shm_size: 256mb environment: - TZ=Europe/Amsterdam - LOG_LEVEL=info volumes: - /volume3/SSD1/docker/tracearr/postgres:/data/postgres - /volume3/SSD1/docker/tracearr/redis:/data/redis - /volume3/SSD1/docker/tracearr/data:/data/tracearr networks: macvlan-br0: ipv4_address: 192.168.2.152 restart: unless-stopped healthcheck: test: ["CMD", "curl", "-f", "http://127.0.0.1:3000/health"] interval: 30s timeout: 10s start_period: 60s retries: 3 logging: driver: db options: {}

#

Container tracearr "CapAdd": [ "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "MKNOD", "NET_BIND_SERVICE", "NET_RAW", "SETFCAP", "SETGID", "SETPCAP", "SETUID", "SYS_CHROOT" ],

onyx mural
#

Your domain name isn't right

#

Hostname shouldn't be part of domainname

gritty quiver
onyx mural
#

But that's just a side observation

gritty quiver
#

different:
shm_size
missing:
mem_limits and ulimits

we also always recommend the use of docker volumes if you decide to use the supervised compose

And on top of that - we note in our docs and the compose that the supervised is intended for Unraid. While you can use it on other bare metal hosts you should use the file without modification.

If you want to modify it the PG18 compose is the better path.

tiny marlin
#

Mem limits was manual added. And after that it works. But i will check the docs to see what more i can change, to represent the docs more

#

Shm size is also a good one

gritty quiver
#

Unless you are running Unraid (which you are not) using the compose you picked is explicitly not recomended

#

You ultimately went against the guidance - so if you are having performance issues thats most likely related to that initial decision to ignore the suggestions

tiny marlin
#

Oke noted.

gritty quiver
#

Otherwise look like everything here is solved - if you still are having issues (and have switched to a proper install) please dont hesitate to open another ticket