Pgpool-IIのREAD負荷分散が効かなかった話。CPUコア分離で真因に辿り着くまで
Hiroba による自動要約
Standby を 1 台追加して Pgpool-II で READ 負荷分散を試みたところ、QPS が最大 12.4% 低下した。Pgpool-II 経由のオーバーヘッドが READ/WRITE と並列度によって大きく変わることと、CPU コア分離検証で発見した測定手法自体の落とし穴を実測データで報告。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 4846 件あります。
関連する記事
同じタグの記事
Claude Code を外部ツールに接続する「裏口」と「表口」—コネクタと Claude in Chrome の使い分けと設定手順
QiitaClaude Code で Gmail・Notion・Slack など外部ツールの最新情報にアクセスするには、2 つの方法がある。直接連携する「コネクタ（裏口）」と、ブラウザ操作で対応する「Claude in Chrome（表口）」。ツール一覧にあり権限がある場合はコネクタ、ない場合は表口を選ぶ。デスクトップアプリの設定で各ツールを順次つなぎ、Claude Code から常に最新データを参照できる環境を構築する手順を解説。
Claude Haiku 5.5ベンチマーク39.2%達成、料金は10分の1に。Opus 5.5との使い分けとAPI移行の注意点
QiitaAnthropicがOpus 5.5とHaiku 5.5を相次ぎリリース。Haiku 5.5はTerminal-Benchで前世代の0.0%から39.2%に向上し、料金も大幅削減された。ただしHaiku 5.5は10万トークン超過で全体料金が5倍になる段階制があり、エージェントのサブタスク実行で注意が必要。両モデルの守備範囲、ベンチマーク、API接続方法、月額コスト試算をまとめた移行ガイド。
Claude Haiku 5.5はどこまで任せられる？仕様書の整理から考える使いどころ
QiitaClaude Haiku 5.5は応答速度と反復処理に最適化したモデルで、仕様書の条件抽出・問い合わせ分類・文書要約・開発補助タスクに適している。100万トークンのコンテキストウィンドウと12万8,000トークンの出力制限を踏まえ、モデルに任せる範囲と人間が確認する範囲を明確に分けることが重要。古い仕様と新しい仕様の混在、推測による補完、関連資料の優先順位の自動判定は避け、依頼の設計と利用入口の選定が実運用の鍵になる。