3 ms·

I used Go's benchmarking tool to compare raw routing performance of various frameworks. The handlers all return a simple "Hello World" string. Here are the resu

I used Go's benchmarking tool to compare raw routing performance of various frameworks. The handlers all return a simple "Hello World" string. Here are the results: PASS Benchmark_Routes 100000 13945 ns/op Benchmark_Pat 500000 6068 ns/op Benchmark_GorillaHandler 200000 11042 ns/op Benchmark_Webgo 100000 26350 ns/op ok github.com/bradrydzewski/routes/bench 12.605s I then ran the same benchmark, but this time I modified the handler to serialize a struct to JSON and write to the response. Here are the results: Benchmark_Routes 100000 21446 ns/op Benchmark_Pat 100000 14130 ns/op Benchmark_GorillaHandler 100000 17735 ns/op Benchmark_Webgo 50000 33726 ns/op ok github.com/bradrydzewski/routes/bench 9.805s In the first test, Pat is almost twice as a fast as the Gorilla framework. In the second test, when we added a bit more logic to the handler (marshaling a struct to JSON), Pat was only about 18% faster than Gorilla. In fact, it turns out it takes longer to serialize to JSON (8000ns) than it does for Pat to route and serve the request (6000ns). Now, imagine I created a third benchmark that did something more complex, like executing a database query and serving the results using the html/template package. There would be a negligible difference in performance across frameworks because routing is not going to be your bottleneck. I would personally choose my framework not just based on performance, but also based on productivity. One that can help me write code that is easier to test and easier to maintain in the long run.

rorrr 14y ago
> Now, imagine I created a third benchmark that did something more complex, like executing a database query and serving the results using the html/template package. There would be a negligible difference in performance across frameworks because routing is not going to be your bottleneck. If you're performing a DB query on every request, you're doing something wrong. In the real world your app will check Memcached, and if there's a cached response, it will return it. Thus making the framework performance quite important.
pifflesnort 14y ago
rorr, you appear to be hellbanned. Here's your comment, since it seemed like a reasonable one: > Now, imagine I created a third benchmark that did something more complex, like executing a database query and serving the results using the html/template package. There would be a negligible difference in performance across frameworks because routing is not going to be your bottleneck. If you're performing a DB query on every request, you're doing something wrong. In the real world your app will check Memcached, and if there's a cached response, it will return it. Thus making the framework performance quite important.
- bradrydzewski 14y ago
  Ok, so I added a third benchmark where the handler gets and item from memcache (NOT from a database). Here are the results: PASS Benchmark_Routes 10000 234063 ns/op Benchmark_Pat 10000 233162 ns/op Benchmark_GorillaHandler 5000 265943 ns/op Benchmark_Webgo 5000 348349 ns/op ok github.com/bradrydzewski/routes/bench 10.062s Notice the top 3 frameworks (pat, routes and Gorialla) have almost identical performance results. The point being is that routing and string manipulation are relatively inexpensive when compared to even the most lightweight TCP request, in this case to the memcache server.
codewright 14y ago
By the way: https://plus.google.com/u/0/115863474911002159675/posts/L3o9hEs8SAe https://plus.google.com/u/0/115863474911002159675/posts/L3o9... More SPEEEEEEEEEEEEED coming down the pipe in 1.1 for Go's net/http. :)

rorrr 14y ago

> Now, imagine I created a third benchmark that did something more complex, like executing a database query and serving the results using the html/template package. There would be a negligible difference in performance across frameworks because routing is not going to be your bottleneck. If you're performing a DB query on every request, you're doing something wrong. In the real world your app will check Memcached, and if there's a cached response, it will return it. Thus making the framework performance quite important.

pifflesnort 14y ago

rorr, you appear to be hellbanned. Here's your comment, since it seemed like a reasonable one: > Now, imagine I created a third benchmark that did something more complex, like executing a database query and serving the results using the html/template package. There would be a negligible difference in performance across frameworks because routing is not going to be your bottleneck. If you're performing a DB query on every request, you're doing something wrong. In the real world your app will check Memcached, and if there's a cached response, it will return it. Thus making the framework performance quite important.

bradrydzewski 14y ago
Ok, so I added a third benchmark where the handler gets and item from memcache (NOT from a database). Here are the results: PASS Benchmark_Routes 10000 234063 ns/op Benchmark_Pat 10000 233162 ns/op Benchmark_GorillaHandler 5000 265943 ns/op Benchmark_Webgo 5000 348349 ns/op ok github.com/bradrydzewski/routes/bench 10.062s Notice the top 3 frameworks (pat, routes and Gorialla) have almost identical performance results. The point being is that routing and string manipulation are relatively inexpensive when compared to even the most lightweight TCP request, in this case to the memcache server.

codewright 14y ago

By the way: https://plus.google.com/u/0/115863474911002159675/posts/L3o9hEs8SAe https://plus.google.com/u/0/115863474911002159675/posts/L3o9... More SPEEEEEEEEEEEEED coming down the pipe in 1.1 for Go's net/http. :)