Inefficient queries when moving from INFLUXQL to FLUX

,
1

Hi there,
We have some problems with performance after migrating our continuous queries(InfluxQl) to tasks(FluxQl) they are going from an average speed of 10 seconds to over 5 minutes.
These tasks are ran every 2 minutes, I was hoping you would have some answers as to why they have slowed down so massively.

from(bucket: “mondoenergy/default”)
|> range(start: -24h2m)
|> filter(
fn: (r) =>
r._measurement == “rawData” and r._field == “attributeValue” and r.attributeId
==
“57664”,
)
|> aggregateWindow(fn: last, every: 1d, offset: -10h, timeSrc: “_start”)
|> difference()
|> set(key: “_measurement”, value: “DailyAccumulation”)
|> set(key: “_field”, value: “import”)
|> drop(columns: [“attributeId”])
|> filter(fn: (r) => r._value >= 0 and exists r._value)
|> to(bucket: “mondoenergy/default”)

The v1 query

RESAMPLE EVERY 2m FOR 26h BEGIN SELECT last(attributeValue) - first(attributeValue) AS import INTO mondoenergy.“default”.DailyAccumulation FROM mondoenergy.“default”.rawData WHERE attributeId = ‘57664’ GROUPBY time(1d, -10h), deviceId, endpointId END

Note: We did swap from using FIRST - LAST to the difference between 2 days. But we have tested and it is the aggregateWindow function that is chewing up all the time.

6:08

Running the old query on the influx box using the /query endpoint gives us roughly the same response time on v1 vs v2

SELECT last(attributeValue) - first(attributeValue) AS import INTO mondoenergy.“default”.DailyAccumulation FROM mondoenergy.“default”.rawData WHERE attributeId = ‘57664’ GROUPBY time(1d, -10h), deviceId, endpointId

2

Hello @mrusmondo,
If you’re only querying data for the last 24 hours, and aggregating every 1d, do you need the aggregateWindow? Can you just run the task every day and use the

function for the offset? I wonder if that would help.

3

The purpose of this query is to get the difference between the start and end of a day’s data.

The reason we have the offset is because our time is stored in UTC, but we want the day start / end to be for the timezone of AEST.

Not sure how timeShift would help in this scenario. Do you have any other suggestions? :slight_smile: