にしし ふぁくとりー:西村文宏 個人サイト

No.990, No.989, No.988, No.987, No.986, No.985, No.984[7件] - 今日のひとことログ

更新

■LOG No.990, No.989, No.988, No.987, No.986, No.985, No.984[7件]

にししふぁくとりーHOMEに掲載している「今日のひとこと」の過去ログ(掲載履歴)です。 RSS

No.990 〔74文字〕

昨夜は真夜中でも室温が19度くらいあって、毛布はなくても良かったくらいだった。今日も暖かいらしい。明日はまた少しだけ寒くなるような予報だったけども。

No.989 〔616文字〕

キャッシュデータの保存先は分散せずに単一のディレクトリに記録しているのだが、1つのディレクトリに10万ファイルとか存在してもパフォーマンスに悪影響はないだろうか? ディレクトリ内のファイル一覧を取得して何かをしようとするなら当然遅くなるだろうが、そうでない限りは特に問題ないと思っているのだが。キャッシュの読み書きをする場合、「あるデータに対するキャッシュファイル名」は生成規則(命名規則)が明確なので、ファイル名を決め打ちで読み書きすれば良いから、「ディレクトリ内のファイル一覧を取得してから何かを探す」というような処理は不要だ。単に「指定のファイルが存在するかどうか」だけをチェックすれば済む。この場合、10万ファイルでも100万ファイルでも、複数のディレクトリに分散していようが単一のディレクトリに保存していようが、パフォーマンスに差はないと思っているのだが、この認識は正しいだろうか?(ファイルシステムにも依りそうだが。) とりあえず、現状の7,600ファイルくらいなら体感速度に影響はない。ただ、キャッシュファイルを無限に作るわけにもいかないので、どこかの時点で「古いファイルを消す」という処理が必要だが、このときには「ファイルの一覧を得て1つ1つの更新時刻を調べる」という作業が発生する。これはファイル数が莫大だとパフォーマンスが落ちそうな気はする。どれくらいの頻度で実行するか次第だろうけども。そこはまだ考えていない。

No.988 〔637文字〕

クローラーに対して5回に4回の頻度で503(Service Temporarily Unavailable)を返す方針でPHPを書いたら、4時間くらいでサーバのエラーログに503エラーが1500回くらい記録されていた。この対処方法だと、本当に何らかの問題で503エラーが発生している場合と区別を付けにくくなってしまうので、やはり429(Too Many Requests)を返すように変更した。クローラーがHTTPレスポンスコード429の意図を把握してくれるのかどうかは分からないが、別に何を返そうが、APIにリクエストを送るより前にPHPスクリプトを終わらせれば(APIへのリクエスト数を削減するという意味では)同じことだから問題はない。行儀の良いクローラーなら問答無用で大量アクセスをしてくるわけではなく、おそらく相手先Webサーバの反応によってアクセス頻度を調節しているのではないかと思うので、503を適宜返していればそのうち頻度を下げてくるのではないかと思ったのだが。429でもそう動作してくれるだろうか。HTTPレスポンスコード429の本来の用途がまさにそれなので、たぶんGoogleのBotなら対応してくれるのではないかと期待しているが、他のクローラーはどうだろうか。(どこからBotが来ているかまでは調べていない。ユーザエージェント文字列に「bot」が含まれることを条件に制限してみたら効果があったので、いま詳細を調べる手間は掛けなくても良いかなと考えた。)📗

No.987 〔453文字〕

6秒に1回の割合でクロールされているとは予想していなかった。さすがに頻度が高すぎないか。私がこのAPIを使い始めたのはたぶん15年前くらいではないかと思うのだが。それだけ年数があれば、さすがに生成されるあらゆるURLが認識されるということか。人間のアクセス者(利用者)は大して居ないサイトなのだが。今回に強制的に移行せざるを得なかったAPI v5では許可されるリクエスト数がシビアになることは事前にアナウンスで分かっていたので、今回はスクリプトを書く上で最初から長めにキャッシュできる仕組みを用意して、リクエスト数もカウントできるように計画したのだが。そうしていて良かった。気付かずに単純に仕様を変更するだけだったら、運営を継続できなくなるところだった。まさか(新スクリプトの)本番稼働開始から半日で6千回もアクセスされるとは。(ただ、同じBotがその頻度で来ているのかどうかは分からないが。そこまでは調べていないので。クローラーは何もGoogleだけが走らせているわけではないので、他にも居るだろう。)📗

No.986 〔148文字〕

ああ、HTTPには429 Too Many Requestsというレスポンスもあるのか。503よりも429を返す方が適切かな。サーバ側の問題ではなく(アクセス頻度が高すぎるという)クライアント側の問題なのだし。このレスポンスコードをクローラが意図通りに解釈してくれるのかどうかは分からないけども。

No.985 〔545文字〕

直近の24時間で8,640回のリクエストが上限だと判定されると考えると、あと11時間くらいの間に2,600回くらいリクエストを送ってしまうと上限に達してしまう。1分あたりのリクエスト数を3.9回以下くらいに抑えないとマズそうだ。リクエストを送るのは何もクローラーだけではなく人間のアクセス者も居るので、とりあえずクローラーに対しては5回に4回の割合で503エラーを返すようにしてみた。これでたぶん概ね30秒に1回くらいしかクローラーからのリクエストは通さなくなるハズだ。書いたコードはとても単純で if(( time() % 5 ) != 0 ) のように現在秒を5で割って「余りが0ではなかったら」という条件で、 http_response_code( 503 ); と書いてHTTPステータスコード503(Service Temporarily Unavailable)を返しているだけだ。そこですぐにexit;でPHPスクリプトは終了させるのでAPIにリクエストは送られない。この判定は「キャッシュがなかった場合」に限って実行されるので、既に自前サーバ内にキャッシュデータがある場合にはそのデータが返される。だからクローラーからのアクセスを問答無用で5回に4回拒否するわけではない。📗

No.984 〔659文字〕

ググってみたところ、APIのリクエスト数上限に達した後は、Too Many Requestというエラーしか返ってこなくなるらしい。しかし、このエラーが返ってきた回数もリクエスト回数としてカウントされるっぽいようなことが書いてあって少々不安になった。「1日あたり8,640回」という制限が例えば『毎日午前0時にリセットされる』というような規則なら良いのだけど、『直前の24時間で8,640回を超えていたら拒否する』みたいなのだと、大量にリクエストを送り続けていると、いつまで経ってもデータが得られないことになりそうな気もした。検索エンジンのクローラーが6秒に1回くらいの割合でアクセスしてくるので、ユーザエージェント名でクローラーを決め打ちにして3回に2回の割合で「503 Service Temporarily Unavailable」エラーを返すようにしてみた。503なら、そのクロールが失敗してもクロールリストから削除されることはないだろうし。これで、6秒に1回アクセスがあっても、実際にリクエストを返すのは18秒に1回くらいになってくれる(はず)。ただ、自前サーバ内にキャッシュが存在する場合には拒否しないようにしたので、キャッシュが蓄積されてくれば、503を返す頻度は下がるハズだ。今日の午前4時頃から今までで6,000回くらいリクエストしているので、もっと頻度を下げておく方が安全かな……。別にクローラーに急いでクロールしてもらう必要は全然ないので、10回に9回は拒否するくらいにしてみた方が良いだろうか。📗
2020年1月
1234
567891011
12131415161718
19202122232425
262728293031
2020年2月
1
2345678
9101112131415
16171819202122
23242526272829
2020年3月
1234567
891011121314
15161718192021
22232425262728
293031

Powered by てがろぐ Ver 4.6.4

--- 当サイト内を検索 ---