Just to clarify some facts. On Sun, Jun 9, 2019 at 11:09 AM 'Axel Wagner' wrote: > > As I've also mentioned: I don't think this test is meaningful. > > First, as it has been pointed out, your Perl program isn't actually a web > server. It only understands ridiculously simple requests and as such violates > the spec left and right. It's also super naive in how it treats malformed > input or actively malicious clients - all of which are handled by the Go http > package, so of course it's going to have some overhead.
There is a second test well before your this post, which is a direct translation of Perl code, that is now reading and writing directly to a socket. Hanging on to the first test method and not referring to the second test is not a very constructive way of discussion, let alone using words like "ridiculously ...". > In its most generous form, you translate the programs faithfully to do the > same syscalls and implement the same logic - and at that point, you are > essentially benchmarking the Perl regular expression engine against the Go > regular expression engine, as that's the only thing the program really is > doing: Branching on a regexp-match. And the Perl RE-engine is famously > optimized and the Go RE-engine famously is not. In fact, you aren't even > benchmarking Perl against Go, you are benchmarking *C* against Go, as Perls > RE-engine is written in C, AFAIK. Over 90% of the code are NOT doing regular expression matching. Focusing *only* on regular expression, not >90% of the rest, is not very convincing but miss the elephant in the room, at least seems to me. Many people have given valid inputs as where things might get improved, including the one you are quoting. > Lastly, as I read the results I get with either net/http *or* the naive > regexp-parsing, I just… disagree with your conclusions. All the numbers I've > seen seem to imply that Go responded *on average* a lot faster and *might* > have higher variance and a slightly higher tail latency (though, FTR, the > measurements I got also suggest that the data is mostly noise). And I'm > struggling to find an application, where that would matter a lot. Like, yeah, > tail latency matters, but so does average latency. In basically all > applications I can think of, you a) want tail latencies to not be > catastrophic, especially when considering fan-out, but b) lower averages are > just as important anyway. So, I think you should, for a decent test, > formulate your criteria beforehand. Currently, there seems to be a lot of > reading in tea-leafs involved. Please don't get personal and emotional over technical discussions, and please refrain from using terms like "ridiculously simple" or "reading in tea-leafs" in future discussions. It is inappropriately condescending, thus not the correct attitude of communication. It does not align with the code of conduct of this mlist, and neither of google's, I believe. If you have test results that contradict with mine, please show me yours -- Let's talk the data, and not let the emotion get in the way of technical discussion, and fact the fact, whatever it is. > Anyway, all of that being said: While I don't think the test you devised > allows the broad generalizations you are making, ultimately I don't have any > stakes in this (which is why I haven't responded further on the blog post). > If you like Perl and think it performs good enough or better for your use > case - then go ahead and use Perl. No one here will begrudge you for it. As I've comment in the blog many times, I'm not trying to prove Perl performs better than Go. On the contrary, I was trying to improve Perl performs with Go, that's why the whole thing get started, as I have replied to your comment in the blog:"that's why I was rewriting the Perl code to Go". It is still the case, and I want to try out everyone's suggestion to see how things can improve. Moreover, if you have taken a look at my second test, you will understand my other goal is to make it clear "who and what to trust". Because if you have taken a look at the httperf test result I posted to this mlist before you reply, you may have realized that, of all the performance testing tools I've used so far, all are suggesting Perl performs better than Go, except for httperf. So maybe the performance testing tools are biased toward Go, and I made it clear in my second blog that I want to get to the bottom of it. > All of that being said > > IMO this is just not a meaningful test. Or its results are totally > unsurprising. Again, I was trying to improve Perl performs with Go. That "ridiculously simple" Perl code is the foundation of the Debian dbab package, and I was trying to improve it. It might be meaningless to you but it is perfectly meaningful to me. Please don't be so judgmental. > On Sun, Jun 9, 2019 at 4:54 AM Justin Israel <justinisr...@gmail.com> wrote: >> >> I'm wondering about a couple factors in this comparison that seem to make a >> difference in my local test: >> >> I think perl sockets are write buffered. So would the equivalent be to wrap >> the net.Conn in bufio.NewWriter(c) and flush before the Close? >> Since this is a straigh-line test where both servers are not using >> concurrent handling of connections (uncommon for a Go server even on 1 >> core), would it not make sense to run the Go server with GOMAXPROCS=1? >> >> - Justin >> >> On Saturday, June 8, 2019 at 1:36:49 AM UTC+12, Tong Sun wrote: >>> >>> I had always believed that the web projects build with Go should be much >>> faster than Perl, since Go is a compiled language. >>> >>> However that belief was crushed brutally last night, when I did a >>> comparison -- the Go implementation is 8 times worse than the Perl! -- the >>> mean response time jumped from 6ms to 48ms. >>> >>> I know this is the simplest possible web server, but still, when it comes >>> to simple web servers like this, I have to say that Perl performs much >>> better than Go. >>> >>> I don't think there is much I can twist on the Go side, since it can't be >>> more simpler than that. However, I also believe it won't hurt to ask and >>> confirm. So, >>> >>> Have I missed anything? Is it possible for me to make my Go implementation >>> anywhere near the Perl's performance? >>> >>> Thanks >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/37a1ac7e-85ee-4775-b348-5673c41a162c%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/iH2Ck_hpCpI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF62D5v%2BRiGtAtzuH0wAHzCLqcwNUidC1Oe2KN9DfRv6Q%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMmz1OcefkrZN3_5R7%2BbjuwHjRx%2BLzttaiXmer0ytwmXUjxN_A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
