I do apologise, I run my tests to fast, the 'extra' parameter isn't working
with a FIND statement only with FETCH. I couldn't really reduce by a lot
using this method (from 70 - 80 seconds) to (40 - 50 seconds) to retrieve
the 14 last values of those series. I had to split my statement in 3 or 4
FETCH, as the labels keys are different for several classes.
Le jeudi 14 mai 2020 16:42:02 UTC+2, A. Hébert a écrit :
>
> Thanks for your proposal. Do you have an example for the 'extra'
> parameter? I couldn't make it work (only one series as result) on a Warp10
> 2.5.
> As a matter of fact this time I am really in the second case (I can't know
> the full set of labels only the id) and I really would like to be able to
> reduce the 10 seconds to FIND a single series.
>
> Le mardi 28 avril 2020 21:34:03 UTC+2, Mathias Herberts a écrit :
>>
>> Hi,
>>
>> assuming you know the classes of those 14 series you want to access, you
>> could very well use the same approach using the 'gts' parameter with a list
>> of GTS you build manually, i.e.:
>>
>> 'gts' [
>> NEWGTS 'class-1' RENAME { 'id' '42' } RELABEL
>> NEWGTS 'class-2' RENAME { 'id' '42' } RELABEL
>> ..
>> ]
>>
>> Of course you need to specify the full set of labels so this approach
>> will only work if you know what the labels are.
>>
>> Another approach, assuming you do not know what the labels are but you
>> know the class names, you could select the GTS using a single class name
>> then use the 'extra' parameter to specify the other 13 classes.
>>
>> On Monday, April 27, 2020 at 11:54:41 AM UTC+2, A. Hébert wrote:
>>>
>>> Hello Mathias,
>>>
>>> I am back again on this story of performance for queries due to the
>>> Index size.
>>>
>>> First of all, I wanted to say that in many use-cases the FETCH with the
>>> "gts" key improve a lot of query in our side.
>>>
>>> However we still have massive slow queries, for example when we want to
>>> compute a FIND on a specific label on one of our most large application.
>>> The selector query is '~.*{id=42}' and this queries takes more than 70
>>> seconds (server side). The FINDSTATS provides the following result
>>> "{"classes.estimate":14,"gts.estimate":14,"labelnames.estimate":13,"labelvalues.estimate":12,"error.rate":0.008125}".
>>>
>>>
>>>
>>> Even when setting one series name on the selector 'test{id=42}', we
>>> still get series than takes more than 10 seconds to be executed (server
>>> side).
>>>
>>> I would be to help to improve those queries. What can I look like to
>>> start with?
>>>
>>> Le mercredi 11 mars 2020 17:01:50 UTC+1, A. Hébert a écrit :
>>>>
>>>> For sure on a batch of hundred queries an average of 150ms, the best
>>>> resolved in only 28ms, and the worst in 1s
>>>>
>>>> Le mercredi 11 mars 2020 16:52:34 UTC+1, Mathias Herberts a écrit :
>>>>>
>>>>> Did you see an improvement in terms of performance?
>>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups "Warp
10 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/warp10-users/d311df49-2b9e-47a0-bbd6-e8a586674fa6%40googlegroups.com.
