To be clear, the particular test cited is expressly designed to exercise the framework and its ORM+database connectivity. None of our present test types permit the use of a reverse proxy cache because we are specifically interested in measuring the performance of the frameworks/platforms and not the performance of reverse proxy software; you can find such tests elsewhere. Further, reverse proxies are only suitable for a subset of real-world applications where it is acceptable to cache output for consumption by a wide audience.
In other words, Rails wasn't unique in being tested without a preferred reverse proxy. Every single framework on that list was tested without a reverse proxy.
A future test type [1] will exercise back-end caching (e.g., memcached in the case of Rails), but we are not planning to ever include reverse proxies (of any form) in the project.
In other words, Rails wasn't unique in being tested without a preferred reverse proxy. Every single framework on that list was tested without a reverse proxy.
A future test type [1] will exercise back-end caching (e.g., memcached in the case of Rails), but we are not planning to ever include reverse proxies (of any form) in the project.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/issues/37...