Baserow 1.28 Performance degradation on API calls

[kezza]

How have you self-hosted Baserow.

Render

What are the specs of the service or server you are using to host Baserow.

Web Service: 16 GB + 4 CPU’s
DB: 8 GB + 4 CPU’s

Which version of Baserow are you using.

1.28.0

How have you configured your self-hosted installation?

Pro max for both DB and Web Service

What commands if any did you use to start your Baserow server?

n/a

Describe the problem

I have upgraded from 1.25.2 → 1.28.0 (latest) with the hope we would see speed increases. UI seems rapid with the changed env variables to supplement… I am however seeing extremely slow speeds on the API calls. e.g. a table with 972 rows (two calls based on my env config is taking a total of 16-20 secs to return). Rollback to 1.25.2 and its rapid on the API and average on the UI to be completely clear. I think I am missing something from env variables as since upgrading it seems to not be maxing out on my available resource on the webservice, previously I was 75%-90% CPU and RAM and now its very low as shown in screenshot. I can upgrade resources but wanted to upgrade first to see if we could sneak any improvements.

I am now stuck as when I try to downgrade back with rollback in render it fails to load the UI with 500 on /applications and see login but as soon as login success I receive internal server errors (I would of course rather not move back but the API is now unusable given the speed decrease since upgrading). Guessing maybe something changed by upgrading which is not backwards compatible (although even when I rollback to be clear, my python API calls still succeed and are significantly faster on 1.25.2)

Anyways I am now back at 1.28.0 and seeing rapid UI with the env variable changes around workers and now am seeing the extremely slow speeds mentioned above on my API calls.

Describe, step by step, how to reproduce the error or problem you are encountering.

n/a

Provide screenshots or include share links showing:

How many rows in total do you have in your Baserow tables?

In the target table 2k but on the view reading from for speed testing its 972 rows.

[kezza]

Just as an update on this, the UI is significantly faster since upgrading so its clear to me this issue seems to be isolated to API end only

[davide]

Hey @kezza,

I’m sorry you’re having issues with Baserow, but the slowdown you’re experiencing is very unusual. The new version should be faster, not slower. We haven’t observed a difference like the one you reported in any cases so far.

Could you please provide more information about the slower endpoints? It would be helpful if you could share your backend logs or demonstrate the time taken for the requests in some way.

Feel free to send them to me privately if you prefer.

[kezza]

@davide I have managed to solve the issue, it was down to Render. You are correct its tons faster than the older versions, really great work!

I did have a question however, on the latest version I am seeing rising Memory usage on my web service instance in render, as you can see over the past few days, its slowly been creeping, indicating some form of memory leak or lack of optimisiation, most likely on my end Happy to upgrade to a slightly higher plan however this is with 16GB memory.

Could you advise on any other environment variables you would recommend to optimise, we are scaling drastically over the coming weeks and conscious interdepencies and linked columns will restrict our read and write latency.

Thank you in advance and keep up the great work.

Below diagrams (top is Memory, bottom is CPU)

[davide]

Hi @kezza,

sorry for the delay. The framework we’re using in the backend is quite resource-intensive in terms of memory.

The first 2 important variables that come to my mind are:

• BASEROW_AMOUNT_OF_WORKERS
• BASEROW_AMOUNT_OF_GUNICORN_WORKERS

You can find the description of these and all other variables here: Configuring Baserow