Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Slow response in web app

オープン
#326 コメント 8 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
postgresql, python

調査の方向性

ホームページの一般統計クエリパスから開始し、run、resource_tags、resource テーブルからの読み取りを調査します。多数のサービスと90日間の履歴で遅延を再現し、その後データベースクエリ分析を使用してボトルネックを特定し、Webアプリが正常に読み込まれることを確認します。

索引モデルが issue の本文から書いたものです。

説明

bug

Describe the bug
The application is really slow, or even stops working, if there is a high number of services configured and / or there are too many historical records in the database.

To Reproduce
Publish a high number of services (ie. 800) , keep 90 days of history and check services every hour.
Looks like the home page tries to load too many records from the database trying to show the general stats of the instance and the web app fails.

Expected Behavior
The web app loads successfully.

Suggestion
In addition to reduce the number of days of history and frequency of checks it could help to include some indexes in the database.

For example:


CREATE INDEX run_res_ident_idx  
ON public.run  (resource_identifier);

CREATE INDEX res_tag_res_ident_idx  
ON public.resource_tags  (resource_identifier);

CREATE INDEX res_tag_tag_idx  
ON public.resource_tags  (tag_id);

CREATE INDEX resource_res_type_idx  
ON public.resource  (resource_type);

主要言語
Python
スター
92
フォーク
76
平均マージ
7時間 21分
マージ済み PR(30日)
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

geopython/GeoHealthCheck のほかの issue

geopython/GeoHealthCheck の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。