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. Le mardi 29 avril 2025 à 14:05:40 UTC+2, Robert Engels a écrit : > 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: > > > > 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 ? > > > > Le lundi 28 avril 2025 à 18:28:25 UTC+2, christoph...@gmail.com a écrit : > >> 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. >> > -- > 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 > > <https://groups.google.com/d/msgid/golang-nuts/1b79e5c8-3c2c-4b43-b24e-16252dfdf3cdn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/e4c1ce28-7a2e-4d96-a9d1-5f7dd482ba90n%40googlegroups.com.
