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

Walden H. Leverich wrote:

OK, I'm still confused. Are you talking about what the client does on it's end with its cache, or what FRCA does? If the former, fine, if the latter please explain more. 1) A request is a request, what's different between a "refresh" and a "reload" at the HTTP level. I can see including an IF-MODIFIED tag to see if the client should use its local copy, but a GET is a GET, no?
2) I have an issue with the client being able to direct to the server what should happen in its cache. If I as the developer/admin allow for the caching, a client shouldn't be able to override me.
3) Unless.... FRCA isn't considered part of the web server, it's actually a reverse proxy sitting on the front end. Ah, that might be it. I'm used to the IIS caching where it's part of the server so it's not considered a down-stream cache copy.
-Walden

________________________________

From: web400-bounces@xxxxxxxxxxxx on behalf of Wayne McAlpine
Sent: Wed 27-Oct-04 4:38 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] Re: FRCA-Fast Response Cache Accelerator any benefit while 
running CGI apps?

The browser buttons work differently.  In Mozilla, it's a "reload"
button and not a "refresh" button like IE.  The cache always honors a
reload request.  The IE refresh request forces a reload only if the
cache timer has expired.

Walden H. Leverich wrote:

Mozilla, however, forces a reload.

A refresh request from Mozilla forces FRCA to invalidate its cache?
Doesn't sound right.

-Walden

------------
Walden H Leverich III
President & CEO
Tech Software
(516) 627-3800 x11
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Wayne McAlpine
Sent: Wednesday, 27 October, 2004 15:15
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.

_______________________________________________
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.