[openstack-dev] [yaql] Yaql validating performance
lương hữu tuấn
tuantuluong at gmail.com
Mon Jan 23 14:44:44 UTC 2017
Hi guys,
I am provide some information about the result of testing YAQL performance
on my devstack stable/newton with RAM of 6GB. The workflow i created is
below:
#############################################
input:
- size
- number_of_handovers
tasks:
generate_input:
action: std.javascript
input:
context:
size: <% $.size %>
script: |
result = {}
for(i=0; i < $.size; i++) {
result["key_" + i] = {
"alma": "korte"
}
}
return result
publish:
data: <% task(generate_input).result %>
on-success:
- process
process:
action: std.echo
input:
output: <% $.data %>
publish:
data: <% task(process).result %>
number_of_handovers: <% $.number_of_handovers - 1 %>
on-success:
- process: <% $.number_of_handovers > 0 %>
##################################################
I test with the size is 10000 and the number_of_handover is 50. The result
shows out that time for validating the <% $.data %> is quite long. I do not
know this time is acceptable but imagine that in our use case, the value of
$.data could be a large size. Couple of log file is below:
INFO mistral.expressions.yaql_expression.InlineYAQLEvaluator [-] Function
evaluate finished in 11262.710 ms
INFO mistral.expressions.yaql_expression.InlineYAQLEvaluator [-] Function
evaluate finished in 8146.324 ms
......
The average value is around 10s each time of valuating.
Br,
Tuan
On Mon, Jan 23, 2017 at 11:48 AM, lương hữu tuấn <tuantuluong at gmail.com>
wrote:
> Hi Renat,
>
> For more details, i will go to check on the CBAM machine and hope it is
> not deleted yet since we have done it for around a week.
> Another thing is Jinja2 showed us that it run 2-3 times faster with the
> same test with YAQL. More information i will also provide it later.
>
> Br,
>
> Tuan
>
> On Mon, Jan 23, 2017 at 8:32 AM, Renat Akhmerov <renat.akhmerov at gmail.com>
> wrote:
>
>> Tuan,
>>
>> I don’t think that Jinja is something that Kirill is responsible for.
>> It’s just a coincidence that we in Mistral support both YAQL and Jinja. The
>> latter has been requested by many people so we finally did it.
>>
>> As far as performance, could you please provide some numbers? When you
>> say “takes a lot of time” how much time is it? For what kind of input? Why
>> do you think it is slow? What are your expectations?Provide as much info as
>> possible. After that we can ask YAQL authors to comment and help if we
>> realize that the problem really exists.
>>
>> I’m interested in this too since I’m always looking for ways to speed
>> Mistral up.
>>
>> Thanks
>>
>> Renat Akhmerov
>> @Nokia
>>
>> On 18 Jan 2017, at 16:25, lương hữu tuấn <tuantuluong at gmail.com> wrote:
>>
>> Hi Kirill,
>>
>> Do you have any information related to the performance of Jinja and Yaql
>> validating. With the big size of input, yaql runs quite so slow in our case
>> therefore we have plan to switch to jinja.
>>
>> Br,
>>
>> @Nokia/Tuan
>>
>> On Tue, Jan 17, 2017 at 3:02 PM, lương hữu tuấn <tuantuluong at gmail.com>
>> wrote:
>>
>>> Hi Kirill,
>>>
>>> Thank you for you information. I hope we will have more information
>>> about it. Just keep in touch when you guys in Mirantis have some
>>> performance results about Yaql.
>>>
>>> Br,
>>>
>>> @Nokia/Tuan
>>>
>>> On Tue, Jan 17, 2017 at 2:32 PM, Kirill Zaitsev <kzaitsev at mirantis.com>
>>> wrote:
>>>
>>>> I think fuel team encountered similar problems, I’d advice asking them
>>>> around. Also Stan (author of yaql) might shed some light on the problem =)
>>>>
>>>> --
>>>> Kirill Zaitsev
>>>> Murano Project Tech Lead
>>>> Software Engineer at
>>>> Mirantis, Inc
>>>>
>>>> On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantuluong at gmail.com)
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> We are now using yaql in mistral and what we see that the process of
>>>> validating yaql expression of input takes a lot of time, especially with
>>>> the big size input. Do you guys have any information about performance of
>>>> yaql?
>>>>
>>>> Br,
>>>>
>>>> @Nokia/Tuan
>>>> __________________________________________________________________________
>>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.org?subject:unsubscribe
>>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170123/e1af40ba/attachment.html>
More information about the OpenStack-dev
mailing list