goblin VS pprof

Up until now, I have been using a homemade HTTP router called goblin in my application, but since the ServeMux functionality has been expanded in Go1.22, I have started using ServeMux. It became so.

Regarding bmf-san/goblin, we found that it is a proprietary extension of the tri-tree, which is not very optimized and has poor performance compared to other HTTP Routers. (We will do our best to improve it...)

When I decided to improve the performance of goblin, a homebrew HTTP Router, I tried to work on performance improvement in Go, so I write about my approach and the efforts I put into practice.

goblin

goblin is an HTTP router made by golang based on the trie tree.

From the above code, if you read the net / http code with the following points in mind, you can see what to implement. - Where and how the multiplexer registers handlers, and what are the specifications for matching URLs and patterns? - How to create a handler (whether there is a variation of handler creation, what interface should be satisfied) Details [bmf-tech.com-Chapter 3 HTTP Server Code Reading] (https://bmf-tech.com/posts/net%EF%BC%8Fhttp%E3%81%A7%E3%81%A4 % E3% 81% 8F% E3% 82% 8BHTTP% E3% 83% AB% E3% 83% BC% E3% 82% BF% E3% 83% BC% E8% 87% AA% E4% BD% 9C% E5 % 85% A5% E9% 96% 80 #% E7% AC% AC3% E7% AB% A0HTTP% E3% 82% B5% E3% 83% BC% E3% 83% 90% E3% 83% BC% E3% 81% AE% E3% 82% B3% E3% 83% BC% E3% 83% 89% E3% 83% AA% E3% 83% BC% E3% 83% 87% E3% 82% A3% E3% 83% B3% E3% 82% B0), so please refer to it if you have time. # Implementation As I introduced at the beginning, the HTTP router implemented this time is in the following repository. [bmf-san/introduction-to-golang-http-router-made-with-net-http] (https://github.com/bmf-san/introduction-to-golang-http-router-made-with- net-http /) This time we will implement a simple HTTP router that "supports method-based routing". * Since it is a summary version, detailed explanation of the code is omitted. Method-based routing means that you can register URLs by HTTP method. In the function of Go standard package only, if you want to route by method, you need to implement conditional branching in the handler. `` `go // ex. func indexHandler (w http.ResponseWriter, r * http.Request) { switch r.Method { case http.MethodGet: // do something ... case http.MethodPost: // do something ... ... default: default: `` ``` This time, we will implement it only with the goal of eliminating this trouble. In order to achieve method-based routing, we will adopt a tri-tree-based data structure. Since it is a simple function, a simpler data structure (such as making it possible to use the standard multiplexer function for each method) is fine, but we will adopt it in anticipation of various implementations later. (To be honest, I just simplified the implementation of [bmf-san / goblin] (https://github.com/bmf-san/goblin).) The general things to do in implementing an HTTP router are as follows. - Process to add URL and handler mapping to data structure - https://github.com/bmf-san/introduction-to-golang-http-router-made-with-net-http/blob/main/trie.go#L51 - Process to search for matching data from the mapped data structure (≈ tri-tree-based data structure) - https://github.com/bmf-san/introduction-to-golang-http-router-made-with-net-http/blob/main/trie.go#L93 --Implementation of DSL for registering mapping - Around here https://github.com/bmf-san/introduction-to-golang-http-router-made-with-net-http/blob/main/router.go#L47 - Implementation of function as a multiplexer (≈ implementation of ServeHTTP) - https://github.com/bmf-san/introduction-to-golang-http-router-made-with-net-http/blob/main/router.go#L54 The first thing you want to do to implement is to implement the data structure. ! [tree_for_implementation] (https://user-images.githubusercontent.com/13291041/138551924-ca2e28f5-a0c1-4ae4-ac9f-76d6ee1c46d9.png) It is easier to work if you use the debug function of the editor (using delve in vscode) or write test code to check if it is implemented well. For implementation details, see [bmf-tech.com-Chapter 4 HTTP Router Implementation] (https://bmf-tech.com/posts/net%EF%BC%8Fhttp%E3%81%A7%E3%81] % A4% E3% 81% 8F% E3% 82% 8BHTTP% E3% 83% AB% E3% 83% BC% E3% 82% BF% E3% 83% BC% E8% 87% AA% E4% BD% 9C % E5% 85% A5% E9% 96% 80 #% E7% AC% AC4% E7% AB% A0HTTP% E3% 83% AB% E3% 83% BC% E3% 82% BF% E3% 83% BC% See E3% 81% AE% E5% AE% 9F% E8% A3% 85). # Summary HTTP routers are almost indispensable for creating web applications, and aren't they very much taken care of? My motivation was that I wanted to make something that I used as a matter of course and use it myself. There are already a lot of great HTTP routers out there, so I think one of the real thrills is that it's worth researching. This time I implemented it in Go, but if I understand the mechanism, I think that it can be implemented in languages ​​other than Go. In Go, the interface is provided in a form that makes it easy to extend the function of the standard package, so I felt that it was relatively easy to make by myself. If you are interested in this article, I would be grateful if you could take a look at [bmf-san/goblin] (https://github.com/bmf-san/goblin). Feel free to send an Issue or Pull Request. :D

The author has released an HTTP router package called bmf-san/goblin.

The pprof format is not tied to Go. From my understanding, it's used within Google across multiple languages. The format is defined in the pprof repository[0], and the visualization tool is source-language agnostic. I've seen libraries in numerous languages (e.g. Python, Java) to publish profiles in pprof format. This is an indicator the pprof format has become de-facto. Grafana Pyroscope[1] is a tool that's capable of parsing the pprof format, agnostic to the source programming language, and has instructions for Go, Java, Python, Ruby, node.js, Rust, and .NET.

My understanding is that you're searching for a combination of the profiles, metrics, and tracing. Caddy supports all 3.

[0] https://github.com/google/pprof/blob/main/doc/README.md

[1] https://grafana.com/docs/pyroscope/latest/

metrics and tracing need to be manually enabled (for now, perhaps)

Because we couldn't identify the issue using the results we got from Callgrind, we reached for another profiler, gperftools. It's a sampling profiler and therefor it has a smaller impact on the application's performance in exchange for less accurate call statistics. After filtering out the unimportant parts and visualizing the rest with pprof, it was evident that something strange was happening with the send function. It took only 71 milliseconds with the previous implementation and more than 900 milliseconds with the new implementation of our Bolt server. It was very suspicious, but based on Callgrind, its cost was almost the same as before. We were confused as the two results seemed to conflict with each other.

github.com - google/pprof

The application performances in a specific code path (e.g. gdb, pprof, …).

pprof is https://github.com/google/pprof, it's a very useful tool in golang , and really really really convenient

Go also has pretty good out of the box profiling (pprof[0]) and third-party runtime debugging (delv[1]) that can be used both remotely and local.

These tools also have decent editor integration and can be use hand in hand:

https://blog.jetbrains.com/go/2019/04/03/profiling-go-applic...

https://blog.jetbrains.com/go/2020/03/03/how-to-find-gorouti...

[0] https://github.com/google/pprof

[1] https://github.com/go-delve/delve

And what we do in Google Cloud is that we still use the pprof. But it's a kind of forked version of the pprof because the visualization part is totally different. So we give that tool as the Cloud Profiler. So that is the product name. And then, the difference between the pprof and a Cloud Profiler is that Cloud Profiler provides the agent library for each famous programming language such as Java, Python, Node.js, and Go. And then what you need to do is to just write 5 to 10 lines of code in a new application. That launches the profile agent in your application as a subsidiary thread of the main thread. And then, that thread periodically collects the profile data of the application and then sends that data back to Google Cloud and the Cloud Profiler.

gprftools (https://github.com/gperftools/gperftools) can be easily plugged in using LD_PRELOAD and signal, and has nice go implemented visualization tool https://github.com/google/pprof.