Go1.9から使える Monotonic Clocks を試してみた
先日Go1.9beta1がリリースされました。 Go 1.9 Beta 1 is released! Announcement:https://t.co/lV5nvXwOoR Get it!https://t.co/2LhlOo2EtX#golang pic.twitter.com/zm09DwX93q — Go (@golang) 2017年6月14日 Go 1.9 Release Notes 型エイリアスのサポート、math/bitsパッケージ、 sync.Map型など、 今回のアップデートでも便利そうな機能が追加されます。 詳しくはtenntennさんのGopher Fest 2017参加レポートをどうぞ。 今回のリリースノートを見て、個人的に注目しているのはMonotonic Clocksのサポートです。 他の機能追加はTwitterとかで見かけるけど、 Monotonic Cl
Re: GoとPythonとGrumpyの速度ベンチマーク
GoとPythonとGrumpyの速度ベンチマーク ～Googleのトランスパイラはどれくらい速い？～という記事を拝読したのですが、 もう一歩踏み込んで検証して欲しい・・・。 並列処理性能が優れているほか、PythonコードからGoのパッケージをPythonモジュールのように呼び出して利用することもできるという特徴がある。 とGoogle、すごくスケールするPython実行環境をGoで開発から引用しているのに、 この件に全く触れていないんですよね。 Twitterに呟いたってどうせ誰もやってくれない気がするので、自分で試してみました。 環境 この記事を書いている2017年5月30日現在の最新バージョンで検証しました。 go version go1.8.3 darwin/amd64 CPython 2.7.13 Grumpy d8d01899f5 Grumpyのインストール方法はREADME
Go言語のヒープに確保するデータの初期化コストについて調べてみた(Go1.8.1版)
golangで p := new(Type) と p := &Type{} の使い分けってどうするべきだろう? — MURAOKA Taro (@kaoriya) 2017年4月12日 こちらのツイートに対して、以下のベンチ結果が紹介されていました。 Go言語のヒープに確保するデータの初期化コストについて調べてみた しかしhnakamur2さんも言及しているように、 これはGo1.2.2時の結果。 その後、GoのコンパイラがGo実装になったり、SSAが導入されたりと、 今のコンパイラの実装は当時とは全く違うものになっています。 というわけで、現時点での最新のバージョン(Go1.8.1)で、同様の検証をおこなってみました。 検証コード 検証に使用したコードはGo1.2.2のときと全く同じものです。 // alloc_overhead.go package main type containe
Redisを使ってユニークなIDを配布する
スケーラブルにIDを生成する方法として Twitterのsnowflakeが有名です。 1024台までスケールすることが出来ますが、各snowflakeのサーバにユニークなWoker IDを割り振る必要があります。 IDを振るためのサーバにIDを振るのが問題になるとは難しいですね。 各snowflakeサーバにIDを振る親玉Worker ID配布サーバを作るというアイデアはあったのですが、 Worker IDサーバの可用性を考えるのが大変で手を付けていませんでした。 最近になってWorker IDサーバとしてRedisを使い、ソート済みセット型で管理すれば楽できるのでは？ と思いついたので、やってみたというお話です。 概要 レポジトリはこちらです。 shogo82148/yaraus 他のsnowflake-likeなID発番サーバの実装として katsubushiや sonyflakeな
Go言語のchanはいったいいくつ付けられるのか試してみた
pecoに入った修正をみて、果たしてchanはいくつまで付けられるのか気になったので、 雑に試してみました。 先に断っておきますが、全く有用ではないですよ。 背景 pecoに入った修正はこちら(一部抜粋)。 Make Resume a blocking operation #411 diff --git a/interface.go b/interface.go index 3d4472f..fff446c 100644 --- a/interface.go +++ b/interface.go @@ -162,8 +162,8 @@ type Screen interface { // Termbox just hands out the processing to the termbox library type Termbox struct { mutex sync.Mutex -
go-sql-proxyがcontextに対応しました
Go1.8ではdatabase/sqlのcontextサポートが入ります。 (きっと今日のGo 1.8 Release Partyで詳しく説明があるはず、たぶん) それにともないGo言語でSQLのトレースをするで紹介した shogo82148/go-sql-proxyでもcontextを扱えるようにしました。 Go1.8新機能のサポート Golang 1.8 でやってくる database/sql の変更点で mattnさんが紹介しているように、Go1.8ではdatabase/sqlにいくつか新機能が追加されます。 (mattnさんの対応が早すぎて、メソッド名とか微妙に変更が入っているので注意) 特に大きなのがcontextのサポートでしょう。以下のようなコードでクエリのキャンセルが可能になります。 ctx, cancel := context.WithCancel(context.Bac
net/httpで安全に静的ファイルを返す
net/httpで静的ファイルを返すで、 http.ServeFileを使っていてアレ？と思ったのでちょっと詳しく調べてみました。 (http.FileServerを使うものだと思ってたため) 結論だけ先に書いておくと やはり、特に理由がなければhttp.FileServerを使ったほうが良さそう どうしてもhttp.ServeFileを使う場合は定数でパス指定をする 「自作パスルータを使っている」かつ「Go 1.6.1 未満を使っている」場合はとくに要注意 ディレクトリトラバーサル脆弱性 紹介されているのは以下のコードです。 http.HandleFunc("/static/", func(w http.ResponseWriter, r *http.Request) { http.ServeFile(w, r, r.URL.Path[1:]) }) しかし、参照先の「Go Golang
Go1.8のGraceful Shutdownとgo-gracedownの対応
Go1.8beta1が出た時に、Go1.8で追加される予定のGraceful Shutdownについて書く！ とTwitterに書き込んで早1ヶ月。 この前の金曜日にGo1.8rc2がリリースされ、正式リリースも間近になってきて、 さすがに書かねばという気持ちになって来たので、がんばって検証してみます。 公式サポートで増える予定の機能 以前Go言語でGraceful Restartをするときに取りこぼしを少なくするで 紹介したようにshogo82148/go-gracedownというものを書きました。 あれから時は経ち、ついにGo1.8からはGraceful Shudownがbuild-inの機能として提供される予定です。 公式サポートが入ることによって、以下のような機能を使えるようになります。 HTTP/2のGraceful Shutdownができる HTTP/2ではGOAWAYフレーム
Re:golang の http.Client を速くする
先日mattnさんの記事を読みました。 golang の http.Client を速くする nettというパッケージを使って 名前解決の結果をキャッシュすることで、http.Clientを早くするというものです。 この記事に関して、ちょっと疑問に思ったことがあったので、検証してみました。 疑問 疑問に思ったのは以下の点です。 名前解決遅すぎでは？ ベンチマークの結果を見ると5億ns(=500ms)ほど速度が改善しています。 3つのURLに対してリクエストを投げているので、初回を除く2回DNSのキャッシュがヒットし、 名前解決2回分の速度改善になるはずです。 と、いうことは、名前解決1回あたり250msかかっている計算になります。 googleのsearchは302でリダイレクトがかかるので、Client.Getの呼び出し1回あたり2回リクエストが飛ぶ、 ということを計算に入れても100m
Go言語でGraceful Restartをするときに取りこぼしを少なくする
少し前にStarletにGraceful Restartが時たま上手く動かない問題を修正するpullreqを投げました。 原因は割り込みハンドラ内でexitを呼んでいたからでした。 「割り込みハンドラ内ではフラグを建てるだけ」 「メインのプログラム内でそのフラグを見て分岐する」という原則があるのですが、それを守るのは難しいということですね。 (しかし新たな問題を産んでしまいrevertされてしまいましたが・・・ まあ修正後のコードも考え方は一緒です。割り込みホント難しい・・・) このpullreqを取り込んでもらうときに再現実験をやってみたのですが、 Goでもちゃんと動くのかな？と気になったので Go言語でGraceful Restartをするで紹介した プログラムに同じテストをやってみました。 2017-01-22追記: Go1.8以降でGraceful Shutdownがbuild-i
Go言語でGraceful Restartをする
とあるHTTPサーバをGolangで立てようって話になったんだけど、 止まると困るので無停止でサーバ再起動をしたい。 PerlにはServer::Starterという有名モジュールがあるんだけど、 Golangはどうなってるの？ってことで調べてみました。 2017-01-22追記: Go1.8以降でGraceful Shutdownがbuild-inになるので、この記事で紹介したライブラリは不要となりました。 詳しくはGo1.8のGraceful Shutdownとgo-gracedownの対応を参照。 gracefulじゃないバージョン Golangの標準ライブラリを使ってHTTPサーバを立ててみる例。 レスポンスが一瞬で終わってしまうとよくわからないので、sleepするhandlerを追加しておきます。 package main import ( "fmt" "log" "net/ht
map[string]Hoge or map[string]*Hoge ?
Go言語でポインタを使うべきか使わないべきか問題。 「ケース・バイ・ケースなので、状況に応じて使い分けましょう！」という結論が出るのは目に見えているので、 具体例について検証してみた結果を書いておきます。 背景 他の人のコードレビューを見ていたら、 レビュアーが「コピーをしないで済むのでstructの受け渡しにはポインタ使ったほうがいいと思います！」とコメントしていて、 そうなのか？と思ったのですがあんまり自信がなかったので検証してみました。 コメントがついていたのは以下のようなコード。 package hoge import ( "strconv" ) type Hoge struct { A int B int C int } func NewHogeMapStruct() map[string]Hoge { m := make(map[string]Hoge) for i := 0;
VeeWeeでVagrantのboxを作ってみた
Vagrant VagrantはコマンドラインからVirtualBoxを扱えるようにするツール。 仮想マシンの起動・再起動をコマンドライン上から行えるのはもちろん、Chefや Puppet と連携することで必要なソフトウェアのインストールを行なってくれます。 Vagrantを使うには仮想マシンのひな形であるBase Boxが必要です。 Vagrantbox.esにいろんなOSのBoxがあるけど、 インストールされているOSのバージョンが古かったり、タイムゾーンがUTCになっていたりして 不具合発生。 そこでBoxを自分で作ってみようと思い立ち、やってみたのでそのメモ。 作ったBoxは GitHub にあげておいたので使いたい方はどうぞ。 Ubuntu 12.04.2 Server + VirtualBox 4.2.10 で作ってあります。 vagrant box add myubuntu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
