Mike Smith d9678ff22e 18938 Passing the error log to the test start/stop 11 years ago
..
src 7641d8004c Get aspnet-stripped working with MySQL, PostgreSQL, MongoDB 12 years ago
.gitignore 7a41293dc3 Heavily stripped down version of aspnet tests: twice as fast for some tests 12 years ago
NuGet.exe 7641d8004c Get aspnet-stripped working with MySQL, PostgreSQL, MongoDB 12 years ago
README.md 1415f7bbef Fix README.md not to say that this is only for SQL Server 12 years ago
__init__.py 7a41293dc3 Heavily stripped down version of aspnet tests: twice as fast for some tests 12 years ago
benchmark_config 873dde0f06 Refactor benchmark_configs 12 years ago
setup_iis.ps1 b6e27cc06d Improve setup robustness of Windows tests 11 years ago
setup_iis.py d9678ff22e 18938 Passing the error log to the test start/stop 11 years ago
source_code 66e46ee08e codeLineCount Create source_code file for each framework. Modify count_sloc to use gather_frameworks instead of a large list 12 years ago

README.md

This is a heavily stripped-down version of pdonald's aspnet tests. Right now this is designed to run on Windows.

For CPU-bound tests such as db, json, fortunes, and plaintext, this is approximately twice as fast as the non-stripped aspnet tests. The performance is obtained by using ASP.NET IHttpHandlers, old-style .aspx files (when HTML is output) and removing unnecessary IIS/ASP.NET modules, especially ones related to URL routing and especially ones written in .NET.

To replace ASP.NET's URL routing, we directly specify the path to IHttpHandlers in web.config. The idea is that native code in IIS probably (definitely?) does the routing for handlers specified this way, so the routing should be extremely fast, as opposed to ASP.NET's System.Web.Routing code that is extremely configurable. To route to an .aspx page, we use NoAspxHandlerFactory, a small piece of 'middleware' that can directly route from this web.config setting to a .aspx file.

This is stripped down so much that I'm not sure if anyone would actually want to use these techniques in production. The point of this is the following:

  1. To provide a better comparison against microframeworks/microplatforms that barely do anything.
  2. To give us a sense of the upperbound of performance for more realistic tests.