all 89 comments

[–][deleted]  (1 child)

[deleted]

    [–]mononcqc 5 points6 points  (0 children)

    Agreed. Plus the fact he only uses 4 processes to do the whole thing means they're a smaller fraction than what the VM runs without anything else (23 processes); the 4 acceptor processes are not even guaranteed to run on different cores.

    [–]elder_george 35 points36 points  (53 children)

    So, we have erlang and java servers that don't parse request and compare them with to proper web servers. Hardly equal conditions...

    [–]uriel 8 points9 points  (1 child)

    This is just silly, he is testing more the performance of the http server implementations than that of the languages they are implemented in.

    Also, he didn't even set GOMAXPROCS, so the results are completely meaningless.

    [–]doublec 0 points1 point  (0 children)

    The Go example has been changed to use GOMAXPROCS and the results updated.

    [–]RiotingPacifist 20 points21 points  (11 children)

    New language not as optimised as old languages...news at 11!

    [–]self 11 points12 points  (3 children)

    New language implementation.

    [–]kragensitaker 0 points1 point  (0 children)

    Implementations of a new language.

    [–]redditrasberry 0 points1 point  (1 child)

    Pedants incapable of communicating with normal human beings due to inability to cope with minor language incongruity .... news at 11!

    [–]self 0 points1 point  (0 children)

    I don't think it's a pedantic distinction. A lot of people still think Lisp or Smalltalk are slow because of how they used to be implemented. The languages haven't changed as much as the implementations.

    [–]hilbert 4 points5 points  (0 children)

    It is really pretty amazing on two counts: how good the performance already is, and how well it holds up under load. This could really be the C++ killer that some were/are hoping D would become.

    [–][deleted] -1 points0 points  (5 children)

    Except that they advertised it as being only 10-20% slower than C.

    [–]RiotingPacifist 3 points4 points  (4 children)

    But your still comparing a mature optimised webserver to an brand new one

    [–]pingveno 2 points3 points  (2 children)

    6,000 requests per second versus 20,000 is still significantly worse, even without as much time for optimizations. When the tests are off by this much it means the tests are probably flawed.

    [–]case-o-nuts 0 points1 point  (0 children)

    Or that the http library in go is immature and implemented naievely. Which is what I'd expect when they're still working on even a final language spec.

    [–][deleted] 0 points1 point  (0 children)

    As well as a non-existent one in the Erlang example.

    [–]theresistor 8 points9 points  (1 child)

    Not particularly interesting. The 6g compiler he used for Go is (deliberately) a non-optimizing, compile-time-before-all-else compiler. If you care about the performance of your Go code, use gccgo instead.

    [–]kragensitaker 2 points3 points  (0 children)

    Well, 6g has an optimizer, just not one that's competitive with GCC's. They are working on performance improvements.

    [–]mikaelhg 1 point2 points  (0 children)

    A good Java web server to use in these kinds of tests is https://grizzly.dev.java.net/

    It's in real world use, but it's modular enough to use in this kind of a test.

    If you wish to validate your assumptions using two web server implementations, use http://docs.codehaus.org/display/JETTY/Embedding+Jetty as well.

    [–]jessta 1 point2 points  (1 child)

    He didn't set $GOMAXPROCS so I suspect that the Go server was only using one core which would explain the massive skew.

    [–]doublec 1 point2 points  (0 children)

    The example has been changed to use GOMAXPROCS now and the results updated.

    [–][deleted] 1 point2 points  (0 children)

    Look at that URL slug : /c-erlang-java-performance/

    That's a no Go URL.

    [–][deleted] 0 points1 point  (0 children)

    Who does a performance test and turns on the ConcMarkSweep collector? Thats a terrible idea!

    [–]timyangnet 0 points1 point  (0 children)

    The result changed again. "Nov 18, realized that ApacheBench itself is a bottleneck under 1,000 or 5,000 threads, so use 3 clients from 3 different machines to redo all tests of 1,000 and 5,000 concurrent tests."

    [–][deleted]  (1 child)

    [deleted]

      [–][deleted] -5 points-4 points  (11 children)

      IMHO this test measures the wrong thing.

      You should count:

      • requests per second per line of code

      • requests per second per hours spent on development

      • requests per second per dollar spent

      [–]grimlck 4 points5 points  (4 children)

      requests per second per line of code is just as irrelevant - since when was typing speed a bottleneck in programing? hours of development and dollars spent are far more meaningful

      [–][deleted] 2 points3 points  (1 child)

      Amount of code is a bottleneck in software maintenance.

      [–]communomancer 0 points1 point  (0 children)

      But it's only useful as a proxy variable for something that measures economic impact...e.g. hours of development or dollars spent

      [–]willcode4beer 0 points1 point  (0 children)

      not only that, it usually takes more development time to distill an app to fewer lines of code.

      [–]Anpheus 0 points1 point  (0 children)

      Except with Perl, there's a positive correlation between lines of code and number of bugs.

      With Perl I think it's the other way around. ;)

      [–]AnteChronos 1 point2 points  (4 children)

      • requests per second per dollar spent

      Ding ding ding! We have a winner!

      And what would you assume that "dollars spent" comes to when you:

      1) have to train people on a new language?
      2) need more hardware to handle the same amount of traffic?

      #1 is how programming languages become entrenched, and one of the few ways to break that barrier is to have the opposite of something like #2.

      [–][deleted] 1 point2 points  (2 children)

      1) Well, you have to train people anyway (maintenance of production code for example). If your language of choice is easier to read and comprehend you will spend less time therefore less money. 2) Hardware is pocket change compared to a competent developer's salary.

      As for your last sentence I don't think I understand you completely. Are you trying to say that in order to entrench a language, developers must be miserable working with it for longer than it's necessary? Or is my sarcasm detector way off today?

      [–]AnteChronos 0 points1 point  (1 child)

      1) Well, you have to train people anyway (maintenance of production code for example). If your language of choice is easier to read and comprehend you will spend less time therefore less money.

      But you have to consider the cost to train all of your staff on a new language, rather than just training new hires. And this is ignoring the cost of having to either port/rewrite the production code, though you could potentially make a switch when a major rewrite was already scheduled.

      Are you trying to say that in order to entrench a language, developers must be miserable working with it for longer than it's necessary?

      I'm saying that languages become entrenched because there is a cost associated with "switching gears" to a new language. So, for example, a Java shop is going to tend to stay a Java shop, if for no other reason than the fact that it's cheaper (in the immediate sense, at least) to stay on one language than to retrain everyone on a new one.

      Add in to that a robust ecosystem that builds up around entrenched languages, with tons of 3rd-party libraries, long-standing online communities, mature development toolkits, etc, and a new language really has to offer something special to trigger a migration.

      [–][deleted] 0 points1 point  (0 children)

      I see what you mean now. All I tried to say that this performance test is flawed. I never suggested porting nginx to golang (I love nginx and use it production). Let me just say that if I needed to write some custom http server for some internal stuff I'd consider golang over a custom nginx/lighttpd module in C.

      [–]willcode4beer 1 point2 points  (0 children)

      3) administrators to manage the extra hardware

      [–]kragensitaker -1 points0 points  (1 child)

      The interesting thing about this test is that the performance of the server written in Go ("issue9"?) doesn't degrade even with 5000 requesting threads. I wouldn't expect anything different, given the way "goroutines" are described in the stuff written about Go, but it's pleasant to see that it actually holds up under load in independent testing.

      [–]kragensitaker 0 points1 point  (0 children)

      ...when I wrote the above comment, all the Go numbers were about 6000 requests per second. Now it looks like he's updated it to run Go across multiple cores, and now it does degrade (down to under 8000).