getPage function is very long to process - Forum - Rollbase - Progress Community

getPage function is very long to process

 Forum

getPage function is very long to process

  • Hello,

    We noticed that the getPage function is very long to process. It takes about 15 seconds to proceed views that show 100 records.

    This long time to process has been noticed in both rbf_getPage client-side API function and the getPage method from the REST and SOAP Web services.

    This is a weird behaviour because when browsing records using this view in the application (from the User Interface), it takes less than a second.

    Why does it take so much time to process?

    I may add that it takes a long time even if we only ask for a list of Ids and names "&fieldList=id,name".

    Romain.

  • Test App_v2.xml

    Hi romain,

    Tested rbf_getPage and seems like it loaded in less than a second with 300 records. Attached here is my test app.

    Do you have any other processes inside the callback?

    Will be testing the getPage and will let you know if I experience slow down too.

    Regards,

    Orchid

  • Hello Orchid,

    Thank you for your answer.

    This happens in our Rollbase private cloud instance.

    All other AJAX api functions are very quick to process (less than a second), only this "getPage" function takes way more time.

    We are using Rollbase 2.2.2.0 version.

    Do you know if there has been improvements on this function in a recent release?

    To answer your question, I do not have any other process inside the callback function. In fact, my callback function only does "console.log(data);" so it prints the results immediately in my browser developper console.

    Also, I cannot test your app because it requires "product2" object to be installed, which I don't have. Can you ship this app with the product2 being joined as a base object in the app instead of dependant object?

    Regards,

    Romain.

  • Test App_v3.xml

    I tested it with private cloud too but with the latest version 3.0.4.0. I'll be testing this with same version as yours and let you know if I get same loading issue.

    I was searching in the release notes from 3.0.0 to 3.0.4 but didn't see about getPage enhancement or fixes, there is something in the 3.0.0 about getPage but seems like it is not related to the issue. See more here Release Notes

    Attached here is the latest xml of my test app, I see product2 was in the dependent object, i just removed it there. The test object is in the Product, you can see the code in the Product tab.

    Regards,

    Orchid

  • This API may bring back related records along with core records (this is managed by "composite" and "objNames" parameters). You can also choose how many records you wish to retrieve in one call by setting "rowsPerPage" parameter.

    So amount of work performed by this API can vary in widely. For that reason elapsed time can vary too.

  • I just added this information to the documentation, very useful!

  • Hello,

    Thank you Pavel for the info.

    Orchid, thank you, I was able to install and try your app.

    Indeed, with your app, it is very fast.

    I believe this is because your Product object only has 2 relationships defined.

    I am having trouble with my Employee object, which has 311 fields and 145 relationships defined.

    When doing getPage requests, it takes about 7 seconds to process 20 records. (I only have 20 employees defined).

    I don't know what I am doing wrong, I am using the following code:

    - rbf_getPage(21900812, 0, 20, 0, "collaborateur1", "id, name", my_callback);

    This should only retrieve Ids and Record names, but since it takes so much time to process, I'm certainly wondering if it's not processing all relationships and fields, even though I'm not asking for them to be retrieved.

    The parameters are the following:

    - startRow: 0

    - rowsPerPage: 20

    - composite: 0

    - objNames: "collaborateur1" (This is the integration name for my Employee object)

    - fieldNames: "id, name"

    I have created a portal so you can see for yourself:

    paas.elsatis.fr/.../portal.jsp

    Best regards,

    Romain.

  • Tested in 2.2.2.0 with my test app and it was fast with 300 records about 1sec.

    I saw your app, Thanks for that. Now, I tested another object with 30+ relationships, 400+ fields and in my rbf_getPage with only 2 fields and get 200 records --- I noticed a very slow process like 20sec or more.

    I will try to get more info about the rbf_getPage / getPage and will let you know of what I can get.

    Regards,

    Orchid

  • Thank you Orchid.

    Kind regards,

    Romain.

  • Romain,

    In my last project I was working on, we had to refactor a significant part of our app to take out the rbf_getpage method from core page functions.  I beleive our guys used the rbf_selectQuery and the rbf_getfields methods.  In our case, we had an Employee object with many relationships as well (around 100 as I remember) and the getpage method proved to be about 1000x slower than the methods we switched to.

    Hopefully this helps some, and feel free to ask me any follow up questions.

    Best Regards,

    Joel

  • Hello,

    Thank you jetconsulting, glad to see that I'm not the only one experiencing this inconvenience.

    Unfortunately, I cannot use rbf_selectQuery in my case, I can only use getPage, because I want my user to define a population by entering a view Id.

    Then I want to do some processing in a trigger for all the records that are in the population (= all the records for the view which has been specified).

    Kind regards,

    Romain.

  • Hi Romain,

    This makes sense and it sounds like you are stuck with getPage.  As Pavel pointed out, there are some good reasons it is much slower (it is doing a lot more work) and I know the guys in Rollbase Product Planning are aware of some efficiency gain opportunities.  This may be an area you can report through a support case and get a Development ID for.  

    Wish you the best in your optimizing!

    Thanks!

    Joel

  • Hi Romain,

    I tested and saw in logs that it does really query through the relationships. I have another idea for you to use where you can utilize the VIEW id, use LOOP_BEGIN.

    <button onclick="getRecords();"> Get View </button>
    <script>
    function getRecords() {
    	//145437 = is the view id
    	//(20) = number of records to query, remove this if you want to view all records
        '{!#LOOP_BEGIN.all#145437(20)} '
        	$("#storeHere").append("<div> {!name} --- {!id} </div>");
        '{!#LOOP_END.all}'
    }
    </script>
    <div id="storeHere"> </div>
    
    
    
    

    Hope this may help

    Regards,

    Orchid

  • Hello,

    Thank you Orchid for your answer.

    Unfortunately, even though I thought about it, I don't think I can use loop_begins statements because I don't know the view Id in advance because it is a dynamic parameter.

    Indeed, I want the user himself to define a view by entering its ID into a Integer type of field, and then I want to retrieve the records for this view.

    Which means I should be able to do something like that:

    var viewId = rbf_getFieldValue('view_id');
    '{!#LOOP_BEGIN.all#'+viewId+'(20)}'
       $("#storeHere").append("<div> {!name} --- {!id} </div>");
    '{!#LOOP_END.all}'


    Which makes no sense because loop_begins statements are evaluated in server-side and my rbf call is going to be client-side.

    However, do you know if we can do this:

    var viewId = rbv_api.getFieldValue('myObjName', {!id}, 'view_id');
    '{!#LOOP_BEGIN.all#'+viewId+'(20)}'
       rbv_api.println('test');
    '{!#LOOP_END.all}'


    In Server-side triggers?

    Hopefully the getPage function can be fixed because It should probably not query through all relationships if we ask it not to by setting the "composite" parameter to 0.

    Then it would be perfect for me!

    Thank you very much.

    Kind regards,

    Romain.

  • I see, I hard coded the view id which it works and in your case it will come from a user input.

    Let me look for another option.

    Regards,

    Orchid