Caching is about storing something on a temporary basis so that you don't have to perform a more expensive operation to retrieve it every time.
HTTP caching is about saving round-trips to servers, if you just use default behaviour a browser will ask the server to "send me a copy of this resource if you have a more recent version"
If you set expires header to a future time, then the browser doesn't ask this question as it knows it can use the copy of the resource it's got.
Caching at this level improves the end-users experience and saves you bandwidth.
From your brief description HTTP caching could help with the smaller static files (have a read of ch3 of bookofspeed.com)
DB caching as memcached (and redis) are used for are about reducing the load on databases (for example) by saving the results on an operation and then serving them from the cache rather than repeating the database operation)
In your situation you would cache at the data retrieval layer based on the request parameters (and perhaps ensure the HTTP responses to the client aren't cached).
CDNs vs Proxy Servers...
These are really different beasts - CDNs are about keeping content close to your visitors so reducing latency - if you're serving large files it also puts them on a network optimised for it instead of your servers but there's a £££ price attached to doing that. Some CDNs e.g. cloud front have a proxy like behaviour where they go back to your origin server if they don't have the file the visitor wants.
Proxy servers are literally servers that sit between your server and the end visitor - they might be part of your server farm (reverse proxy) the ISP's network or the visitor's network.
A reverse proxy is essentially offloading the work of communication with the end-visitor from your servers e.g. if they have a slow connection they'll tie up a server generating a page for longer. Reverse proxies can also sit infront of multiple servers - either all doing the same thing or different things and the proxy presents a single address to the outside world. Squid is one proxy you might use but Varnish is very popular ATM too.
Normal proxies just act as caches for those visitors who come through them e.g. a company may have a caching proxy server at their internet gateway so that the first person visiting an external site gets to retrieve a file and subsequent visitors get it form the proxy - they get a faster experience and the company reduces their bandwidth consumption.
I'm guessing you don't have a high traffic site at the moment so your challenge is to understand where to spend your effort i.e. what needs optimising when.
My first recommendation would be to get some real user monitoring (RUM) in, even if it's building your own using Boomerang.js or Pion. Also look at monitoring tools such as Cacti/Munin/CollectD so you can understand the load on your servers.
Understanding your users experience is key to working out where you need to optimise.
发布评论
评论（1）
那么让我们从缓存开始...
缓存是临时存储某些内容，这样您就不必每次都执行更昂贵的操作来检索它。
HTTP 缓存是关于保存到服务器的往返，如果您仅使用默认行为，浏览器将要求服务器“如果您有更新的版本，请向我发送此资源的副本”
如果您将过期标头设置为将来的时间，那么浏览器就不会问这个问题，因为它知道它可以使用它所获得的资源的副本。
此级别的缓存可改善最终用户体验并节省带宽。
根据您的简短描述，HTTP 缓存可以帮助处理较小的静态文件（阅读 bookofspeed.com 的 ch3）
DB 缓存，因为 memcached（和 redis）用于通过保存结果来减少数据库的负载（例如） 在您的情况下，
您将根据请求参数在数据检索层进行缓存（并且可能确保不缓存对客户端的 HTTP 响应）。
CDN 与代理服务器...
这些是真正不同的野兽 - CDN 的目的是让内容靠近您的访问者，从而减少延迟 - 如果您提供大文件，它还会将它们放在为其优化的网络上，而不是您的服务器上，但有一个这样做所附加的价格为$$$。一些 CDN（例如云前端）具有类似于代理的行为，如果它们没有访问者想要的文件，它们会返回到您的原始服务器。
代理服务器实际上是位于您的服务器和最终访问者之间的服务器 - 它们可能是您的服务器场（反向代理）、ISP 网络或访问者网络的一部分。
反向代理本质上是从服务器上卸载与最终访问者的通信工作，例如，如果它们的连接速度较慢，它们将占用生成页面的服务器更长时间。反向代理也可以位于多个服务器前面 - 所有服务器都执行相同的操作或不同的操作，并且代理向外界提供单个地址。 Squid 是您可能使用的一种代理，但 Varnish 也是非常流行的 ATM。
普通代理只是充当通过它们访问的访问者的缓存，例如，一家公司可能在其互联网网关处有一个缓存代理服务器，以便第一个访问外部站点的人可以检索文件，而后续访问者可以从代理获取该文件 - 他们获得更快的体验，公司减少带宽消耗。
我猜您目前的网站流量并不高，因此您面临的挑战是了解应该在哪里花费精力，即何时需要优化哪些内容。
我的第一个建议是加入一些真实的用户监控 (RUM)，即使它是使用 Boomerang.js 或 Pion 构建您自己的监控。另请查看 Cacti/Munin/CollectD 等监控工具，以便了解服务器上的负载。
了解用户体验是确定需要优化的关键。
Right then let's start with caching...
Caching is about storing something on a temporary basis so that you don't have to perform a more expensive operation to retrieve it every time.
HTTP caching is about saving round-trips to servers, if you just use default behaviour a browser will ask the server to "send me a copy of this resource if you have a more recent version"
If you set expires header to a future time, then the browser doesn't ask this question as it knows it can use the copy of the resource it's got.
Caching at this level improves the end-users experience and saves you bandwidth.
From your brief description HTTP caching could help with the smaller static files (have a read of ch3 of bookofspeed.com)
DB caching as memcached (and redis) are used for are about reducing the load on databases (for example) by saving the results on an operation and then serving them from the cache rather than repeating the database operation)
In your situation you would cache at the data retrieval layer based on the request parameters (and perhaps ensure the HTTP responses to the client aren't cached).
CDNs vs Proxy Servers...
These are really different beasts - CDNs are about keeping content close to your visitors so reducing latency - if you're serving large files it also puts them on a network optimised for it instead of your servers but there's a £££ price attached to doing that. Some CDNs e.g. cloud front have a proxy like behaviour where they go back to your origin server if they don't have the file the visitor wants.
Proxy servers are literally servers that sit between your server and the end visitor - they might be part of your server farm (reverse proxy) the ISP's network or the visitor's network.
A reverse proxy is essentially offloading the work of communication with the end-visitor from your servers e.g. if they have a slow connection they'll tie up a server generating a page for longer. Reverse proxies can also sit infront of multiple servers - either all doing the same thing or different things and the proxy presents a single address to the outside world. Squid is one proxy you might use but Varnish is very popular ATM too.
Normal proxies just act as caches for those visitors who come through them e.g. a company may have a caching proxy server at their internet gateway so that the first person visiting an external site gets to retrieve a file and subsequent visitors get it form the proxy - they get a faster experience and the company reduces their bandwidth consumption.
I'm guessing you don't have a high traffic site at the moment so your challenge is to understand where to spend your effort i.e. what needs optimising when.
My first recommendation would be to get some real user monitoring (RUM) in, even if it's building your own using Boomerang.js or Pion. Also look at monitoring tools such as Cacti/Munin/CollectD so you can understand the load on your servers.
Understanding your users experience is key to working out where you need to optimise.