[過去ログ]
【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net (1002レス)
【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1460359714/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
レス栞
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
142: デフォルトの名無しさん [sage] 2016/05/17(火) 11:22:28.23 ID:vWciy/Ev >>141 そら、メーラーで防いでも無駄だし、メーラーか防ぐべきもんじゃないからね。 http://mevius.5ch.net/test/read.cgi/tech/1460359714/142
423: デフォルトの名無しさん [sage] 2017/04/05(水) 01:59:50.23 ID:T1xSqOuQ >>422 違うyo http://mevius.5ch.net/test/read.cgi/tech/1460359714/423
491: デフォルトの名無しさん [sage] 2017/04/08(土) 01:31:42.23 ID:Ibdd+rg/ Observableが得意なのはキャンセルだけじゃなくて 並列処理もなんで、fs.fstatを並列で実行したいときにも 簡単にかけるというメリットも有るな http://mevius.5ch.net/test/read.cgi/tech/1460359714/491
609: デフォルトの名無しさん [] 2017/05/15(月) 18:54:23.23 ID:ejKo8zg4 609 http://mevius.5ch.net/test/read.cgi/tech/1460359714/609
651: デフォルトの名無しさん [sage] 2017/06/07(水) 00:32:13.23 ID:kUtim7jQ >>647 たった5行でWebサーバーが書ける http://engineer.recruit-lifestyle.co.jp/techblog/2015-06-22-node1/ httpモジュールを使っている分、nodeだけのメモリ使用量ではないが、 ps uのRSSの値は26000KB、つまり26MBだが? http://mevius.5ch.net/test/read.cgi/tech/1460359714/651
653: デフォルトの名無しさん [sage] 2017/06/07(水) 00:46:45.23 ID:kUtim7jQ > nodeって起動するだけでメモリ相当食うから、バージョンアップでさらに増えてないかが気になる > 安いプランのVPSだとメモリ1Gとかだから >>631の文脈から言って、メモリを相当食う何かを動かしているのだろう。 だがそれはnodeの使用量ではなく、モジュールの使用量がほとんど。 nodeのバージョンアップでメモリ使用量が増えたとしても 大部分のモジュールの使用量は変わらないので、気にするレベルにはならない。 http://mevius.5ch.net/test/read.cgi/tech/1460359714/653
656: デフォルトの名無しさん [] 2017/06/07(水) 14:14:41.23 ID:Kk4r5o3h Cは現実的じゃない Goでおk それかRust http://mevius.5ch.net/test/read.cgi/tech/1460359714/656
798: デフォルトの名無しさん [sage] 2017/09/08(金) 19:24:30.23 ID:pIgMfxSJ >>790 MDISのケースは多分、図書館内端末用の界面にそのままWebを接続しただけだろ。 この場合、見た目は問題なく動く。 リソース枯渇のケースはコードから落とすしかないが、レビューが新規コードだけなら無理だ。 (この場合は新規コードはほぼ無しで、問題は今動作しているコード内にあるから) おそらくMDISもB方式で、自前でコネクションプーリングしてる。 これは館内端末用で、端末に行列が出来ているかどうかは知る由もないから、closeはタイムアウトで10分とした。 ここまでは妥当な設計で、館内端末なんて高々数十台だし、問題なく動く。 問題はこれをそのままWeb側にも解放したことで、 この場合は一気に端末数が無限大になるのと等価で、コネクションが枯渇した。それだけだろ。 本来は、 D. Webからの入力を受ける「仮想端末」を用意し、Web入力は一旦全部そこで受けてからDBアクセス。 E. open/closeを毎回やるようにする。(Aと同じ) のどちらかが必要で、本来はDの方がいいし多分そうしていると思う。 Dの場合はDDoS時にも館内端末は無傷で済む。 追加コードは仮想端末部分だけであり、既存コードには一切手を入れる必要がない。 Eの場合は全体のパフォーマンスが「いちいちopen/close」分だけ落ちる。 とはいえ真面目にDBを組んであればUIからでは見えないとも思う。 変更はopen/closeが内部APIで隠蔽されていれば数行、といったところか。 (そうなっていない場合は全体ソースを見直す必要があり、現実的ではない) http://mevius.5ch.net/test/read.cgi/tech/1460359714/798
839: デフォルトの名無しさん [sage] 2017/09/16(土) 09:45:53.23 ID:7pQmikz8 簡単な関数だよ $(name1, value1 ...) で>>829みたいな事をすれば良い http://mevius.5ch.net/test/read.cgi/tech/1460359714/839
967: デフォルトの名無しさん [sage] 2018/02/05(月) 07:30:15.23 ID:GXsl78kw node.jsでウェブサーバやる利点って何?超使いづらいんですけど http://mevius.5ch.net/test/read.cgi/tech/1460359714/967
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.034s