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

2020年3月10日の投稿[12件] - 今日のひとことログ

更新

■LOG 2020年3月10日の投稿[12件]

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

No.998 〔6文字〕

ねーむーいー

No.997 〔6文字〕

激しく眠い。

No.996 〔6文字〕

激しく眠い。

No.995 〔17文字〕

公立高校の入試って今頃なんだっけ。

No.994 〔13文字〕

ねむい。凄まじく、ねむい。

No.993 〔247文字〕

「カロリー取り過ぎ」や「マイルを貯める」のカロリーやマイルはどちらも単位だから良いと思うのだが、「ギガが減る」のギガは単位ではなく補助単位に過ぎないので違和感が強いのではないか。ギガバイト(Giga Byte)なのだから単位のByteを使って「バイトが減る」ならまだ許せる。間違いなく異なる意味に解釈されるだろうが。またはビット(Bit)でも良い(1バイト=8ビットだ)。「カロリー取り過ぎ」だってkcal(キロカロリー)の補助単位の方を使って「キロ取り過ぎ」と言ったら意味が分からないだろう。

No.992 〔307文字〕

今朝の5時頃に、API 4.0が停止したとメールで連絡が来ていた。「As of today, March 9, 2020, the upgrade to PA API 5.0 should have been completed. Any application calling PA API 4 will no longer be able to retrieve information.」とのこと。日本時間の10日5時に送ってくるというと、どこの標準時が基準なのか。米国西海岸だと9日13時、東海岸だと9日16時、UTCだと9日20時だ。まあ、アメリカでのだいたい昼頃に送ったということだろうか。(^_^;)

No.991 〔203文字〕

株価下落で日本でも証券会社のサーバに接続できなくなっていたとかTwitterに流れてきていた。今朝S&P500の指数を見ると、だいたい1年前くらいの値にまで下がっていた。
20200310123755-nishishi.png
グラフは左側が1年スパン、右側が3年スパン。2019年1月頃に大きく下がったときほどまではまだ下落していないけど、どうなるかな。とりあえず、ちょっとだけお買い得にはなっているな、とは思う。しかもここ数日でちょっと円高になっているし。

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だけが走らせているわけではないので、他にも居るだろう。)📗
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.1.1

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