Portal Access Slow

Hi Isaac, Can provide your technical reason why you think it could be slower it would be helpful for all of us to make some suggestions to look for.

-=Bhattman=-

VE Is pretty easy to mis-configure from a hypervisor networking point of view. What hypervisor are you using please?

OK, so a few things to check/try;

• Ensure you are using VMXNET3 vNICs
• Enable TCP Segmentation Offload (TSO) by modifying 'sys db tm.tcpsegmentationoffload' and setting it to enable
• Enabling TSO support also enables support for Large Receive Offload (LRO) and Jumbo Frames
• If this still doesn't help try disabling Large Receive Offload (LRO) in the hypervisor
• I also believe enabling SR-IOV in the hypervisor can help

did you get any further? it could be the VE part. but it could also be the APM portal part, has happened to me before. try to access the websites through the BIG-IP (but without the APM portal) to determine the network part of the BIG-IP.

If you haven't applied the web acceleration profile, try that. This will help to use ramcache to improve performance.

If you haven't applied the web acceleration profile, try that. This will help to use ramcache to improve performance.

If I may add, there's another forum thread on this same issue:

https://devcentral.f5.com/questions/portal-system-very-slow

There are a few options for acceleration. First, each portal resource will have its own compression and caching settings. Second, and this is a method that I tend to prefer, I'll build internal VIPs for each of my applications and then point the portal objects at these VIPs (basically VIP targeting).

Some level of web acceleration should definitely help, but aside from that, I would do a Fiddler/HTTPWatch capture of direct and portal access to each of these applications and compare the times for each request/response cycle. If you notice that large files, specifically JavaScript, CSS, Flash, or Java files, then that's probably the issue. The portal rewrite engine has to parse each of these files as they pass through the box, looking for links to rewrite. If the files are large, that can eat some time. There are definitely ways around this, but do the analysis first.

As a quick test, disable JavaScript Patching in your SharePoint portal config and test again. This may break some functionality if you have some site specific JS files with URLs in them, but you should see a noticeable difference in overall performance.

hi Everyone,

I am also facing a slowness issue with my Portal Access configuration, when i access them via APM it is very slow, but when i bypass it is fast. I tried using http watch and found that some of the pages are getting response of 404. But that is not the case when i am bypassing the APM.

I assume that the Rewrite profile is taking a long time to rewrite the content. Is there any way i can troubleshoot the issue.

I have one Virtual Server with 8 portal access configured on it. some of the applications which are running on port 80 in the backend is working fine. while the portal running on port 443 shows a huge delay.

Vs 443 offloading --> Portal Access 80 good performance.

Vs 443 offloading --> Portal Access 443 too slow.

Thanks.

if i were you i'd start a new question. provide things like your version and such so others can find similar issues.

what if you take the APM profile off, just LTM, is it slow then also? so all backend applications on 443 are slow and all backend on port 80 are fast. can you test with an application which is available on 80 and 443, is then slow on both or fast on both or ...?