Đang chuẩn bị liên kết để tải về tài liệu:
developing facebookbapplications phần 10

nhưng nó không phải là một viên đạn kỳ diệu. Nó cần có thời gian cho memcached để lưu trữ các đối tượng trong bộ nhớ cache. Trừ khi ứng dụng của bạn liên tục kéo cùng một dữ liệu từ bộ nhớ cache mà không sửa đổi nó, bạn thậm chí có thể trải nghiệm một sự suy giảm. | Caching Our Views 173 Using memcached can be a great way to eliminate database queries but it isn t a magic bullet. It takes time for memcached to store objects in the cache. Unless your application repeatedly pulls the same data from the cache without modifying it you may even experience a slowdown. For example if you store a last-accessed date on each user and update it on every request you won t get any benefit from caching. 9.2 Caching Our Views Caching our models can reduce database queries but there is more we can do. we ll look at several methods of view caching that can eliminate dynamic requests altogether. Rails provides three different levels of view caching each with its own pros and cons. Although page caching gives you the biggest performance benefit it is also the most difficult to manage. Fragment caching is easy to use but it does relatively little to boost performance in the average case. Of the three action caching typically gives the largest bang for your buck. if we combine view caching with memcached we get the best of both worlds. We will eliminate code when we can and when we can t we will make it faster with memcached. Thanks to the power of the Facebook platform we can use FBML to customize the look of a cached page as it is displayed to the user. Page Caching Page caching is the sledgehammer of Rails caching it is incredibly powerful and imprecise. With page caching enabled Rails will write the results of each request into the public directory. If your web server is correctly configured 3 future requests for this page will be served from disk completely bypassing Rails. Page caching is by far the fastest style of caching. Page cached pages are served directly from the web server bypassing Rails completely. A typical web server can comfortably serve 1 000 static files per second. As a side effect there is no way to ensure that the viewer has per -mission to access the requested page. Additionally because the same content will be sent to .