[go-nuts] Comparing Java (based tech stack) ang Go (standalone) performance as a Web server

This surely depends on the implementation of both the Java and the Go
services.
In cases where the communication overhead is bigger than the actual work,
latency will increase with concurrency (not only in Go, but in general).
Can you provide the source code?

According to the first part of the blog the code is here:
https://github.com/collinvandyck/go-and-java

It doesn't look like there's any explicit synchronization happening - can I
assume that the concurrency is being managed by the http.Handle call? I'm
not familiar with the net/http API.
Did you ever profile this code to see where the latency is coming from?

I don't know if it will help his particular case but there has been
significant performance work, and much still to come, that has a
dramatic effect on the performance of some benchmarks like this. Even
what's at tip now is much faster than go1.0.2 because of changes to
the compiler and run-time.

Leaving aside the general unreliability of benchmarks.

-rob

--

Your post says "as a web server", but you are also making calls to an sql
server.
If you wanted to measure web serving you should take out all the sql calls
and serve up static files.

--

I think the test author is not a part of this thread. I forked the code at
https://github.com/patrick-higgins/go-and-java and have confirmed that DB
access is not the same between the two implementations. Using prepared
statements in Go doubled throughput in my very simple testing.

--

hmm, that's interesting ... because the author uses db.Query(), which uses
db.Prepare() under the covers ...

374 func (db *DB) Query(query string, args ...interface{}) (*Rows, error) { 375 stmt, err := db.Prepare(query)

Yep, and that means it has to do a db.Prepare() for every query which
requires an additional round trip to the database.
The database driver could cache this itself, but it doesn't.

I'm glad it doesn't cache, since caching increases complexity and adds more
processing time and memory usage in the best case (when caching isn't
needed). Since Go encourages a "culture of competence" much more so than,
say, Java, we enjoy lower overhead (semantic overhead, at the very least),
we don't mollycoddle those who don't understand what they're doing at the
expense of those who do.

To be honest, almost all of the benchmarks (especially in blogs) that I've
seen concerning Go are from those who are just first trying out the
language, and are not in a position to do it any kind of justice. The
stress on benchmarks, for me, is a sign that they may have gotten so far as
to learn the syntax, but not the _language_, and so they don't yet know
what Go really has to offer. Those who have well integrated into the Go
mindset often do not to care either way: they know the performance is
competitive and they know how to make reasonable effort-to-efficiency
tradeoffs, and even if it was not nearly as efficient, they may still have
reservations "going back" to their previous language, since performance is
hardly our only feature.

Without even optimizing anything, I highlighted a few issues and different
results here:

http://boundary.com/blog/2012/09/17/comparing-go-and-java-part-2-performance/#comment-655206246

I may continue a little more after dinner... maybe.

--

Are there any plans to make the database connection pool size configurable?

Why is it that in raggi's test, Go lit up only 2 cores while Java used all
8? Was GOMAXPROCS not set to a large enough value?

On my system Go beats Java with all the tools except ab. I have always
suspected ab but can't really say why...

Everything run locally.

Java 1.7 (latest from Oracle and after warmup)
Request rate: 4360.1 req/s (0.2 ms/req)

Go go1.0.2
Request rate: 7044.9 req/s (0.1 ms/req)

Tip (version devel):
Request rate: 8424.2 req/s (0.1 ms/req)

This was taken from httperf output and may or may not be relevant but
saying that Java "wins" is clearly not the whole truth at least
The results from ab is different and Java heads it and for siege it is a tie.

The observation that the Go program don't saturate the cores is true
here at least. No matter the GOMAXPROCS setting it is fairly low on
CPU. The Java version does not do much better but clearly more cpu is
used even when the result is worse.

These little benchmarks are a fun distraction but I agree with the
general consensus that real metrics are really hard to produce and
even harder to trust.

/ Henrik