kainsavage

<Sees baby boomers retiring to Nevada/Arizona where tax rates are lower>

"Humans are fleeing California, looking for a better life!" - CBSNews

That moment when your tool gets posted to Hacker News and the video on your homepage is muted and cannot be unmuted.

TIL: $73/year is "insanely expensive".

Literally cheaper than sponsoring an African child or paying Sarah McLachlan to stop using commercials to make me cry.

Biggest annoyance with this software - backspace is, apparently, something that I alone exercise. If you type an incorrect letter, it simply doesn't advance the cursor rather than advancing the cursor and marking the letter as incorrect. Since I am already a pretty good touch-typist, I routinely KNOW I have hit an incorrect key, hit backspace, and correct it and progress with the word.

However, very often I will do something like spelling "icnorrect" from feeling, then hitting backspace exactly eight times and re-type "ncorrect"... which is simply not supported by this software.

We aren't trying to measure each hardware set as apples-to-apples, but rather give the reader an idea of how performance characteristics for a chosen stack are affected by hosting environment. Specifically, we wanted the middle-of-the-road EC2 instances versus the extremely high-end Peak option to illustrate that difference.

Thanks for the pointer - I have reconfigured our Apache to support the ailing browsers affected by a stricter cipher suite selection.

I am not familiar with Owin; how does it differ from Mono?

Our suite takes a nuke-from-orbit approach when it comes to killing processes, as this has come up in every round. The idea is that now all tests are run with a specific user, and instead of relying on the test to shut down properly (which MANY could not reliably do), we simply nuke all processes owned by this runner.

It has the downside that if a process forks other processes and drops them into another different user (recently addressed for hhvm, for example), we cannot capture that. However, we have made great strides in trying to avoid that. Additionally, the logging for the application WOULD suggest if a port were bound prior to start-up, and that does not seem to be the case in this example.

Agreed. Our logging has undergone some solid improvements in the last week or two, and so round 11 will, if not resolve this issue completely, make the logged output more useful for tracking down issues like this during the preview runs.

Rust and Elixir SHOULD be included in Round 11 - we have already accepted a pull request for the Phoenix framework (Elixir) and have had a pull request for Rust when it was in alpha. Hopefully, we will see another Rust pull request soon.

We HAVE the memory data, but we have not distilled it into a consumable form to use on our website. Here, for example, is the cpu/ram usage report for ULib's json test: https://github.com/TechEmpower/TFB-Round-10/blob/master/peak...

Actually, not really. We checked the code to ensure that there was no gaming the system and it definitely APPEARS to be making separate database queries as we require in our rules. In fact, we had this same question in round 9 and had a number of people audit it. We cannot explain it other than it might be pretty darn fast.

Isn't this irrelevant since no one is 1) using CGI on Macs and 2) no one is using a Mac as a server?

I just posted another response to this - we had some trouble with the package manager for Erlang after round 6. Additionally, I had been working on improvements for the suite specifically (better logging/reporting, etc) and did not get a chance to resolve the Erlang problems.

Rest assured, "get erlang running again" tops my 'todo' list for round 9.

We have been having trouble with Erlang frameworks since before Round 7. Unfortunately, I was still getting up to speed and improving the suite mostly for Round 7/8 and did not get to fix this yet. I do have it topping my todo list for round 9, with the hope being to get them all back in and working soon.

Gemini is our internal Java web framework; it has no relation to the Eclipse project (other than I use Eclipse when I work on Gemini) ^_^

> This is oversimplified debate-club propaganda presented as fact.

... he said, hoping everyone would accept the statement as fact.

We are accepting pull requests on the GitHub page, yes.

In my opinion, you hit the nail on the head with regard to a view on Java (being that it is "slow"). For many years in the early going, it was slow, but it has come around so much.

That being said, as a day-to-day Java web-developer, I cannot honestly remember the last time I wrote "public static void main".

There is a column labeled 'errors' for this, but basically only Lift and Phreeze had errors.

While it is true that our source code is closed at the moment, you are still free to check out the benchmark code from github and run it yourself to verify our results.

It wouldn't really be a fair test if we put all these frameworks up for testing, suggested Gemini was better than sliced bread with auto-applying jam, and didn't back it up in a testable way ;-)

We accepted a pull request for an Erlang framework yesterday, so they will be in the next round of benchmarks. If you want to ensure your favorite is listed, you can issue a pull request yourself on our github page.

Personally, I really like Lua and I would love to see a pull request with a Lua framework test!

Don't thank us, we didn't write the code for it - one of you (the community) wrote it and submitted a pull request. We just ensured that the test would work in our benchmarks, then ran it! We are happy to do it, and super appreciative of the support from you guys!

We got a pull request for an Erlang framework (my brain is not letting me pull up the name) yesterday that we accepted, but sadly it was too late for this round of benchmarks. We will include it in the next round.

We have at least one Erlang test that came in yesterday and will be included in the next round of benchmarks.

This is definitely something we want to include in the tests, but it is difficult to manage a fair way of monitoring. Outside of the actual benchmarks, where we kept everything as fair as possible, we ran individual tests to make sure they worked prior to the benchmarking and would routinely have htop running at the same time to get an idea of what that sort of data looks like.

It IS very interesting and is definitely something we have discussed methods for measuring for the sake of these benchmarks. Other areas that we discussed were cpu utilization, disk utilization, and network saturation.

Yes, we are using APC for all the PHP tests in this round of benchmarking.

This is really the point.

As our blog post suggests, where we are not experts we had to rely on the tutorials provided by each framework's authors to build a test setup. If a specific framework seems low on the list, it could be due to the fact that the best practices guides we found for getting set up were not correctly configured for production use.

Draw what conclusions you would like from this statement, but we did aim to be as fair and unbiased as possible.

We are doing precisely that: if there are any mistakes or misunderstandings about the production-level best practices, we are accepting pull requests on our github (set up with all these tests, in case you want to run them yourself) to fix them, rerun them, and then report our updated findings.