In an effort to limit the system usage of your data source, Chartio has two controls built into the app: Rate Limiter and Max Query Duration. In the backend of Chartio, the Rate Limiter can be set to only allow a set number of queries to be sent to the data source to even get to a point where the Max Query Duration has an impact. This is meant to limit the number of queries that are waiting in your data source’s queue at any given time. This could be particularly important with a data source that limits the number of concurrent query connections in your query queue, like Amazon Redshift.
It is important to try to find a balance between how many connections your WLM’s Client Queue has for Chartio and how many queries you are sending it at once. Drawbacks can come from setting the Rate Limiter too low, as well as too high. If the Rate Limiter is too low then there will be a lot of queries waiting to complete and they will only wait for a certain period until Chartio cancels the queries; too high and you may be using up too many concurrent connections at one time and this may cause performance degradation in your Redshift instance. We allow queries to wait for 3+ minutes, apply an exponential backoff algorithm which has the query retry for an open slot to run in.
For example, Chartio is sending ten queries. These ten queries go into Chartio’s Rate Limiter which is set to five. Only five queries get passed through Redshift’s queue and Chartio will wait up to five minutes for the query to complete. The remaining five queries are waiting in the queue for an open slot due to the rate limit. From the Redshift queue only three queries are being passed to the server if your Redshift has three connections; two queries are left in the Redshift queue.
The Rate Limit is controlled in Chartio’s backend so after figuring out the best balance for you, you can contact Chartio Support about setting the Rate Limit for your data source.