トップブルーワード懸念「王Yujieのブログ」をクリックします。
リード
昨年末、私はと題した記事を書いた「私は、.NETコアパフォーマンス最適化の教訓ブログ」が、その後行方不明補足する必要があることがわかりました。私たちは〜を見てみましょう
時間のために犠牲にスペース
時間のためのスペースを犠牲にする、スペースのための時間を犠牲にする：私たちは専門家だけが私の普通のプログラマは通常2つだけのオプションのような、高速で小型とソフトウェアの設計を行うことができますことを知っています。だから、必要な場合にパフォーマンスの追求は、我々は宇宙にいくつかの犠牲を作ることができます。例えば、データベースは、冗長データを格納することができます。
データベーススペースの費用
私のブログでは、私は記事のリストページの要約を表示する必要があり、この要約は完全な記事の最初の400個の言葉に由来しています。多くの時間を無駄に消費するので、私のレガシー.NET Frameworkでは、たびに、この操作ではSQLでこの傍受を達成することは困難EFの使用による最初の400個の単語のサブストリング（）傍受、とSELECT記事全文コンテンツをブログおよびネットワーク伝送がかかります。ブログの.NETコアの書き換えでは、私は、設計を調整し、保存前の記事の400語の要約専用の記事で新しいテーブルを追加し、新しいコンテンツの要約は、記事を書いたり編集になります計算が完了し、データベースに格納されている場合、私は記事のリストを表示するとき、あなたは完全な記事の内容SELECTに行く必要はありません。この設計は確かにそれらを満たしていないものの、厳密データベースのパラダイムを話すが、完全にここでパフォーマンスを向上させます。
企業システムでは、このアプローチは、より一般的です。計算の結果は、オーバーヘッド取得するために、比較的大きく、結果は変わりません場合は、すべての時間をカウントする必要はありませんし、それがパフォーマンスを向上させるために、データベースに格納され、完全なカウントとして設計されています。
犠牲ファイルシステム空間
私が完了し、データベースのデータを計算するたびに取る必要があり、過去になど、RSS / ATOM / OPMLフィード、ブログを持って、クライアントに出力します。しかし、そのようなデータもほとんど変化しない機能があります。ユーザーとして、結果が一時ディレクトリにXMLファイルのキャッシュを生成した最初の訪問、フォローアップユーザーは、データベースのヒットにアクセスする必要がないように設計私はそう。記事の内容は、ユーザーが再生成次のリクエストにできるように、キャッシュファイルのドロップアウト、時間を変更する必要が場合のみです。
この課題を解決するための手段
在系统设计中，不要过分遵守理论，比如数据库范式，要具体分析自己遇到的业务情况，并做调整，世界上没有可以完美复制的“最佳实践”，只有适合自己业务的才是最佳实践。
懒，越懒越好！充分分析业务，明确哪些数据不容易变，可以缓存就缓存，文件也好，内存也好，根据需要自己设计。能不要去调用数据库的就尽量不要去用，因为通常系统最慢的环节就是在调用不同的API和数据库通讯上。
其他性能优化事项欢迎参考前篇《我的 .NET Core 博客性能优化经验总结》
