1

Following up on the previous “teaser” post, we open-sourced the project! Check it out at our projects page where you’ll find all the relevant links (GitHub, documentation).

From our development experience, I think that some improvements should make it to the core project, which I’d like to bring to the community’s consideration here:

Declarative API using swagger (OpenAPI)

To develop a client that was stable and easier to expand than the rest of the open-source client projects we’ve found (including the redash-toolbelt client) we started to define Redash’s API using Swagger.

I think that moving this into the core project, completing it, and using something like swagger-codegen to base the server off of would make the experience of working with Redash programmatically better.

The file is open source and under the same license, so Redash maintainers can just grab it - we’d also love to collaborate on it and advise if needed.

Perhaps time to sunset redash-toolbelt?

The official client for Redash - redash-toolbelt - has a bunch of useful utilities and should probably stay around, but as an official client, it’s missing too much functionality.

Pagination

We’ve had some peculiar issues with the Pagination API which weren’t super-reproducible, but it seems like it ignores the “page size” parameter from the API. Is anyone experiencing similar issues?

Stress testing

We’re running a self-hosted instance of Redash on K8s using a helm chart we developed based on the community one. Since Redash has a few DBs and services that make up its deployment, some stress problems don’t manifest in Redash but rather in Redis or Postgres. Specifically, when trying to add ~100 queries in a for loop, the server starts failing to add them, with Redis throwing errors and the server getting exceptions.

For now, this is our workaround (with many internal parts omitted):

func (dashboardBootstrapper *DashboardBootstrapper) setUpWorkspaceTilesInRedash(dataSource *redash_models.DataSource,
	workspaceTilesMapPtr map[uuid.UUID][]*TileConfiguration) {
	for workspace, tilesInWorkspace := range workspaceTilesMapPtr {
		for i, tileConfig := range tilesInWorkspace {
			// [OMITTED]...

			// NOTE: Here be dragons. Our K8s Redash instance fails inserting many queries
			// probably due to stress on its Redis. This is a temporary (?) fix for that.
			// The default time is depressingly long, but this is in order to be on the
			// safe side.
			time.Sleep(defaultSleepBetweenQueryAdditions)

			// [OMITTED]...
			newQuery, err := queries.NewQuery(
				queryName,
				string(queryOpt),				
				tile.Description,
				query, 0, 
				dataSourceID, 
				tile.Schedule.Interval, 
				queriesVersion, 
				isDraft)

			newQuery, err = dashboardBootstrapper.redashClient.Queries.Add(newQuery)

So this some some “ground research” performance testing results for Redash. We solved it - as you see - using a time.Sleep call, but I think perhaps the server can handle load or at least communicate load-based failures better so that the users can “back off” until everything’s operational again.

2

With those failures to insert, is there any chance the instances didn’t have the rate limit disabled?

eg:

That can lead to failures that are pretty “WTF?”, unless you’re aware of it. :smile:

1 Like