For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Jon_Singh's avatar
Jon_Singh
Icon for Altostratus rankAltostratus
Sep 09, 2016

F5 APM Slow Performance

Hi All,

 

We are utilizing Portal Access Resources with rewriting to let users into our network and access applications (Proxy Mode Reverse). Overall it works but we are experiencing some heavy slow downs. It is expected that there would some speed decrease utilizing the APM Module in this way with the rewriting but in some cases it is very slow.

 

In one case, to log in to one application without APM it takes 4 seconds, with APM about 22 seconds.

 

My question is, where could I start to identify the slow down? I tried enabling debug in the logging for SSO/Portal Access/APM but haven't seen much usable informaiton. I was hoping to capture errors but I didn't get much of anything to help me identify the problem.

 

Any help or pointers, or tips to identify or increase our performance with the APM module is greatly appreciated.

 

Jon

 

BIG-IP
BIG-IP Access Policy Manager (APM)
devops

2 Replies

  • Matt_Dierick's avatar
    Matt_Dierick
    Icon for Employee rankEmployee
    Sep 09, 2016

    Hi Jon,

     

    You right, Portal Access uses rewrite engine and may take some time to rewrite the page and the content (javascript ...).

     

    Enable cache in your Portal Access ressource and you should see a better performance at the second connection. If you still experience latency, raise a case to F5 support in order to check the rewriting process (a JS might be difficult to rewrite).

     

  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Sep 09, 2016

    Start troubleshooting by figuring out if the issue is network or the JS interpreter on the browser.

    We have one issue that comes up pretty often in that there is some extra processing that occurs for document links, and sometimes pages can have a lot of these. That will be visible as extra JS processing in the app rather than network transfer speed.

    If it turns out to be that the browser is very busy processing javascript, try this irule:

     suppress document.links processing for a page
 Change "PUT YOUR URI THAT IS SLOW HERE" to the PATH of the HTML file you want to target
 The iRule for suppress document.links patching in one special file.

when HTTP_REQUEST {
    if {[HTTP::path]  contains "PUT YOUR URI THAT IS SLOW HERE" } {
         set insert_noswitch 1
    } else {
         set insert_noswitch 0
    }
}

when REWRITE_REQUEST_DONE {
  if {$insert_noswitch  != 0} {
          REWRITE::post_process 1
  }
}

when REWRITE_RESPONSE_DONE {
    log local0. "uncomment this to see if the rule is firing in the right place"
    set strt [string first {