Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

hhtp mux performance question

146 views
Skip to first unread message

christoph...@gmail.com

unread,
Apr 28, 2025, 12:28:25 PMApr 28
to golang-nuts
I have created web site with a middleware measuring the execution time of requests using the time.Since(start) method. It is thus using the wall time.

I see that the execution of the ServeHttp() is around 60μs. The handler is a function that simply renders the login page that I benchmarked to use at most 1μs.

The time difference seams huge. The server is idle and receiving only one request at the time. I know that measuring execution time with a wall clock on a time sharing system is not a great, but I have 8 cores and they are mostly idle. I apparently don’t have a better method.

I also saw a big jitter which was reduced by adding the instructions

runtime.LockOsThread()
defer runtime.UnlockOsThread()
runtime.GOMAXPROCS(1)

But I still see the big execution duration.

Unfortunately, I can’t benchmark the ServeHttp() method has the object is complex (db, etc.).

Is there a more precise way to measure the execution time Such big values don’t seam very accurate.

christoph...@gmail.com

unread,
Apr 29, 2025, 5:58:07 AMApr 29
to golang-nuts
More strange result.

With Firefox, the time measured with time.Since is 55μs on average, and with Chromium it’s on average 200μs but with a big jitter. It’s not the OS (Ubuntu 2.24LTS) load that changes as both browsers are running side by side. How can the ServeHttp processing time change (~ x4) depending on the browser ? 

Robert Engels

unread,
Apr 29, 2025, 8:05:40 AMApr 29
to christoph...@gmail.com, golang-nuts
Hi. Unless you provide a standalone test program it will very difficult for anyone to assist you. 

On Apr 29, 2025, at 5:03 AM, christoph...@gmail.com <christoph...@gmail.com> wrote:


--
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...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/1b79e5c8-3c2c-4b43-b24e-16252dfdf3cdn%40googlegroups.com.

christoph...@gmail.com

unread,
Apr 29, 2025, 10:52:56 AMApr 29
to golang-nuts

Here is a minimal program that I tried out: https://go.dev/play/p/Rp03LxuvDVw . Note that it measures the duration of w.Write(msg).

On my local host I displayed the web page http://localhost:8080/firefox with Firefox, and http://localhost:8080/chromium with chromium. I don’t have chrome installed. My computer is "idle", as far as I can tell.

Here are four requests by chromium:

url: /chromium duration: 2.5µs
url: /favicon.ico duration: 1.128µs
url: /chromium duration: 2.334µs
url: /favicon.ico duration: 991ns
url: /chromium duration: 2.568µs
url: /favicon.ico duration: 1.143µs
url: /chromium duration: 2.904µs
url: /favicon.ico duration: 1.654µs


Here are four requests by firefox on the same host in the exact same condition:
url: /firefox duration: 1.094µs
url: /firefox duration: 1.979µs
url: /firefox duration: 894ns
url: /firefox duration: 1.125µs


I’m aware that I use the wall time which is not OK for benchmarks. I just want to understand why it takes so long, and why is chromium twice slower ?

Is there a scheduling switch just in the w.Write(msg) or time.Now() ?

My CPU frequency is only 0.80Ghz showing that it’s not doing much.

robert engels

unread,
Apr 29, 2025, 12:17:12 PMApr 29
to christoph...@gmail.com, golang-nuts
You can’t time things this way. The duration is so short, you are going to be heavily affected by what else is happening on the system, and especially thermal/energy throttling.

Read up on writing low-level performance benchmarks. This article seems decent: https://leveluppp.ghost.io/how-to-lie-with-benchmarks/



robert engels

unread,
Apr 29, 2025, 12:23:06 PMApr 29
to christoph...@gmail.com, golang-nuts
Also, Chromium is not twice as slow, in fact 991 ns against 894 ns, is a difference of 7 nanos…. shorter than most cache reads. It is this sort of evidence that should be a red flag that your benchmark is broken.

Further, for things like http, it could be simply that Chromium sends more headers - the server has to process them… You should start by recording the actual bytes sent by the browser - the browser development tools can be used to inspect this.

It could also be that one or the other is using http2 vs http - again, use the browser tools to make sure you are comparing the same thing.

You can also run your test using ‘curl’ as a third data point.

On Apr 29, 2025, at 9:52 AM, christoph...@gmail.com <christoph...@gmail.com> wrote:

Reply all
Reply to author
Forward
0 new messages