このサイトを構築するとき、私はElasticSearchをデータベースRedisとしてキャッシュコンポーネントとして使用しましたが、最初は問題なく使用され、その後、バージョンの反復、モジュールの追加、およびページの継続的な改善により使用されました。 多くの場所のデータをRedisで埋める必要があり、一部のページでさえ数十回または数百回クエリする必要があるため、読み込み速度が遅くなり、システム負荷が増加します。 このトピックでは、Web サイトのバグの修正、システム負荷の最適化、およびキャッシュ ポリシーの調整について説明します。
最初は古いブログ投稿を新しいシステムにインポートする予定がなかったので、新しいページリンク形式、つまり '\result\article ID'を設計しました。このIDは一意であり、長さは20ビットに固定されているため、キャッシュシステムで設計したキーと値のペア(KV)は記事ID:記事コンテンツです。
hXia44YBlyC2E8nCuWW5:[記事内容]
これの利点は、記事がキャッシュされているかどうかを照会する必要がある場合、IDを直接確認でき、そうでない場合はデータベースにドロップされてからRedisにスローされるため、非常にシンプルで高速です。
その後、最初にElasticSearch人気クエリを使用して[推奨読書]がページの横に追加され、その後、人気のリストは基本的に変更されず、無意味であると感じたため、ランダムリターンに変更され、更新ごとに変更されました。 しかし、ElasticSearchへのすべてのクエリは遅いので、ランダムにキーを返すことができるRedisのランダムキー機能を使用してから、キーに基づいて記事の詳細を取得します。
まず第一に、ここで推奨されているコンテンツを繰り返すことはできません、そして第二に、私のウェブサイトは英語と中国語のバイリンガルであるため、中国語のページで英語の記事を常に推奨できるとは限らず、その逆も同様です。
したがって、このモジュールでは、合計10エントリのwhileループを使用して、クエリの直後に取得して戻るたびに、言語が本文の内容と一致しているかどうかを判断し、一貫性がある場合は、カウントが10に達するまで+1を加算してカウントします。 一部の人々は理解していないかもしれません、以下はモジュールコードのこの部分です、言語のためにLを入力してください: '''ジャワ 防御力 getrandomkeyredis(L): #随机获取文章 idlist = []#id rawinfolist = []#详细内容 レン(rawinfolist)が11:#直到列表大于11停止<している間 onepagesid = str(pagecache.randomkey(), 'utf-8')#从redis データリターンとバイトから文字列へのデータをランダムにフェッチします onepagesid idlistされていない場合:#不在列表内 個数 = getpc(onepagesid) #获取文章详情 場合 pcs['言語'] == l :#语言一致 a = {['記事の詳細']}#构造返回 rawinfolist. 付録(a) #将构造好的返回打包到组里面 idlist. 追加(onepagesid) #计数 rawinfo_listを返す
まず、ここでの言語の理由は、このデータが使用できるかどうかを知るために毎回クエリする必要があり、各クエリの構築リターンを完了するのに30〜40回かかりますが、それでもElasticSearchを直接使用するよりも高速です。 ### 何か他のものを見てください 今、私はサイドバーとは異なり、記事ページの下部に「何か他のものを見てください」を追加しました、それはカードスタイルです。 そして当時、便利で高速にするために、サイドバーは「名前、リンク、時間、人気」の4つのフィールドのみを返し、さらに2つのフィールド、つまり「プレビュー画像、紹介」があり、別のモジュールを作成しましたが、コード部分は基本的に同じでしたが、わずかな変更しかありませんでした。 ![](https://pic.saltyleo.com/i/17108282981.webp) インターフェイスは見栄えが良く、コンテンツは豊富ですが、クエリが多すぎるため、各ページの出力には基本的に80〜100msが必要であり、これは私には受け入れられず、頻繁なIOの読み取りと書き込みはシステムラグになり、高速ではないアクセス速度自体がさらに遅くなります。 それは私が以前に掘った穴であり、私は最近それらすべてを最適化しました。 ソリューションのアイデアと実際のコードを以下に共有します。 ## バグ解決 まず第一に、この問題は、アーキテクチャ全体が後続のバージョンの反復のニーズに追いつくことができず、この問題を解決するためにいくつかのコアモジュールをリファクタリングする必要があるという事実に要約されます。 この点で、私はテーブルを直接持ち上げて再エンゲージしましたが、古いコードを最適化するのではなく、混乱をすばやく切り抜けてリファクタリングする方が適切でした。 記事の詳細ページの横にある10の記事と下部の6つの記事に基づいて、合計16セットの情報を作成しました。 ElasticSearchデータベース内の対応する言語の16のランダムなリターンを直接取得し、各リターンは6つのレコード、つまり「名前、リンク、時間、人気、プレビューマップ、紹介」のみを取得し、メモリを節約します。 クエリ コードは次のとおりです。
es.search(index="why", body={"query":{"bool":{"must":{"multimatch":{"query":'tttt',"fields":['so']}},"filter":{"match":{"language":l}} ,"mustnot":{"match":{"edit":' 編集 '}}},"from":0,"size":16,"sort": {"_script": {"script": "Math.random()","type": "number"}}})
人間の言葉に翻訳すると、[Lと編集されていない記事を含むデータベースからクエリ言語を与え、ランダムに16個のデータを返す]です。 クエリの 'tttt'は、私が設定した一般的なクエリパラメータです。 言語の問題を根本的に解決するために、中国語と英語のRedisライブラリを直接分離して、クエリ時間を無駄にしないようにしました。 上記のクエリコンテンツをRedisに書いてください、私が現在使用しているキーキー、とにかくそれは必要ありません、ただ1つだけです。
def setrdm(l): 対応する言語に対応する#给redis添加一组缓存 l == 'zh'の場合: zhrdmcache.set(round(time.time()),json.dumps(esact.random(l)),ex=3600) elif l == 'en': enrdmcache.set(round(time.time()),json.dumps(esact._random(l)),ex=3600)
また、読みやすさも非常に簡単で、次のコードを使用して、対応する言語で推奨読書を読むことができます。
def getrdm(l): 対応する言語に対応する #从 redis でランダムな戻り値のセットを取得します l == 'zh'の場合: return json.loads(zhrdmcache.get(zhrdmcache.randomkey())) elif l == 'en': return json.loads(enrdmcache.get(enrdm_cache.randomkey())) ```
この操作の後、各ページは本文を一度だけ照会する必要があり、ランダムな推奨事項があり、合計時間の消費は基本的に10ミリ秒以内になる可能性があります。
したがって、単純なものほど速くなり、パフォーマンスを無駄にしやすく、パフォーマンスの高いサーバーでは大きな変化を感じないかもしれませんが、構成が低いサーバーで少し最適化すると、大幅な改善がもたらされます。
Hyper-V を使用するためのヒント。
VNC を使用するための簡単な基本チュートリアル
このサイトのドメイン名の話
この記事では、私の記事の表紙画像の制作過程を簡単に紹介します。
Ubuntuでの自動起動の簡単設定
目次
人気タグ
その他の言語
サイト情報