Slow timeline requests

#1

Hello, everybody,

I have a problem with my instance. Sometimes the refresh of the timeline is very slow and even fails sometimes. Can one of you help me with the troubleshooting? I can’t find anything conspicuous in the logs.

Many greetings

Edit:
I found something in the logs after all:

[httplog] GET https://mstdn.jp/users/miku_cdP#main-key completed with status code 410 in 137.4732386340038 seconds

Does that look familiar to anyone?

#2

Is it just a request to ask for data of some user that is now deleted?

#3

With a timeline, can you check what’s up with your node streaming process?

#4

I believe this occurs with both existing and deleted users.

I’m sorry for the stupid question, but how can I check the node streaming process? :grimacing:

#5

There are no stupid questions.

I have a process running process like this:

76513  5- IJ     0:00.87 /usr/local/bin/node ./streaming/index.js

You can start it my hand or together with your system, there is some info about it in the Mastodon Production Guide (search for “streaming”).

There should be 3 components running: puma main Mastodon engine, sidekiq workers (both in Ruby) and a node streaming service. Plus there is usually a webserver such as nginx on top of this.

#6

I have the three components. I had set up the streaming endpoint incorrectly, but it works now.

I think I found the problem. When the search api (/api/v2/search?q=https://mastodonten.de/@username&resolve=true) is called, I get the error message “503 Remote data could not be fetched”.
Any idea why that might be happening?

#7

So is the “slow timeline requests” problem solved now?

For the search, I’d check the Ruby puma service log.

#8

The problem with the slow timeline is partially solved. All 5-10 requests are still slow.

Search: I can’t find anything suspicious in the logs. Is it enough if I set the RAILS_LOG_LEVEL to debug?