Open Stack

Ok, thanks. That looks more clear now.

Renat Akhmerov
@Nokia

> On 24 Jan 2017, at 14:15, lương hữu tuấn <tuantuluong at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe> 
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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 <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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 <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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/e3ca2599/attachment.html>