Ok, thanks. That looks more clear now. Renat Akhmerov @Nokia
> On 24 Jan 2017, at 14:15, lương hữu tuấn <tuantulu...@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.akhme...@gmail.com > <mailto:renat.akhme...@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 <tuantulu...@gmail.com >> <mailto:tuantulu...@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 <tuantulu...@gmail.com >> <mailto:tuantulu...@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.akhme...@gmail.com >> <mailto:renat.akhme...@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 <tuantulu...@gmail.com >>> <mailto:tuantulu...@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 <tuantulu...@gmail.com >>> <mailto:tuantulu...@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 <kzait...@mirantis.com >>> <mailto:kzait...@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 (tuantulu...@gmail.com >>> <mailto:tuantulu...@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-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org >>> <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >> <http://openstack-dev-requ...@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-requ...@lists.openstack.org >> <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
