風バイアス・NARスクレイピング②～高速化処理への道～

このお題だと、鶏卵論から結局は卵を選んだ？と言う感じですが。

これ以上追記するのもどうかと思い、新しい記事で投稿します。
結局、禁断の「非同期スクレイピング処理」に手を出してしまいました。
最大の理由は、、「余りに処理が鈍足で使用に堪えれない」からです。
全ての処理終わるまで、13万件超で3300時間って壊れとるやん！！
って事が原因でした。
そりゃリストにリスト当ての処理をぶつけていますからね。。。

貧相な私のPCですが爆速処理を求めているにも関わらず、結局メモリ不足の処理落ちとか多発中です。。。
もう、どうにかしてくれ。。。(´;ω;｀)

始めはrequests準拠for回しのイテラブル処理のみで動かしていました。
はい、昨日の投稿はそれです。
まぁ、月次や年次処理がまるで動かないのも愚直な正攻法イテラブルを諦めた原因です。
→何で方々はこの手法ばかり取るのだ？？コーディングが簡単だからか？？

この時点で、先ほど挙げた年次処理が3300時間と言うべらぼうな完了予定時間。
たとい処理完了してもちゃんと期待したデータが反映されているか？疑問が残り、これは本当に無理っす。。。

次に考えたのが、concurrent.futures+requestsの並列化処理。
→夕べ～夜中に並列化処理にソースコードを移行改造して、それでもtqdmが日次→月次が漸く動き出し、速い速い～って喜んでいたらこれが罠でした。。。
完了予定、330時間。
→いやったぁ！1/10短縮だぁぁ～、、じゃねーよ！！
処理も一向に進まず。。。

Copilot先生ですら、「そこまで仰るならasync処理如何っすか？」って言ってきました。。。
で、requestsAPI謹製はここでお別れ。
そこで又も非同期処理用にソースコードを書き換えて挑んだところ、、極めてピーキーな動きとなり、処理落ちしたりしています。。。
何か別事すると真っ先に落ちるんです(´;ω;｀)

→いまココ

正直、早速途方に暮れております。
風速や風向の反映って結構大変なチャレンジだったのね。。。
もう少し頑張って戦います！

それではまた！！
せや、処理ぶん回したまま何もせずに寝たろかな？？？（苦笑）
あ、そうそう言い忘れました。
スクレイピング処理で読み込むことが多いサイトのSSL証明書はローカルにインポートするべきですよ～。
これだけでも少しは処理落ち対策にはなると思います。