ディレクトリ
結論：あなたが必要とする小規模な接続プール、および接続待機中のスレッドのキューであります
I.はじめに
基本的に、私たちはデータベースと対話するために必要なプロジェクトのほとんどは、その後、データベース接続プールのサイズは、はるかに良いように設定されていますか？
：一部の開発者は、ベテランはあなたを教えてくれるかもしれない、それは問題ではないようなデータベースは、より高いパフォーマンスをされますように、スループットが大きくなります、200に設定するなど、より大きな設定をしてみてください！
あなたはそれが本当にある、うなずくかもしれませんか？この記事を読んだ後、あなたはあなたの認知ああを覆すかもしれません！
第二に、メインディッシュが開始します
データベース接続プール設定のサイズについて、言うことは非常に簡単することができ、各開発者がリンクをピットに陥ることがあり、それは実際には、ほとんどのプログラマは、そのサイズを設定するには、自分の勘に頼る可能性が高いだろう、に設定されています100？長い間熟考した後、ちょうどそれについて考え続ける必要がありますか？
第三に、あなたのサービスを想定して万の同時アクセス
わいせつを見たいことがあり、あなたの手はないのFacebookへの同時圧力そのレベルが、ウェブサイトを持っているが、何？万並行ボリュームアップダウンもあります！それは、ほぼ約20,000 TPSです。
そこで質問です！サイトデータベース接続プールは、より良いどのくらいに設定する必要がありますか？
実際には、この質問を自分自身に問われる問題であり、我々は右の質問がされて依頼する有効にする必要がありますする必要があります：
「サイトのデータベース接続プールは、より良い小さな以上に設定する必要があります？」
PS：ここではOracleのパフォーマンスチームが発表し、短い動画だ、リンクアドレスがhttp://www.dailymotion.com/video/x2s8uecで、ヒント、アクセスXXああを必要とします！
データベースを操作するために9600個の同時実行スレッドをシミュレートするために、Oracleデータベースのストレステストのビデオでオーラル見て、すべての2つのデータベース操作の間のスリープ550msは、2048年のためのビデオセットの初めに、スレッドプールのサイズに注意を払います。
のは、幽霊の2048パフォーマンステストの結果のためのデータベース接続プールのサイズを見てみましょう：
33ms接続プール内の各要求は、時間のかかるSQL実行77msを必要とし、その後、接続が得られ、キューで待機し、CPUの消費量は約95％で推移しました。
次に、我々は、接続プールのサイズ断片的なポイントは、他の試験パラメータ変わらず、1024年に結果Zeyangを設定しますか？
「ここでは、本質的に変わらない接続を待って、長い時間を得るが、SQLの実装では、時間のかかるを減らします！」
おっと、ああそこに育ちます！
次に、我々は、他の96個のパラメータへの同時変更の数を、接続プールのサイズを小さくし、何が起こるか見て、小さい方を設定します。
1msの各要求キュー接続プール平均待ち時間は、SQLには時間がかかり2msのです。
私が行ってきました！何地獄？
それが3msのに平均応答時間前に100ミリ秒にできるようになるので、我々は、データベース接続プールのジャストサイズが縮小され、何も調整していませんでした。スループット指数の上昇ああ！
あなたもそれをスリップ！
第四に、なぜこのような効果がありますか？
私たちは、その性能はこれまでのプロセスはApache HTTPD 100それを超えている、唯一の4つのスレッドなぜnginxの内部で使用する、考えるかもしれませんか？言葉の説明責任は、コンピュータサイエンスの基礎を思い出す理由は、答えは非常に明白です。
あなたも、シングルコアCPUのコンピュータが「同時に」スレッドの数百を実行することができ、知っています。しかし、実際に我々はすべて、これが私たちだけ何も再生するトリック高速スイッチング時間スライスオペレーティングシステム、であることを知っています。
コアCPUは一度に1つのスレッドを実行することができ、その後、オペレーティングシステムのコンテキストの切り替え、高速スケジューリングのCPUコア、コード別のスレッドを実行するには、絶えず繰り返され、それは私たちに同時に錯覚を実行しているすべてのプロセスを引き起こしました。
実際には、コアCPUのマシンで、実行の順序AとBは、タイムスイッチ「同時」を通じてスライスよりも常に優れているAとBのオペレーティングシステムは非常に明確にする必要があり子供用の靴のこのコースで学んだ原因となる、高速です。いったんスレッドの数は、CPUコアの数を超え、これはパフォーマンスをコンテキストスイッチの追加コストを伴うため、システムは、より高速ではない、もっとゆっくりスレッドの数が増加します。
ここで、あなたは突然実現しなければならない......
第五に、他の要因が考慮されるべきです
主な理由のセクションに言えば、実際にはそれほど単純ではありません、我々はまた、他の要因を考慮する必要があります。
私たちは、データベースのパフォーマンスのボトルネックを探すときは、大きく3つのカテゴリーに分類：
-
CPU
-
ディスクIO
-
ネットワークIO
おそらくあなたは、この因子のメモリがある、と言うのだろうか？メモリが考えられ、これらに比較することが確かにあるディスクIOやネットワークIO、やや無意味な、そこに追加されません。
我々は接続の数を増やす場合は、最適なパフォーマンスを提供できるようにするには/ 8スレッドディスクおよびネットワークIO IO、非常に良い結論、および8コアサーバ上の、データベース接続を考慮していないと仮定しますが、理由はコンテキストのパフォーマンスの低下を切り替えます。
我々はすべて知っているように、通常、何らかの回転する金属ディスクとステッピングモータによって通常はディスク上のデータベース、及びディスクは、データ・ストレージ・コンポーネントの頭部に装着しました。/書き込みヘッドを読むだけで、それは読んで、もう一度書き込み操作を実行する必要があるとき、タスクを完了するために別の場所に「対処」する必要があり、同じ時間位置で発生する可能性があります。そう？ここではそこに時間のかかるに対処することに加えて、回転時間がかかり、ヘッドの操作を読み書きするために、ターゲット・ディスクのディスク「の場所でスピン」のデータを待つ必要があります。もちろん、パフォーマンスを向上させるためにキャッシュを使用できるようにするには、これらの原則が適用されます。
この期間内に（「I / O待ち」）時、スレッドはである「ブロッキング」状態を待って、それが仕事に取り掛かるやっていません！オペレーティングシステムは、他のスレッドのために、このアイドルCPUコアサービスを使用することができます。
ここでは、あなたのスレッドは、I / O集約型のビジネスであるとき、あなたはスレッド/ CPUコアは、いくつかの接続の数よりも大きい場合、これはより多くの作業を完了するために同じ時間にすることができ作ることができ、まとめることができますスループットを向上させます。
そこで質問が再び？
どれだけ良くするような大きさ？
これは、依存するディスク、あなたはSSDソリッドステートハードドライブを使用している場合、それは対処する必要はありません、あなたはディスクを回転させる必要はありません。停止停止に来て！！！当たり前のことをあなたが取ることができないん：「速いSSD以来、少し大きいが、我々は、スレッド、それの大きさの数を設定します!!」
結論反対！必要はありません対処すると時間のかかるサイクルが意味するものではありませんあまり混雑高い性能を再生されます、（CPUのコア数に近い）ので、少ないスレッドを。集中的な阻止た場合のみ、スレッドのより多くの数は、より良いパフォーマンスを再生することができます。
私たちは、IOは、その後、我々はネットワークIOの話をディスク上に述べてきました！
ネットワークIOは実際には非常に似ています。また、100Mの帯域幅の一部を詰まらせる帯域幅の1G未満ながら、読み、1G阻止帯域幅が少なく消費するよりも、イーサネット、10G帯域幅を介してデータ・インタフェースを書くために閉塞を引き起こす可能性があります。通常、我々は考慮すべきネットワークIO第三位につけたが、一部の人々はネットワークIOパフォーマンス計算によってもたらされる影響を無視します。
図は、PostgreSQLのベンチマーク性能試験データであり、我々は図から見ることができ、TPSスロースタートは、接続数で50に到達します。コアサーバのCPU数が16または32でなければ戻って次に来てほしい、Oracleのパフォーマンス・テスト・ビデオの上に、テスターは、まだ、96までの2048年から高すぎる実際には96の接続数を持つことになります。
六の接続式
次の式は、PostgreSQLによって提供されていますが、根本的な原理は、それが市場に出回っているデータベース製品の大半に適用され、同じです。また、あなたは訪問数の期待値をシミュレートする必要があり、かつ合理的な値のバイアスを設定するには、以下の式で、その後、微調整することにより、実際の試験では、最も適したサイズの接続を見つけること。
接続=（（2つの*コア）+ディスクの有効数）
コアは、全体のホットデータがキャッシュされている場合は、オープンハイパースレッディングは、あまりにも、そして効果的なディスクの実際の数は、減少のキャッシュヒット率で、0で効果的なディスクの数が徐々になってきていた場合でも、ハイパースレッディング（ハイパースレッド）を含むべきではありませんディスクの実際の数に近接しています。また、SSDの役割を達成するためにどのようにこの式は、不明である、注意してください。
サーバーのCPUはクアッドコアのi7のであればよく、この式によれば、接続プールのサイズはする必要があります((4*2)+1)=9。
全体を取る、我々は10バールに設定されています。あなたああ大丈夫？10それには小さすぎます！
あなたが行を考えていない場合は、テストが見ることができる人格を実行することができ、我々はそれが簡単なクエリを実行するために6000 TPS同時シーンのレートで3000人のユーザーをサポートできることを保証することができます。また、10の上にプールのサイズを接続することができ、あなたはTPSは減少し始め、長い応答時間が増加し始めるでしょう。
結論：あなたが必要とする小規模な接続プール、および接続待機中のスレッドのキューであります
あなたは万の同時アクセスを持っている、とあなたは、接続プールのサイズは10000で設定し、あなたの音楽ブログああを揺することを恐れているとしましょう。
1000年には、あまりにも？100へ？それともあまり。
あなただけのサイズ10データベース接続プールを必要とし、その後、スレッド事業の残りの部分はキューで待機することができましょう。
（それは通常せいぜい2つの* CPUコアである）データベースタスクが同時に効果的に行うことができるクエリの数：接続プールのサイズの接続の数は次のように設定されるべきです。
あなたはいつもケース100、200をシフトするように設定されている同時データベース接続プールのダースについてに対応するために、大規模なWebアプリケーションではありません一部のユーザーが表示されるはずです。データベース接続プールのサイズをオーバープロビジョニングしないでください。
8つの追加点は注意を払う必要があります
実際に、またはプールのサイズは、何かのために、実際のビジネスシナリオとの接続をセットアップします。
たとえば、あなたのシステムが混在しながら、長いトランザクションと短いトランザクション、その後、上記の式に従って、それは難しい得るために計算します。正しい方法は、二つの接続プール、長いトランザクション内のサービス、短期取引である「リアルタイム」の問い合わせ、でサービスを作成することです。
タスクキューを実行するためのシステムは、ビジネスタスクの一定数をのみ許可されている同じ時間を要する別のケースでは、たとえば、その後、我々はむしろ接続の数よりも、接続プールの接続に合わせて同時タスクの数をさせてください同時タスクの数に合わせてサイズ。
オリジナルリンク：
https://mp.weixin.qq.com/s/Esop6mmjYt0mw_DCo9QbOw
https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing