MalcolmEvershed

4 ms·

1.
by MalcolmEvershed 13y ago
There were a variety of experiments with async and I don't think there has yet been any data to show that it improved performance of this benchmark. [0] https://github.com/TechEmpower/FrameworkBenchmarks/pull&
2.
by MalcolmEvershed 13y ago
I implemented the threadpool tuning originally first for the ASP.NET tests ( https://github.com/TechEmpower/FrameworkBenchmarks/issues/39... ) because it improved performance 5-10%. If you've seen data sho
3.
by MalcolmEvershed 13y ago
No, I'm not implying any of that. I'm just saying that an important step to getting good performance is profiling to determine the cause of poor performance, then deciding whether it makes sense to try to improve performance in th
4.
by MalcolmEvershed 13y ago
In case anyone is curious what is going on with those ASP.NET TechEmpower benchmarks: The TechEmpower benchmarks are all about how much overhead you can eliminate. I profiled the CPU-bound ASP.NET TechEmpower benchmarks and most of the time
5.
by MalcolmEvershed 13y ago
I believe that quote from [2] is referring to simply calling accept(), but modern socket servers use epoll() (or similar) before accept() which I think still has the problem (because I've run strace on nginx and uwsgi and I'm pret
6.
by MalcolmEvershed 13y ago
It seems like this could help solve the thundering herd problem [0][1][2], no? [0] http://en.wikipedia.org/wiki/Thundering_herd_problem [1] http://stackoverflow.com/questions/15636319/why-is-a
7.
by MalcolmEvershed 13y ago
I worked on improving the aspnet (on Windows) results and I committed aspnet-stripped (based on @pdonald's aspnet tests) and HttpListener. As that committer, I have to ask: Why would you change your career path due to supposed 'ab