× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Yes, I believe that's correct. But don't spread it around or our server will be overwhelmed tomorrow.

Walden H. Leverich wrote:
Wayne,
Just so I understand then, if FRCA sees a GET request with a "cache-control:no-cache" header (what mozilla seems to always send and IE sends on Ctrl-F5) FRCA will expire it's cache and reload from the source -- correct?
-Walden


________________________________

From: web400-bounces@xxxxxxxxxxxx on behalf of Wayne McAlpine
Sent: Thu 28-Oct-04 10:32 AM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] Re: FRCA-Fast Response Cache Accelerator any benefit while 
running CGI apps?



FRCA reverse-proxy cache is a separate server instance caching at the
machine interface level.  You're right, it's downstream from the http
server.

IE has both a refresh command (F5 or the refresh button) and a reload
command (Ctrl-F5).  Both do what they're intended to do.  Mozilla
refresh is supposed to be Ctrl-R and reload Ctrl-Shift-R, but both
combinations force a reload.  I've played with the browser cache
settings and still can't seem to make it do what it's supposed to.

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.





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





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.