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

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.