Goのnet/httpのkeep-aliveで気をつけること - Carpe Diem
概要 Idle connectionをプールするkeep-aliveの仕組みですが、Goで適切に使用するためにはいくつか注意があります。 環境 golang/go 1.13.1 TCP Keep-Aliveの挙動をパケットキャプチャで確認する 例えば以下のようにDefaultTransportの一部の設定（①、②）をイジってリクエストを送ると client = &http.Client{ Transport: &http.Transport{ DialContext: (&net.Dialer{ Timeout: 30 * time.Second, KeepAlive: 10 * time.Second, // ① DualStack: true, }).DialContext, ForceAttemptHTTP2: true, MaxIdleConns: 100, IdleConnTim
Golang Memory Management: Allocation Efficiency in Go Services
Want to stay updated on Segment launches, events, and updates? Subscribe below to keep in touch. We’ll share a copy of this guide and send you content and updates about Twilio Segment’s products as we continue to build the world’s leading CDP. We use your information according to our privacy policy. You can update your preferences at any time. Memory management in Golang can be tricky, to say the
Debugging Latency in Go 1.11
It is complicated to diagnose and debug complicated systems. It often takes multiple levels of diagnostics data to understand the possible causes of latency issues. A distributed system is made of many servers that are depending on each other to serve a user request. At any time, A process in the system might be handling a large number of requests.In highly concurrent servers, there is no easy way
go tool traceでgoroutineの実行状況を可視化する - ( ꒪⌓꒪) ゆるよろ日記
こんにちわ。しいたけです。今日はgoroutineの実行状況をいいかんじに可視化するツールの話です。 goのプロファイリングツールと言えば、 runtime/pprof や net/http/pprof ですよね。これらの使い方はググればすぐに出てくるのですが、 詳細なtraceを取得して可視化できる runtime/trace については、日本語の情報が殆ど無いので書いてみましいたけ。 runtime/trace はgoroutineの実行状況やsystem callのイベント、Heapやnetworkの状況をこんな感じに可視化してくれるので便利です。 これは自作のクローラーを動かしている際のtraceを可視化したもので、横軸がタイムラインになっており、上段に Heapの使用状況やgoroutineとos threadの数が, 下段はnetworkやProccesor(GOMAXPROC
golang で string を []byte にキャストしてもメモリコピーが走らない方法を考えてみる - Qiita
package main import ( "unsafe" ) type foo struct { k int64 v int64 } func main() { f := &foo{3,4} // unsafe.Pointer() で匿名ポインタにして // uintptr() で演算可能にして // +8 バイト(64bit)足して // unsafe.Pointer で匿名ポインタに戻して // そこにはフィールド v があるはずなので *int64 にキャストして // デリファレンスすれば出来上がり *(*int64)(unsafe.Pointer((uintptr(unsafe.Pointer(f))+8))) = 5 // ｸﾞﾋﾋ println(f.v) // 5 } 0x001c 00028 (stringbytes2.go:8) LEAL go.string."he
![golang で string を []byte にキャストしてもメモリコピーが走らない方法を考えてみる - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4325e244cbc258effc8fe14ac7952c6256aa0ede/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9Z29sYW5nJTIwJUUzJTgxJUE3JTIwc3RyaW5nJTIwJUUzJTgyJTkyJTIwJTVCJTVEYnl0ZSUyMCVFMyU4MSVBQiVFMyU4MiVBRCVFMyU4MyVBMyVFMyU4MiVCOSVFMyU4MyU4OCVFMyU4MSU5NyVFMyU4MSVBNiVFMyU4MiU4MiVFMyU4MyVBMSVFMyU4MyVBMiVFMyU4MyVBQSVFMyU4MiVCMyVFMyU4MyU5NCVFMyU4MyVCQyVFMyU4MSU4QyVFOCVCNSVCMCVFMyU4MiU4OSVFMyU4MSVBQSVFMyU4MSU4NCVFNiU5NiVCOSVFNiVCMyU5NSVFMyU4MiU5MiVFOCU4MCU4MyVFMyU4MSU4OCVFMyU4MSVBNiVFMyU4MSVCRiVFMyU4MiU4QiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1jbGlwPWVsbGlwc2lzJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9Y2FmZjBiMzlhY2M1NGY2MzExODNjOGIyZDE0MjhkNjg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbWF0dG4mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWY5MWFmZGNhMGU4OGEwYzI0MjkzY2ZjZjA3YWM3OTQx%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Db3ecaedb191e67ec7bd1fc1f028687a1)
The complete guide to Go net/http timeouts
The complete guide to Go net/http timeouts Loading... When writing an HTTP server or client in Go, timeouts are amongst the easiest and most subtle things to get wrong: there’s many to choose from, and a mistake can have no consequences for a long time, until the network glitches and the process hangs. HTTP is a complex multi-stage protocol, so there's no one-size fits all solution to timeouts. Th
Accelerating real applications in Go
Accelerating real applications in Go golang.tokyo #3 ~Performance~ 26 January 2017 Tatsuhiko Kubo Profile @cubicdaiya (GitHub) Principal Engineer, SRE @ Mercari, Inc. Favorites: nginx, Go, C, Lua 2 Softwares in Go Server middlewares and command-line tools. Gaurun - Push notification server widebullet - API gateway by JSON-RPC slackboard - Proxy server and client for Slack nginx-build - Seamless ng
High Performance Go Workshop
High Performance Go Workshop Mercari 11 April 2018 Dave Cheney License and Materials This presentation is licensed under the Creative Commons Attribution-ShareAlike 4.0 International licence. The materials for this presentation are available on GitHub: github.com/davecheney/high-performance-go-workshop You are encouraged to remix, transform, or build upon the material, providing you give appropria
Writing High Performance Go
Writing High Performance Go GopherChina 17 April 2016 Dave Cheney Welcome 您好! Thank you for coming to my talk. Thank you also to the GopherChina organisers for inviting me to speak. My name is David. I'm a Go programmer from Sydney, Australia. I'm a contributor to the Go project and I run the Sydney Go Users' group. 2 Agenda This talk is aimed at development teams who are building production Go ap
GolangでFlame Graphを描く
アプリケーションのパフォーマンス問題の解決やチューニングで大切なのは問題のコアやボトルネックに最短パスで到達することである． 基本的なパフォーマンス分析の入り口はアプリケーションのスレッドがon-CPUで時間を消費しているかoff-CPUで時間を消費しているかを理解するところから始まる．on-CPUの場合はそれがuserモードかkernelモードかを特定し，さらにCPUプロファイリングによってどのcode pathがCPUを消費しているのかの分析に向かう．off-CPUの場合はI/OやLock，pagingといった問題の分析に向かう． Flame Graphはon-CPUでのパフォーマンスの問題が発覚した時に行うCPUプロファイリングを助ける．どのcode pathがボトルネックになっているのかを1つのグラフ上で理解できる．本記事ではFlame Graphとは何か? なぜ必要なのか? を解
Go Conference 2014 Autumn、その他のセッションのまとめ | gihyo.jp
前回の記事では、3つのセッションについてレポートを記しました。この記事では、残りのセッションについてまとめたいと思います。 Why my Go program is slow?（@methane氏） このセッションでは、@methane氏からpprofというCPUプロファイラとGo言語におけるパフォーマンスチューニングについての話がされました。なお、このセッションの発表資料は、以下のURLから閲覧することができます。 http://www.slideshare.net/InadaNaoki/gocon2014-pprof 写真1 @methane氏の発表の様子 サンプリングプロファイラ pprofはサンプリングプロファイラで、一定時間ごとにCPUがどこを処理しているかというサンプルを取ることでプロファイリングを行うそうです。そのため、多くのサンプルが取れた関数は時間がかかっているということ
Golang パフォーマンスチューニング - Qiita
この記事は Go Advent Calendar 2014 17 日目の記事です。 Go におけるパフォーマンスチューニングの話をします。 これらは Denco や Kocha などでのパフォーマンスチューニングの経験などから得た知見です。 処理系の話ではありませんのでご了承ください。 前提 プロファイリングを取った後、じゃあどうやって最適化するかというところの話です 「推測するな、計測せよ」 アルゴリズムやデータ構造は最適なものが選択されていると仮定します 小手先の最適化を行うよりアルゴリズム自体を変えたほうが圧倒的に良くなります。 この記事の各ベンチマークは Go 1.4 （go version go1.4 linux/amd64）で下記のコマンドにて取っています
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - davecheney/high-performance-go-workshop
GoCon 2016.04 MO Game Server
コネクションプールのチューニング - Qiita
High Performance Backend For Mercari