With a session called "Caching and Timeouts" late in the day in the middle of the week, my expectations of paying attention were pretty low.  But Graham Smith from Oxfam gave the most practical and complete presentation of the topic that I’ve heard.

Oxfam is one of those rare companies that runs PeopleSoft all over the world.  Not just in nice urban centers with reliable fiber-optic networks, but in places like Afghanistan where the only power comes from a diesel generator and the network is a small satellite dish on the roof.  In such situations, it’s absolutely critical to get caching and timeouts optimized, or the user experience will be non-existent.

I had a client in Switzerland once with the challenge to operate in similar environments, and although it’s been over 10 years I’m still interested in how companies do computing in hostile environments.

It’s not that the subject matter was difficult, or that I didn’t know most of it already, but the completeness of the presentation and the additional insights to the process made the session worthwhile.  Here are the points I came away with:

Caching

Cache is a tradeoff between speed and currency.  The goal is to cache frequently accessed but infrequently changed objects. The question you have to ask yourself is how important it is to stay up to date.

Cache resides on the Application Server, the web server and the browser.  Application Server cache works like this:  When a request for a PeopleTools object is made, the application server checks its in-memory cache for the object. If it’s not there, it checks the disk cache and if it finds it, it pulls it into memory and uses it there.  If it’s not on the disk, it pulls the object from the database.

The web server caches the following objects:
•    CSS, Javascript, GIF files (these are static, usually changing only during a PeopleTOols upgrade)
•    Navigation Pages (in Tools 8.45 and above, this is the big supplemental navigation page in the main frame, not the left-hand menu).
•    Portal Header HTML (The frame at the top of the screen)
•    Portal Homepage
•    Portal Pagelets
The client browser caches these same objects with a couple of exceptions:
•    Portal pagelets are not cached, at least the currently released tools versions (through 8.49)  You may find objects in your client cache that looks like portal pagelets, but these objects do not contain the content of the pagelets.  This content IS cached on the web server.
•    Navigation pages are not cached.  They should cache, but an iScript/HTML bug prevents it.  There is a POC fix available on customer connection if this is a problem for you.
Now security doesn’t change often, so it is good to cache portal objects like navigation pages and menu navigation where possible. 

The browser manages its local cache like this:
1)    Is it local?
2)    Has it expired? If no, fetch it, if yes, go to the next step.
3)    Is it on the web server?  If yes, fetch it, if not build it.

There are some tools that are very useful for viewing cache properties and which items are retrieved from where.  Microsoft’s Fiddler tool (available from www.fiddlertool.com) is very good.  Firebug is a good tool for firefox, and the Internet Explorer Developer Toolbar is good as well (as long asyou download it from Microsoft.com).  You may be surprised at how many requests are made to the web server with each mouse click once you’re viewing the activity with one of these tools.

PeopleSoft performance monitor is also an invaluable tool for troubleshooting such things.

Did you know:
•    CTRL-Refresh in Internet Explorer forces the browser to bypass local cache and forces it to go to the web server.
•    A 304 HTTP response code means the browser compared the dates on its cache with the web server to see if anything is out of date.
•    By default, image objects are cached in the browser for 10 years.
•    After a PeopleTools upgrade, you should ask your users to clear their local browser cache to insure new images, CSS and Javascript is re-loaded from the web browser.
•    Jolt-pooling often causes more problems than it fixes.  Ou should turn it off.
•    If you create a navigation collection through the wizard, you need to manually check the “Enable Caching” check box on the last page or it will not be cached.
•    If you’re serious about improving performance between the web server and the browser, check out HTTP Accelerators.  They’re inexpensive and effective.

Have you ever noticed how when you change security it might show up at one level of the navigation menu, and not at another?  This is because all menu levels are not cached equally.  From ___’s analysis, the root menu is not cached on the web server, and there’s no way to cache it.  The submenus on the other hand do get cached – for 24 hours by default.  So when security is changed the best thing to do is to clear the web server cache, and ask the user to clear their browser cache as well.

Timeouts

Here are the timeouts in the order that they appear:
1)    Browser client inactivity warning.  Set in the Web Profile, and happens in javascript in the browser.
2)    Send Timeout.  Time to Send Jolt Request to Tuxedo.  Set in the web profile.
3)    Receive Timeout.  Time to receive a jolt response from tuxedo.  This must be greater than all of the timeouts down the chain.
4)    Disconnect timeout.  The amount of time to wait before disconnecting the BEA jolt connection.  This is set in the Web Profile.
5)    HTTP Session Activity.  The time after which user sessions and component state reset. Set in the Web Profile.
6)    Client Cleanup Timeout.  This overrides the disconnect time.  Set in PSAPSRV.CFG.  It must be greater than the service timeout.  Set in psappsrv.cfg.
7)    Service Timeout.  This is the maximum time a Tuxedo transaction will run before being terminated.  Set in psappsrv.cfg.

Comments (0)

Write comment

Name

Email

Website

Title

Comment

Write the displayed characters

Add Comment