回答編集履歴
2
回答としての精度を上げる為に大幅に書き直し
answer
CHANGED
|
@@ -1,62 +1,65 @@
|
|
|
1
1
|
フロントエンドのJavaScriptが重いので、
|
|
2
2
|
サーバサイドのNode.jsに逃したいとのことですが、
|
|
3
|
-
|
|
3
|
+
不特定多数へ公開する事が目的ならばオススメ出来ません。
|
|
4
4
|
|
|
5
|
+
逆に自分一人で行うならば良い案になるかもしれません。
|
|
6
|
+
特にブラウザを開いている端末がスマホやノートPCといった貧弱なマシンで、
|
|
7
|
+
母艦の高性能なサーバマシンに処理を移譲したいケースであれば最善となりうるでしょう。
|
|
5
|
-
|
|
8
|
+
(イメージとしてはクラウド実行したゲーム)
|
|
6
9
|
|
|
7
|
-
その
|
|
10
|
+
ただし、それに飛びつく前に本当のボトルネックが何なのかをしっかり調査する必要があります。
|
|
8
|
-
|
|
11
|
+
現状が分からないので何とも言えませんので、見るべき所を羅列という形で上げていきます。
|
|
9
12
|
|
|
10
|
-
な
|
|
13
|
+
> カクツキを解消出来ないか
|
|
11
|
-
そしてサーバサイドに処理を逃がす行為が反対な理由は何だよって思いますよね。
|
|
12
14
|
|
|
13
|
-
そ
|
|
15
|
+
そもそも何故カクツキが発生しているのでしょうか？
|
|
14
|
-
|
|
16
|
+
JavaScriptとして一番考えられる原因がDOMツリー操作です。
|
|
15
17
|
|
|
18
|
+
ブラウザの画面描画はDOMツリーというオブジェクトをメモリ上に展開し、
|
|
16
|
-
|
|
19
|
+
JavaScriptはブラウザが用意したDOMツリーを書き換えるAPIにお願いして画面の更新を促します。
|
|
17
|
-
1台分の物理演算を賄うだけでクソ重くて処理落ちしてんのに、
|
|
18
|
-
2人アクセスするだけで並のマシンで賄えるはずないやんって話ですよ。
|
|
19
20
|
|
|
21
|
+
これのコスパが非情に悪いです。
|
|
20
|
-
もし
|
|
22
|
+
もしうねうね動く物理演算を、裏で大量のdivタグ作ってstyle要素を編集して操っているのであれば、
|
|
21
|
-
1ヶ月百万円するようなWebサーバを
|
|
22
|
-
|
|
23
|
+
もはや物理演算云々の話ではありません。
|
|
23
|
-
|
|
24
|
+
DOMツリーがクソなので画面がカクついています終わり。
|
|
24
25
|
|
|
26
|
+
そこがボトルネックなのであれば、
|
|
25
|
-
|
|
27
|
+
せっせとWebSocketを使ってサーバサイドに逃がしても無駄です。
|
|
26
|
-
|
|
28
|
+
結局画面更新の負荷でブラウザは固まり、カク付くことでしょう。
|
|
27
|
-
利用者が万を越えたらサーバー台数を増やして対応しなければならないということですね。
|
|
28
29
|
|
|
29
|
-
|
|
30
|
+
まず下記を試しましょう。
|
|
30
31
|
|
|
32
|
+
- svg画像に逃がす
|
|
33
|
+
DOMツリーより出来る事は少ないので多少コスト減になるか？
|
|
34
|
+
- DOMにデータを持たせているならJSの変数にデータを持たせる
|
|
35
|
+
DOM APIでのやり取りを極力減らす事が目的
|
|
36
|
+
JS自体は数万レベルの配列操作ならば結構高速にやってくれる
|
|
37
|
+
- 画面更新は[requestAnimationFrame](https://developer.mozilla.org/ja/docs/Web/API/Window/requestAnimationFrame)を利用する
|
|
38
|
+
- ReactやVue等のJSフレームワークの導入
|
|
31
|
-
|
|
39
|
+
差分だけ賢く更新してくれるので、下手なDOM操作のコードを自分で書くよりもマシになる可能性
|
|
40
|
+
あくまで可能性程度
|
|
32
41
|
|
|
33
|
-
そもそもWebアプリとして使う意味があるのか
|
|
34
|
-
|
|
42
|
+
---
|
|
35
43
|
|
|
36
|
-
ElectronからNode.jsを経由して、
|
|
37
|
-
|
|
44
|
+
以下はそのボトルネックが本当に物理演算だったという前提で考えていきます。
|
|
38
|
-
そしたらHTML・CSS・JSを使いつつもGPUにアクセスするマルチプラットフォームアプリとして配布出来そうです
|
|
39
45
|
|
|
40
|
-
小手先の技術でよければRustで物理演算組んでWebAssembly越しにJSから利用出来るようにするというのも手です。
|
|
41
|
-
|
|
46
|
+
そもそも物理演算の計算をサーバーサイドに逃すと言うことは、
|
|
42
|
-
|
|
47
|
+
GPU(グラフィックカード)を利用した方が得意なジャンルの計算ではないでしょうか？
|
|
43
48
|
|
|
49
|
+
もしそうならサーバーサイドに逃がす選択肢自体は悪くないように思えます。
|
|
44
|
-
|
|
50
|
+
Node.jsはGPU扱えますしね。
|
|
51
|
+
参考記事: [JavaScriptでGPUを簡単に扱えるライブラリ「GPU.js」レビュー、並列処理で多次元の演算が爆速に](https://gigazine.net/news/20200805-gpu-js/)
|
|
45
52
|
|
|
46
|
-
|
|
53
|
+
ですがまぁWebアプリの利用者全ての物理演算を
|
|
47
|
-
|
|
54
|
+
Webサーバのマシンに代わりにやれという状況になります。
|
|
48
55
|
|
|
56
|
+
一人や二人しか使わないのであれば最善でしょうけど、
|
|
57
|
+
もしWeb上に公開して不特定多数のユーザー達に利用してもらうつもりなら
|
|
58
|
+
1ヶ月何十万・何百万円するようなWebサーバを
|
|
59
|
+
AWS等から借りて運用する事になるかもしれません。
|
|
49
|
-
|
|
60
|
+
人気が出たら会社を立ち上げる等マネタイズが急がれるでしょう。
|
|
50
|
-
なのでDOMツリー上にDIVタグを100万個並べてstyleを付与して模様をうねうね変えるみたいな事はブラウザがフリーズしかねないので辞めましょう。
|
|
51
61
|
|
|
52
|
-
DOMのdata属性にもたせてそこから読み出すみたいな事も
|
|
53
|
-
死ぬほどパフォーマンスに悪影響が出るので、
|
|
54
|
-
状態を持たせるならJavaScript上の変数スコープに全てロードしてそこで管理しましょう。
|
|
55
|
-
|
|
56
|
-
もしレンダリングをアニメーションしたければ、
|
|
57
|
-
[requestAnimationFrame](https://developer.mozilla.org/ja/docs/Web/API/Window/requestAnimationFrame)を使う事も検討してみてください。
|
|
58
|
-
|
|
59
|
-
DOMへの書き出しは常に必要最小限
|
|
60
|
-
jQueryとか使っているならばReactやVueを使いましょう。
|
|
61
|
-
|
|
62
|
+
Node.jsのWebSocketが同時に捌ける接続数という制約もあります。
|
|
63
|
+
調査した感じだと数千人で頭打ちになり、その辺でも利用者に応じてサーバーマシンを増やす対策をしなければなりません。
|
|
62
|
-
|
|
64
|
+
Node.jsを捨てる選択肢も必要かもしれません。
|
|
65
|
+
参考記事: [WebSocket大合戦：Clojure、C++、Elixir、Go、NodeJS、Ruby](https://postd.cc/websocket-shootout/)
|
1
校正
answer
CHANGED
|
@@ -47,7 +47,7 @@
|
|
|
47
47
|
毎秒・毎フレームの描画をHTML上のDOMで操作しまくってませんか？
|
|
48
48
|
|
|
49
49
|
DOMツリーを弄る行為ってコスパが死ぬほど悪いんですよね。
|
|
50
|
-
なのでDOMツリー上にDIVタグを100万個並べてstyleを付与して模様をうねうね変えるみたいな事は
|
|
50
|
+
なのでDOMツリー上にDIVタグを100万個並べてstyleを付与して模様をうねうね変えるみたいな事はブラウザがフリーズしかねないので辞めましょう。
|
|
51
51
|
|
|
52
52
|
DOMのdata属性にもたせてそこから読み出すみたいな事も
|
|
53
53
|
死ぬほどパフォーマンスに悪影響が出るので、
|