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