Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1120 rxapi overhead - any techniques for keeping to a minimum?

None
invalid
nobody
None
none
1
2012-10-03
2012-10-03
Andrew McIntyre
No

Ubuntu 12.04.1 Server

now rexx 411 amd64 - (upgrading from 410 to 411 fixed my system queue abend - see other post - yea!!)

So without command piping anything to an rxqueue stage, and no push/pull or queued() my rxapi overhead was about 7% (see other post) and stayed there daily. Some internal REXX usage I'm not clear on accounts for this I guess...

Anyway, I recently started using some rxqueue set and push/pull between processes and I'm now up to about 9% cpu overhead.

I get these percentages by taking the total rxapi cpu usage and dividing that by the total rexx process usage (currently same 4 all day long), as shown by Linux top TIME column at end of day.

I anticipate more usage of push/pull between processes, plus whatever rxapi is being used for internally by rexx, plus increased data volume and I'm getting a little worried...

My question is, are there any techniques that I can use, things I can avoid, etc., etc. to keep the rxapi cpu usage overhead to a minimum?

Thanks for the help!!

Discussion

  • and I forgot to add, I'm using Mark's rexx/sql 2.6b2 a whole lot with db2... if that might explain any of the rxapi overhead...

     
  • Rick McGuire
    Rick McGuire
    2012-10-03

    My apologies for not replying sooner. The notification system for sourceforge was not working recently, so this bug report fell through the cracks. I am going to close this, as this is not a bug.

    The rxapi process is used for things other than the queue, specifically the macrospace and registered external functions. These registries are checked as part of the external function call search order, so that probably accounts for the overhead you are seeing. If you are making calls to external rexx programs, the external program is the last step of the search order, so there will be a check for a registered native function and two different macrospace registry checks before the external file is loaded. If you rework your functions into packages that get loaded via ::requires, those functions will be located as the first step of the call search order, thus avoiding all of the rxapi involvement. Additionally, you'll also get a performance boost since the functions will only be loaded from disk once, rather than on every call.

    • status: open --> invalid
     
  • some link on sourceforge took me to the bugs forum directly.. the link
    said something about "this is the link they prefer to use".. sorry if i
    put it in the wrong place..

    anyway, I'm not doing any external function calls.. all of my calling is
    internal to a single rexx.. except for linein, lineout, time, rxqueue,
    syssleep..

    one process is doing an every second call to a C command that pipes to
    grep then to a file..

    and all the processes are making extensive use of Mark's sqlexecute..
    can I load it somehow?

    not sure how to make a C command a package and load it via ::requires...
    is that possible?

    and any other how to speed up rexx advice gladly welcomed...

    On 10/03/2012 05:28 PM, Rick McGuire wrote:

    My apologies for not replying sooner. The notification system for
    sourceforge was not working recently, so this bug report fell through
    the cracks. I am going to close this, as this is not a bug.

    The rxapi process is used for things other than the queue,
    specifically the macrospace and registered external functions. These
    registries are checked as part of the external function call search
    order, so that probably accounts for the overhead you are seeing. If
    you are making calls to external rexx programs, the external program
    is the last step of the search order, so there will be a check for a
    registered native function and two different macrospace registry
    checks before the external file is loaded. If you rework your
    functions into packages that get loaded via ::requires, those
    functions will be located as the first step of the call search order,
    thus avoiding all of the rxapi involvement. Additionally, you'll also
    get a performance boost since the functions will only be loaded from
    disk once, rather than on every call.


    bugs:1120 rxapi overhead - any techniques for keeping to a minimum?

    Status: open Created: Wed Oct 03, 2012 09:13 PM UTC by Andrew
    McIntyre Last Updated: Wed Oct 03, 2012 09:18 PM UTC Owner: nobody

    Ubuntu 12.04.1 Server

    now rexx 411 amd64 - (upgrading from 410 to 411 fixed my system queue
    abend - see other post - yea!!)

    So without command piping anything to an rxqueue stage, and no
    push/pull or queued() my rxapi overhead was about 7% (see other post)
    and stayed there daily. Some internal REXX usage I'm not clear on
    accounts for this I guess...

    Anyway, I recently started using some rxqueue set and push/pull
    between processes and I'm now up to about 9% cpu overhead.

    I get these percentages by taking the total rxapi cpu usage and
    dividing that by the total rexx process usage (currently same 4 all
    day long), as shown by Linux top TIME column at end of day.

    I anticipate more usage of push/pull between processes, plus whatever
    rxapi is being used for internally by rexx, plus increased data volume
    and I'm getting a little worried...

    My question is, are there any techniques that I can use, things I can
    avoid, etc., etc. to keep the rxapi cpu usage overhead to a minimum?

    Thanks for the help!!


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/oorexx/bugs/1120/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/prefs/

    --
    personal Signature


    Andrew McIntyre
    amcintyre@m-m.com amcintyre@m-m.com
    http://www.mindspring.com/~amcintyr/resume.htm
    http://www.mindspring.com/%7Eamcintyr/resume.htm


     


Anonymous


Cancel   Add attachments