Hi Parrin, > While it is possible to do some caching in a proxy like this, the more > important thing it does is buffering the content, and possibly serving static > requests for JavaScript and images. That frees up the mod_perl processes to > move on to another request.
I am questioning the value of this kind “proxy”. We have load balancer cache that can cache images and JavaScripts. This functions seems a bit duplicate. The value I am seeing is that because “proxy” understands the HTTP protocol so dynamic content can be served directly from “proxy” cache, without going through a front end server to memcache then a response back to a front end server to remote client. That’s the value I am seeing. I am not sure if this is the right understanding. - xinhuan From: Perrin Harkins <phark...@gmail.com<mailto:phark...@gmail.com>> Date: Thursday, November 13, 2014 at 4:54 PM To: Xinhuan Zheng <xzh...@christianbook.com<mailto:xzh...@christianbook.com>> Cc: mod_perl list <modperl@perl.apache.org<mailto:modperl@perl.apache.org>> Subject: Re: Disconnect database connection after idle timeout On Thu, Nov 13, 2014 at 2:41 PM, Xinhuan Zheng <xzh...@christianbook.com<mailto:xzh...@christianbook.com>> wrote: >From the description of the document, the “proxy” server acts much like a >memcache but it appears the difference is the “proxy” understands the HTTP >protocol while memcache does not. Not exactly. While it is possible to do some caching in a proxy like this, the more important thing it does is buffering the content, and possibly serving static requests for JavaScript and images. That frees up the mod_perl processes to move on to another request. This is the same process model used by most other systems, like FastCGI or nginx + Starman. Would you think this “proxy” server sitting in front of the front end server but behind the load balancer? Yes, it goes between your load balancer and your mod_perl server. - Perrin
