Спасибо Максу, вроде начал кое-что понимать...
У меня теперь вопрос относитель англицкой грамматики:-), помогите плиз, а то понимаю что дурят а как не понимаю:-), Вот текст на англицком:
Q: Can the accelerated content be cached?
It depends.
It makes no sense to ever attempt to cache dynamically generated content that will be different every time the object is requested and, these days, that accounts for a very large percentage of the traffic coming from most major online sites. In many cases, major online sites are now simply ALWAYS supplying slightly \'different\' versions of their page(s) to each and every requestor since they have \'round robin\' agreements in place with their advertisers which will insert different advertisements onto each and every copy of the pages each and every time they are requested.
Search engines ( like Yahoo! and Alta-Vista ) are perfectly good examples of this. The odds that any 2 search result pages generated dynamically as the result of a new query will be identical and that any benefit will be seen by trying to cache the previous search results are slim to none.
Likewise for just about all e-commerce transactions. The account information and form data being exchanged has very little chance of being \'the same\' for any 2 people using the interface so caching these kinds of e-commerce sites is usually pointless. Online catalogs or product listings can be the exception but even they change so often ( sometimes moment to moment ) that very little benefit is seen from attempting to cache these pages.
It all comes down to TIME. If the overhead required to store copies of pages in a local cache and to perform the complicated logic to determine where the \'freshest\' copy of a page resides takes more time to execute than it would to simply fast-compress the object and send it on its way then obviously the caching itself is simply a waste of time.
Our own testing has shown that when you take into account the high overhead of implementing any caching scheme and you combine it with the additional complexities of handling compressed versions of the normally uncompressed source objects, the real benefits of caching become hard to detect and/or justify.
The reality is this. Most HTTP objects that will provide the greatest speed benefit by being compressed before they are delivered to the requesting user-agent can be compressed in memory and forwarded to the requestor much faster than they can actually be verified as \'fresh\' in a local cache and retrieved from disk. The average HTTP entity is around 30k and, when using any modern CPU and a robust compression algorithm, can be fast-compressed multiple times before it could be located and retrieved from a local disk cache even once. These verifiable test results generally negate the entire need to store compressed versions of objects. Factor in the additional reality that most content is being dynamically generated at all times and the need for the storage/retrieval of compressed versions of requested objects to/from a local cache becomes hard to justify.
RCI\'s own research in this area is ongoing at this time the next version of mod_gzip will, in fact, include the ability to store copies of compressed objects to a special local compressed object cache, but this initial version of mod_gzip has no built-in compressed object caching of its own.
Кто тут хорошо знаком с англицким? Помогите плиз... Объясните в кратце, кешируются таки или не кешируються архивированные файлы? А то моих познаний английского не достаточно, чтобы понять весь этот бред, что они накатали.
