Open Stack

Hi Renat,

In short, it is the expression: output: <% $.data %>

I would like to post the workflow too since it would make more sense to
understand the whole picture(IMHO :)). In this case, it would be that the
data is too big, AFAIK is around 2MB. Therefore i would just wanna know
more information about the performance of YAQL (if we have), i myself do
not judge YAQL in this case.

Br,

Tuan

On Tue, Jan 24, 2017 at 6:09 AM, Renat Akhmerov <renat.akhmerov at gmail.com>
wrote:

> While I’m in the loop regarding how this workflow works others may not be.
> Could please just post your expression and data that you use to evaluate
> this expression? And times. Workflow itself has nothing to do with what
> we’re discussing.
>
> Renat Akhmerov
> @Nokia
>
> On 23 Jan 2017, at 21:44, lương hữu tuấn <tuantuluong at gmail.com> wrote:
>
> 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: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.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: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:unsubscribe
> 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/20170124/150e1b25/attachment.html>