Re: FRCA-Fast Response Cache Accelerator any benefit while running CGI apps? -- WEB400

Well, actually, it's much less than three minutes on average. If you're the first person requesting the page, or the three-minute timer has expired, you get it with no time delay. If it's within the three-minute window, i.e., 1 to 180 seconds after the page was last loaded, you get the cached copy.

If it's an infrequently requested page, you'll always get a fresh copy. Otherwise, odds are that the cached copy is only 90 seconds old. This is acceptable in our application and solves the problems of users hitting the refresh key non-stop to be sure they're getting up-to-the-minute returns.

And yes, I shouldn't have called it real time. It used to be, but not any longer. But still close enough for government work ;-)

Mike Skvarenina wrote:

So doesn't this mean that "real-time" really means up to a 3 minute
delay?  In my case, I can't afford a 3-minute delay for up to date real
time data so I don't believe this would work for me.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Wayne McAlpine
Sent: Wednesday, October 27, 2004 12:15 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] Re: FRCA-Fast Response Cache Accelerator any benefit
while running CGI apps?
I have been using FRCA reverse proxy cache for the past year with cgi programs to serve election night results real-time. I've got it set to cache for three mminutes, so the first call to a particular page loads it into the cache. Subsequent calls during the next three minutes receive the cached copy. There are literally thousands of pages cached in a large election and this works extremely well.
Prior to using the cache, each request did a cgi database read and buidl
of an html page, with a resulting high processor and disk usage.  We did
some stress testing originally and found a tremendous performance improvement using the cache, while keeping cpu usage within acceptable levels. The real test will be next Tuesday night when the polls close. Wish me luck!

BTW, the IE browser refresh button retrieves the cached copy. Mozilla, however, forces a reload. Fortunately, about 98% of our clients are IE,
so it works fine.
Mike Skvarenina wrote:
My apologies for the continuous questions but now that I'm running
Apache, I
feel like a kid in a candy store and am looking to maximize my CGI
performance.  The documentation is useful but end user experience is
almost
always much more informative.
This question is about the FRCA. My CGI apps are basically RPG
database
intensive programs that don't make much use of the IFS. About the
only IFS
references I use is for the graphics (icons and pictures) I store on
the IFS
so my CGI apps can reference them.
In this case, does using FRCA add any benefit?
Also, I see there are options to specify the min and max number of CGI
jobs.
The default is 40. I cannot find any documentation on recommended
values
based on my system size.
_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.
_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.