very slow dashboard with less than 10k conferences in a day

[vkruoso]

If you have around 10k conferences, the dashboard fails to open as the API endpoint suffers to process all the data. Also, it seems that a lot of data is transferred to the browser in the initial dashboard load.

While the dashboard load call is running, the python API fails to ingest new data from current calls, reducing the performance for parallel workloads.

[onel]

Thanks for bringing this up. It's true that api might not be optimized for this case.

The FE might be able to handle it, and display the graphs but if I understand correctly the API struggles to build the response for the request?
Are you also using redis?
How many instances of API are you running?
What are the specs? For that many conferences I'm thinking you need a beefier machine

[vkruoso]

Thanks for the response. I'm using the default docker-compose deployment with redis and postgres containers. I'm running just one instance of the API, but I would assume running more would not be beneficial in this case as the call is not able to use more that one CPU to handle the request. The call that is slow is the v1/conferences?appId=xxxx. The response size is also really big for the initial dashboard load. Below the calls:

This is from one day of a small operation, so I guess it becomes unusable after some days.

[onel]

Hmm. We're not seeing this in production so it makes me think if it's something with the open source code.
First thing I see from the screenshot is that the request to /conferences are reaching the 30s timeout that is default for gunicorn.
Right now in docker compose there is none specified so it defaults to 30s.

Change the command for the api container into this

command: "gunicorn api.wsgi:application --bind 0.0.0.0:8081 --log-level debug --reload --timeout 300"

This should help with the timeout. After that we can talk about the data coming in.

[vkruoso]

Thanks for the info. Below are more details: