hhtp mux performance question
134 views
Skip to first unread message
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.
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
Apr 29, 2025, 3:05:40 PM (8 days ago) Apr 29
to [email protected], 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, [email protected] <[email protected]> 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 [email protected].
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/1b79e5c8-3c2c-4b43-b24e-16252dfdf3cdn%40googlegroups.com.
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).
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
Apr 29, 2025, 7:17:12 PM (8 days ago) Apr 29
to [email protected], 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
Apr 29, 2025, 7:23:06 PM (8 days ago) Apr 29
to [email protected], 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, [email protected] <[email protected]> wrote:
Reply all
Reply to author
Forward
0 new messages