GiteaとApache+HTTP/2がやたらと遅い

長いスクリプトを簡単に作業環境に取り込めるように、Giteaで幾つかのリポジトリを公開している。
記事からリポジトリへのリンクを書いたこともあって、クローラーが時々やってきてくれているのだけれど、その時にページにアクセスしてみたら、やたらと遅い。

Giteaはかなりキビキビ動く印象だったのに、何故こうなったのだろうか。

発生している問題と原因

Ubuntu 22.04 serverでDockerのGiteaを動かし、Apacheでリバースプロキシをしている環境。

発生していた問題は以下。

ページにアクセスしたとき、最初に無反応の時間がある。
問題発生するページは特定できない。ランダム。
無反応な時間は30秒～60秒くらいあったように思う(体感)。
ページが表示されはじめると速くて、最後に表示される時間はいつも100ms以内。
クローラーによるアクセスがあったときに顕著だった(体感)。
- クローラーA(3つのIPから少し早め)からアクセスがあったとき、頻度高めに発生。
- クローラーB(2つのIPからゆっくりめ)からアクセスがあったとき、しばしば発生。
- とはいえ、本当にアクセス量が影響しているのかどうかは分からない。

Gitea導入当初はHTTP/1.1でサービスを公開していた。
ある時HTTP/2があることに気が付いて、メインサイトにPHP-FPMを導入してHTTP/2に切り替えたとき、Giteaも同時にHTTP/2になっていた。
これが問題発生の原因になっていた。

Giteaはリアルタイム通知のために、ロングポーリングを使っているそうで、それはApache+HTTP/2と相性が悪いそうだ。
そして、Nginxではこの問題は発生しない、とされている。
Github / go-gitea / gitea / Slow browsing on http2 enabled reverse proxy, long-polling /user/events blocks other requests #19265

なお、この問題が発生しているとき、コンテナにアタッチしてログを確認してみたら、所々にこんなログが出ていた。

gitea     | 2023/10/14 09:19:58 ...eb/routing/logger.go:102:func1() [I] router: completed GET /user/events for [<接続元IPアドレス>]:0, 200 OK in 30005.1ms @ events/events.go:18(events.Events)

※/user/eventsで30秒。

対策

Nginxに乗り換えるという解決策もあると思うが、ここではApacheのままでできる対策を2つ整理した。
どちらか一方を実施すればOK。

(1) HTTP/2を諦める

Apache+HTTP/2だとランダムに遅くなる、ということなので、残念だけれどもGiteaだけHTTP/1.1で通信するように設定を変える。

/etc/apache2/sites-available/myservice.conf ※ファイル名はホームラボで導入したときのもの。適切なファイルに書けばOK。

<VirtualHost *:443>
    ServerName gitea.rohhie.net
    DocumentRoot /var/www/html
...
    Protocols http/1.1
....
</VirtualHost>

※赤文字を追加。

設定を反映。

$ sudo systemctl reload apache2

これで、このVirtualHost(gitea.rohhie.net)だけがHTTP/1.1で通信する。

(2) リアルタイム通知を諦める

ページを切り替えれば通知は見えるのだろうから、リアルタイム通知を諦める。

この場合、以下を設定することで、リアルタイム通知を止めることができる。

gitea:/data/gitea/conf/app.ini

[ui.notification]
MIN_TIMEOUT = -1
EVENT_SOURCE_UPDATE_TIME = -1

※セクションごと追記。MAX_TIMEOUTとTIMEOUT_STEPはデフォルトのままでも、ポーリングをオフにすることができた。

設定を反映。

$ cd <docker-compose.ymlがあるディレクトリ>
$ sudo docker compose restart <service name> && sudo docker compose up -d

※<service name>はdocker-compose.ymlの中でgiteaを定義したサービスの名前。

これでロングポーリングすることがなくなった。

結果

HTTP/2を諦めた場合

結果は、若干の残念はあれど、全体でみれば素晴らしい環境といえるまでに復旧した。

画面が表示されるスピードは僅かながら落ちた。やはり並列で表示する効果はあったようだ。
不思議な待ち時間はなくなった。
- どのページに行くにしても、早いときと遅いときがあったが、常にキビキビと動く。
- サイト管理の「組織」「リポジトリ」は確実に遅かったが、それが解消された。
- サイト管理の「設定」がかなりの確率で遅かったが、それが解消された。

リアルタイム通知を諦めた場合

不思議な待ち時間は全くなくなり、ページの表示も速い。

どうせ一人で管理しているGitサーバーなので、現時点でリアルタイム通知は必要がない。
それよりも、アクセスしたときにキビキビと画面が表示される方が、メリットが大きい。

ということで、本番環境ではこれを採用することにした。

さいごに

こういった話になってくると、Nginxに乗り換えるのが一番いいのかなとも思う。
でも、まぁ、また今度にしよう(いつになるか分からないけれど)。