{'fraction_non_alphanumeric': 0.020865936358894107, 'fraction_numerical': 0.0005216484089723526, 'mean_word_length': 4.865443425076452, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Transparent Caching and Consistency in Dynamic Content Web Sites

We consider a cluster architecture in which dynamic content is generated by a database back-end and a collection of Web and application server front-ends. We study the effect of transparent query caching on the performance of such a cluster. Transparency requires that cached entries be invalidated as a result of writes. If multiple caches are present, the caches also have to be kept consistent. A cached query needs to be invalidated when an underlying data item in the database changes. The necessary dependency tracking and the resulting invalidation can be done at the granularity of a database table or a database column. A query cache may be located at the database back-end, on dedicated machines, on the front-ends, or on a combination thereof. This paper evaluates the tradeoffs in invalidation granularity and cache location using the TPC-W benchmark. We have implemented caches with both coarseand fine-grain invalidation, and we have measured their performance when placed at various locations. We conclude that transparent query caching improves performance very substantially, up to a factor of 2 in throughput and response time. Fine-grain invalidation is considerably more effective than coarse-grain evaluation. The benefits of the higher hit ratio outweigh the costs of additional processing. The results are less clear-cut in terms of where to locate the cache. With a single front-end, the performance differences are small. With multiple front-ends, the best approach depends on the fraction of writes in the workload. A small number of writes makes a two-level cache attractive, with private caches on the front-ends and a shared cache on a dedicated machine. With increasing number of writes, the cost of enforcing consistency between these private caches reduces performance compared to a single cache on a dedicated machine.