Comparing Java (based tech stack) ang Go (standalone) performance as a Web server

[Anssi Porttikivi]

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

Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven has some optimzations to make it faster than Go http?  

[Raph]

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?

[Chris Hines]

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

[Rob Pike]

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

[Raph]

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?

[bryanturley]

On Tuesday, September 18, 2012 9:46:35 AM UTC-5, Anssi Porttikivi wrote:

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

Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven has some optimzations to make it faster than Go http?  

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.

[Patrick Higgins]

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.

[Jesse McNelis]

On Wed, Sep 19, 2012 at 11:39 AM, <brad.ry...@gmail.com> wrote:
> hmm, that's interesting ... because the author uses db.Query(), which uses
> db.Prepare() under the covers ...
>
> func (db *DB) Query(query string, args ...interface{}) (*Rows, error)
> {
> 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.
--
=====================
http://jessta.id.au

[Kevin Gillette]

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.

[Sam Freiberg]

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

On Sep 18, 2012, at 8:58 PM, ra...@google.com wrote:

On Tuesday, September 18, 2012 7:46:35 AM UTC-7, Anssi Porttikivi wrote:

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

Any thoughts on that? Why is the Go alternative slower? Maybe Apache Maven has some optimzations to make it faster than Go http?  

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.

--
 
 

[Chandru]

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?

--
Chandra Sekar.S

--
 
 

[Henrik Johansson]

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

> --
>
>