#4885

非合理的大回転


web制作


昨日分の記事に引き続いてプログラミング系の話題になりますが、
ちょっとしたWebプログラミング絡みの気付きがあったのでメモ。
昨日の昼間と今日の起床直後でしばらく放置していた特設サイトのメンテをしていたのですが、
かねてよりこのサイトはページの読み込み速度が懸案になっていました。
開発ツールで見てみると、サーバーサイドの処理で2秒ほどかかっている。
これは回線速度やクライアントの状況は関係なく、
自分が書いているPHPのプログラムの実行にやたら時間がかかっているということを意味します。

頻繁にwebサーフィンする人なら分かると思いますが、
2秒待たされるというのは意外とストレスになります。
web業界には昔「8秒ルール」というものがあったそうで、
曰くWebページの閲覧者は8秒以上待たされると読み込み前に帰ってしまうので、
制作者は読み込み速度をそれ以下に抑えるように設計するべきとのことですが、
これはダイアルアップ回線が主流だった時代の話で、今はもっとシビアになっていると思われます。
個人的には8秒は待てなくて、たぶん4~5秒くらい待って駄目だったら次に行きますね。
情報が溢れかえりすぎて安牌が埋もれてしまっている今は、
検索結果最上位だけで済む割合も減ってきているわけで、
下手にひとつのサイトに期待せずにどんどん次を探していこう、というスタンスです。
(そういう意味ではこのブログはたいへん厳しい立場にあるのですが……)

ともあれ、昔は回線速度も遅かったので8秒くらいがボーダーラインだったのかもしれないけれど、
光回線が当たり前の今は、サイトもサクサク表示されるのが当たり前になっているわけです。
だからこそ、ページ読み込みで待たされる際のストレスがより敏感にならざるを得ないと。
というわけでかねてからなんとかしたいと思っていたのですが、
結論から言って、とてもあっさり直りました。
今はサーバーサイド処理が0.3秒ほどになっています。

原因はやはりというか、データベース問い合わせでした。
特設サイトはPHP-MySQL間で関数を使って相互にデータをやりとりしています。
データベースの技術は凄いもので、数千行あるテーブルをリクエストしても、
大抵はほぼ一瞬で返してくれます。
しかし、PHPは基本的には1行ずつ進んでいくプログラミング言語であるため、
たとえばデータベース問い合わせ関数が100個並んでいたら、
2番目のクエリは1番目が終わらないと処理できず、それが後ろにずらっと並ぶ行列のようになります。
これがひとつ当たり0.01秒なら数が多くても気にならないかもしれませんが、
データ数が多くなってきたとき、ひとつのクエリの処理速度が少し遅くなっただけでも、
実感する読み込み速度はその100倍遅くなることになります。

この特設サイトも移転当時は数百しかなかったレコードが今や4,000行近くまでなっており、
この肥大化が読み込み速度に影響しているとなれば、対策はひとつ。リクエストを減らすしかない。
しかしサイトの形を変えずにリクエストの数を減らすなんてどうすれば……。
と長らく悩みの種だったのですが、ふとプログラムを上から順番に見ていくと、
メニューに表示するための130ほどのステージタイトルを、
foreachでループを組んでひとつずつデータベースに問い合わせをかけていました。
しかも、参加者数を取得するだけために。
つまり、今まではページ表示のたびに4000行のデータベースを130回問い合わせていたと。
そりゃあ読み込みに時間かかるわ……。むしろそれでもなお2秒で済むのか。

結局これは、ステージタイトル表示前に一度だけデータベースを読み込んでおいて、
PHPのarray_count_values関数で参加者数を数えるだけで事なきを得ました。
おかげで読み込み速度も早くなって、大分ストレスフリーになったんじゃないかと思います。
こんな感じで初期の頃に作った構文を見ていけばざくざくと改善点が見つかりそう。
まぁ、下手にいじって壊れるのも恐いので今日みたいにモチベがあるときにしかできませんが。

そんなこんなで昨日と今日は完全に書く作業三昧で、
たまに息抜きにサイトのメンテナンス作業をしてみたりしただけで完全に潰れました。
先週・先々週のピク2本編でブログ更新を完全に見捨てた分のしっぺ返しなわけですが……。
いやー日課の借金を返す作業はいつまでたってもつらいですね。なんとかならないのかこれ。
ピク2本編も次にやることをおぼろげながらに考えていましたが、
日課の方が安定しないとちょっと厳しい感じです。

コメントを残す