Re: Configuring sql.DB for Better Performance : DSAS開発者の部屋
Configuring sql.DB for Better Performance という記事を知りました。 コネクションプールの大きさを制御する3つの設定を丁寧に解説されたとても良い記事です。 しかし、この記事で推奨されている設定については同意することができません。私が推奨する設定とその理由を解説していきたいと思います。 Limit ConnMaxLifetime instead of MaxIdleConns Allowing just 1 idle connection to be retained and reused makes a massive difference to this particular benchmark — it cuts the average runtime by about 8 times and reduces memory usage by ab
Go の MySQL ドライバの効率の良い使い方 - methaneのブログ
10/5 に ISUCON 3 の予選に Go 言語で参戦していました。 とりあえずレポートは会社のブログに書いたので、 Go 言語で go-sql-driver/mysql を使って MySQL を使う時に知っておくと良い点をまとめておきます。 ちなみに MySQL ドライバにはもうひとつ MyMySQL というものがあり、 まだ試していませんが、 MyMySQL の方が落とし穴が少なそうな気がします。 sql.Open() が返す DB オブジェクトはコネクションプールをしてくれる なので、自前で DB オブジェクトを使いまわしてコネクションプールを実装しても意味は無いです。 DB.SetMaxIdleConn() で、使い終わってもクローズしないコネクションの数を設定できます。 デフォルトだと使い終わったコネクションを閉じてしまうので、 DB オブジェクト自体をプールしても コネクシ
Go の Prepared Statement は Connection を気にせず使える - Qiita
コネクションプールと prepared statement database/sql は、トランザクションを除いて基本的にコネクションをユーザーに見せず、全ての操作をコネクションプール sql.DB を通して行う設計になっています。 コネクションプールと言えば、 prepared statement の実装が気になります。 prepared statement は基本的にコネクションに紐付いていて、 プレースホルダ付きのクエリを投げてコネクションローカルの「ハンドル」を貰う 「ハンドル」にパラメータを送ってクエリを実行する 「ハンドル」を閉じる（あるいはコネクション自体を閉じる） という流れになるので、コネクションプールと組み合わせて使う場合には、 毎回ハンドルを取得＆開放する (１クエリに３回通信が発生) ハンドルを開放しない (DBサーバー側のリソースを食いつぶす) コネクションごとに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to use the go-mysql-driver with ssl on aws with a mysql rds instance
