ブラウザで大量データ処理をした覚書

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

いやーやっぱりいろいろやってみるもんだな ・10万オーダーのデータをブラウザで触ると簡単にOOMになる ・なので、Indexeddbに逃してWebWorkerをこき使いましょうね ・WebWorkerちゃんもだんだんGCできつくなる ・そんな時はサクッとTerminate！そして新規召喚！あらメモリがきれい！ ・indexedb駄目

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

・WebWroker でindexeddbをさわると同じDBでは当然ロック競合が起こって遅い ・BroadCastAPIはWebWorkerちゃんとの1:1通信よりメモリに厳しい ・やはりまる一日稼働を目指してブラウザで処理を考えるとGCがキツイ ・だんだんメモリにゴミが溜まってGCで速度がでなくなる ・その点Workerに投げるはあり

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

・しかしWebWorkerにデータを渡す量が多いと遅い ・ここをシェアードオブジェクトにする（でもArrayBufferからデータ形式の変更で多分遅い） ・ブラウザがバックグラウンドになると遅くなるから顔帳に習って小さい音を鳴らす ・しかしWebAudioはユーザーアクションがないと作動しない ・リロードしたい

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

なんつうかねGCなんよ GCは悪くないけど 「うおぉぉぉぉぉその調子だ！いっけー！」 って言ってるときに 「スんッ」ってGCで動きが鈍くなるの。 でGC頑張ってるんだけど、カクついて動かなくなった後に突然のOOMで落ちると。 これを回避しようとするとオブジェクトをカジュアルに作らないとか

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

コールバック関数をループの中で作るのやめようぜ とか、要らなくなった配列は中身ちゃんと空にしようぜとか、そのオブジェクト終了コマンドあるんじゃない？はちゃんと終了するとか頑張らないと駄目なんだけど… それってめちゃくちゃ時間かかるんよ。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

なので、 ブラウザをWebRTCサーバーとして活用したい場合は ・ブラウザ本体のプロセスは画面描画とバックグラウンド化抑止に音を鳴らすこと、各Worker管理と取次に特化 ・Workerプロセスは定期的に作って殺すこと ・通信もできるだけWorkerプロセスに寄せ世代交代でも問題ない様ハンドオーバすること

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

あとはjsの体感的な省メモリ術としては できるだけオブジェクトを使いまわすこと 関数をstaticにしてnewしないこと 使い終わったオブジェクトと配列はきれいに内容をクリアすること クロージャーでの参照を避けること かねぇ GCでお片付けされるので 実際どうなの？は有るけれど。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

想像してご覧、2000円で買ったジャンクスマホが OSにユーザー登録しないまま外部公開サーバーとして作動する様を〜 ※Googleアカウント無しで運用はどこまで危険なのだろうか、アプリがバージョンアップしない？

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

しかし秒間200件弱のwhile文からのリクエスト発行の上限が有るという単純にノンブロッキングをマルチコンテキストで実現しようとすると１スレッドでやるとどうしてもWhile文の中でsetTimeoutを使用したwaitを噛まして他のコンテキストを待つのだがそこで1msでも待てば 他の処理が0でも秒間1000まで

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

実際は5msはなにかでかかるらしく、200件未満で止まる。 当たり前と言えば当たり前。 したがってこの部分を突破したければ、Workerに投げるリクエストを秒間200弱を上限として別のworkerに出さないといけない。 Nested Workersで司令塔Workerに管理させる事になるのかな？ nhiroki.jp/2018/10/29/nes…

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

まあWorkerはメモリを食うよね。 しかし、メモリリークを考えると一定時刻で殺したい。 そうするとブロッキングするAPI（indexeddbとか）まで含めて渡したい。やり取り情報はサマリーだけ寄越せ、言うことをきけ みたいな社会の縮図的な構造にせざる得ないな こう画面スレッドが制御可能な時間は有限と

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

Workerとやり取りするメッセージングもコピーコストがそこそこ高いからArrayBufferでバイナリ管理したい 等などが要望として上がってくる感じ。 秒間1000件を超えるリクエストの生成を考えるとネストしないと無理と。途中で一回でもノンブロッキングでwaitした処理が介入するチャンスが有ると1msは使う

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

WebRTC経由でリクエスト受付でだけど その辺のジャンクスマホがこっそりサーバーになるとかドキドキしないかい？ ShardWorkerとかServiceWorkerとかWASMとかはとりあえず脇に置いておいて、こんな感じ。 メインスレッドでは1000件/秒のリクエスト処理は絶対こなせないので分散が必要という話。 pic.twitter.com/o3fnsyr3TH

拡大

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

中間管理職は期日（1秒単位）になったら結果報告書をメインスレッドに上げて、他の中間管理職とおしゃべりする会議をBroadCastAPIで持つ感じか。 一定時刻が経つと死ぬので、一定期間後、仕事の発注を控えて必要な引き継ぎをすると。

汝、翼を与える＠ばってん先に翼ばくれんね イベント・・（parody） @ryunosinfx

WebRTCのチャンネルもハンドオーバーしないと駄目だから、チャンネルの生存期間管理も必要だね。 こうしておかないと何がメモリリーク（これはjsエンジンとその仕様への浅い理解が主な原因だとは思う）を回避して安定稼働への鍵なんだと思う。