【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Node.js Foundationに対し不安を持つグループによるNode.jsのフォークプロジェクト「Ayo.js」誕生
https://mag.osdn.jp/17/08/25/163000 シングルスレッドだから遅くならないなんて言っている人なんているかねぇ？
C10Kの話ならかなりニュアンスが違う。 優秀な一名をこき使うから速いんだな。
ほんの少しでも空時間があったら仕事をぶっこむ。
人間なら死ぬわ。 >>738
メモリ使用量が増えないってnodeのメリットじゃないの？
そんなのスケールアウトで十分だと思うんだが > メモリ使用量が増えないってnodeのメリットじゃないの？
だれがメモリ使用量が増えないというメリットが有ると
いったんだ？ お前の脳内か？ nodeが良かったのはは非同期apiにより
プロセスあたりのリクエスト処理数を高めたからでしょう？
マルチプロセスにすればその分リクエスト処理数もある程度スケールしてくれる。ただしdbアクセスは考慮しないものとする >>743
nodeとは全く別もので、ただのデータベース Nodeが普及したのは良いサイバーサイドJS環境だったから let dict = {}
で辞書のように使おうとしたんだけど、
dict['constructor']ではまった
アレイにkvペア入れて頑張るしか無いの?
16万項目あるので線形検索は躊躇う Mapを使うとかlet dict = Object.create(null)とか >>746
16万項目のデータをメモリ内に置くのか。
もっといい方法無いかな。realmとか使えればいいんだけど。 Object.createで上手くいった
try catchで検出してエラーになるのを、別管理と考えてたけど、すっきりした
さんきゅ >>748
db構築に使うフォーマット変換ツールなので、適切な時間で終了する事が要件で
利用リソース量はあまり気にしない eslintとそれにぶら下がるプラグイン本当互換性がない
ツール入れる所でトラブらないといけないとかだるいわ
これだからJavaScriptなんて書きたくないんだよ eslintのプラグイン何を使おうとしてるの？
使わなければいいじゃない >>742
そういうのもNginxやApacheがある程度やってくれるようになってるからね。
後ろは好きな言語をそのまま使えばいい。PHP-FcgidとかuWSGIとかRackとかServletとか。 >>755
非同期apiはphp処理系では無理じゃない？phpはインスタンスの生存時間がリクエストを受けてからレスポンスを返すまでの固定だよね。
どうやってイベントループ回すの？ >>756
フレームワークによってはイベントループで生存期間が無限のものもあったはず。
前の会社で、そういうWebSocketフレームワーク使おうとしてたよ。
…そんな用途全く想定してない普通のPHP用のオレオレライブラリ組み合わせて
メモリリーク起こしてたけど（藁 >>757
メモリリーク起こすなら使えないな。
phpってインスタンスの生存時間短い前提だから、
メモリリークってさほど気にしなくて良い言語なのかも。
素直にjsでいい気がするけどね。今の時代。
yahooで勤務してる知り合いも今はjsでサーバサイドを書いてるってさ。 もともとCGIはリクエスト毎にプロセス作ってサービスしてた
なので、一つのリクエストが終了するとperlやphpのプロセスも終了するので、オブジェクトを解放(リファレンス外す)しないCGIが多くある
ところが、これじゃおせーよと言うことで、終了させないで無理やりに複数リクエストを処理させる仕組みをでっち上げた
これがPHP-FcgidとかuWSGI
リークしまくりのサービスが出来上がり
三菱とかやりそうだろ だから一定数のリクエストを処理したらプロセス再起動する
三菱でも大丈夫 メモリだけじゃなくて
CPUもファイルI/Oも簡単に食い潰せるからな >>760
なるほどね。大雑把な作りだ。
大昔Dephiの案件をやった時に、PLが
ひとかたまりのEXEを画面ごとにバラバラのEXEにして
切り替えるたびに終了させる仕組みを作り出して、メモリリークを
極力抑える仕様にしてたの思い出した(データはDBにおいてる) >>760
三菱は自動再起動なんて技術がないから、連絡受けて手動で再起動してた 何故、三菱が引き合いに出されるのだ?
なんかやらかしたんかい。 三菱電機インフォメーションシステムズ (MDIS) 製のソフトウェアは、
1時間に400以上リクエストを送られると他のリクエストの処理が不可能になる不具合を含んでいた
これか?
9秒に1回以上で破たんするなんてどんな実装か興味津々 そもそもDOMとのメモリリークとかまともに対応してきたJS界のエンジンが優秀過ぎるだけで
他のサーバサイド言語で環境を跨いた循環参照とか上手く処理できるエンジンは無いし、他のGC技術や調整も何年も遅れてる WebアプリでDBコネクションを10分間も保持するなんてどういう実装したらできるんだろ?
普通にやったんじゃできないよね。 >>769
expressだって、グローバルスコープの変数にコネクション保持すれば、その参照切るまで残るぞ >>769
膨大な数のリクエスト処理するのになぜ閉じるのかが逆に理解できないんだけど
普通WebアプリやサービスのDBはつなぎっぱなしだとおもう Webのセッションが終わってるのにコネクションをセッションのために１０分間保持してたって事でしょ?
普通はコネクションは閉じないがWebのリクエスト毎に紐付けは開放でしょ。 >>775
三菱に限らずSIerの技術力低下が半端ない 自分達の底辺技術レベルが原因で、無実のエンジニアを罪人にして、ほっかむりしたのは三菱だけ ちなみにDBってopenとtransactionを分離している奴があるけど、これって何で？
例えばIndexedDBでもそうで、open後にtransactionを作ってアクセスしなければならない。
しかし普通に読み書きだけなら
DBWrite(DBname, objectStores, key, value)
みたいなAPIでクエリ毎にopen/close繰り返した方が使う側は楽だよね。
何らかの理由でopenが重いから分離しているのだろうけど、
普通に実装すればそんなに重いとも思えない。
（実際はopenは数秒かかる時もある程重いが）
これって何で？
ちなみに類似ケースはXHRで、通常は毎回XHRをnewするだろ。
indexedDB.openもそれに近くて、本来はオブジェクトを初期化するだけで終わるはず。 >>769
> WebアプリでDBコネクションを10分間も保持するなんてどういう実装したらできるんだろ?
> 普通にやったんじゃできないよね。
コネクションプールを使ったら普通にそうなりますが？ >>779
DBをopenしてselectしてcloseするなら
トランザクションいらないでしょ？ >>779
> 何らかの理由でopenが重いから分離しているのだろうけど、
> 普通に実装すればそんなに重いとも思えない。
ゆえにopenが重いから分離しているという
あなたの想像は間違いだって言うこと。
根拠のない想像を結論にしないようにしよう
検証の前にあるのは結論ではなく仮定という
トランザクションは複数の操作を一塊にするもので
openが軽いのとは関係ない話 >>781
IndexedDBの場合はトランザクションは常に必要だ。
他の楽観的なトランザクション分離のDBについては知らん。
>>782
では何故openとtransactionを分離するんだ？
最初からtransaction単位でopen/closeするAPIにしておけばいいだけの話だろ。
そこを分離して手動でやらせる理由が分からん。 IndexedDB特有の話なら、IndexedDBの話だって書けよ
はい、トランザクションつかってませーん。ばいなら
http://qiita.com/butakoma/items/2c1c956b63fcf956a137#%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%82%B9%E3%83%88%E3%82%A2%E4%BD%9C%E6%88%90
オブジェクトストア作成
オブジェクトストアは、RDBでいうテーブル。
var storeName = 'sampleStore';
var openReq = indexedDB.open(dbName, dbVersion);
// オブジェクトストアの作成・削除はDBの更新時しかできないので、バージョンを指定して更新
openReq.onupgradeneeded = function(event){
var db = event.target.result;
db.createObjectStore('storeName', {keyPath : 'id'})
} IndexedDB特有の話ならtransaction使わないと
readonlyなのかreadwriteなのか決められないからだろ >>779
DBへの接続(open)とトランザクションは別のレイヤーだからだよ
1つの接続で2つのトランザクションを実行したい場合どうすんの？
transactionを明示的に指定しない場合に
デフォルト設定で例えばステートメント単位でトランザクションになるような仕組みがDBにあればtransaction指定は必須でなくなる
一般的なRDBはそうなってると思うけど >>784-785
つかお前根本的に分かってないだろ。
IndexedDBはonupgradeneededの時は最初からトランザクションを張っている。
これはMDNからはとてもそうは読めないのだが、とにかくそう。
そしてAPIが
> DBWrite(DBname, objectStores, key, value)
> DBWrite
とかでいいのではないか？というのが俺の疑問なのだが。
何故かは知らんがDBには「繋ぎっぱなし」の文化はあるんだよ。>>772
IndexedDBのAPIからもそれは読みとれる。
> Web アプリが別のタブで開かれているときにバージョンを変更する
> https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB
毎回閉じる文化ならそもそもこれは要らない。
MDISはこの「繋ぎっぱなし」の文化でWeb側にも解放したらリソースが枯渇しただけだろ。
ただそもそもこの「繋ぎっぱなし」ってなんなのさ？
open/closeが軽いのなら毎回open/closeすればいいだけだし、
普通に実装すれば重いとも思えないし、ということなのだが。
（ただし実際にはIndexedDBでもopen/closeは重い） >>786
> transactionを明示的に指定しない場合に（以下略）
これについてはそれでいい。
APIコール1回＝1つのtransactionになるって事で。
> 1つの接続で2つのトランザクションを実行したい場合どうすんの？
これってどういうケース？
その2つのトランザクションをくっつけて1つのトランザクションにしておけばいいだけの話では？
並列性を限界まで出したくて、例えばライト/リードでトランザクションを分けておきたいとかか？ >>788
1回の接続で複数トランザクションを実行したいケースってあんまりないのかな
例えば２つのトランザクションのうち後者が失敗しても前者をロールバックしたくない時とか考えてみたら？
トランザクションのたびに再接続するので良いケースもありうるけどそうじゃないケースもありうるよね
だから一般的にはトランザクション境界と接続の開閉を一つにしたAPIってのはいい設計じゃないと思う
>>787
繋ぎっぱなしの文化なんかなくて、ただの開放漏れのバグだよ
openしたらcloseするのが必須 >>780
コネクションプーリングはコネクションを使いまわす仕組みだからDBには繋がったままだけどWebのセッションからはリクエストの度に切り離される。
とっくに終わってるセッションがコネクションを独占するようなアホな作りはどうやったらできるのかって事。 >>787
繋っぱなしってコネクションプーリングのことでしょ。アプリから見ると毎回、open/closeしてるように見える。 >>790
コネクションを独占ってなんだ？
異なるセッションから、コネクションを使いまわすのがコネクションプーリングなんだが？
セッションが終わってるっていうのなら、コネクションは明け渡してるだろ >>787
> IndexedDBはonupgradeneededの時は最初からトランザクションを張っている。
じゃあなおのこと、openでトランザクションは貼れないな。
だって、何の操作をするかで、トランザクションの種類が変わるわけで
openした時点ではわからないんだから >>787
> そしてAPIが
> > DBWrite(DBname, objectStores, key, value)
> > DBWrite
> とかでいいのではないか？というのが俺の疑問なのだが。
トランザクションは複数のDBWriteを
一つにまとめるものなんだから
それじゃだめだろって言ってるんだが？
いいからトランザクションを勉強してくれ
お前、根本的に分かってない（笑） >>789
ただのバグでMDISが糞だというのは同意だが、APIは糞だぞ。
> 例えば２つのトランザクションのうち後者が失敗しても前者をロールバックしたくない時とか考えてみたら？
これなら2つトランザクションを打てばいいだけ。それで何の問題もない。
> トランザクションのたびに再接続するので良いケースもありうるけどそうじゃないケースもありうるよね
ねえよ。具体的に挙げられないだろ。
open/closeがAPIにある場合の利点は、連続した同一DBに対する2つのトランザクションで、
・open/transaction1/close/open/transaction2/close
を
・open/transaction1/transaction2/close
とでき、真ん中のclose/openを省ける分速度が稼げることだ。
しかしこの場合に、DB内部でキューイング機構を持ってこの余分なclose/openを自動的に省き、
・ユーザ側で手動open/closeした場合と、
・ユーザAPIはトランザクション単位で、DB内部で自動open/close
で、パフォーマンスが全く変わらない場合、前者を使う理由がないだろ。
(現実的にはユーザ側でコネクションプールを実装する必要であり、
これの代替としてDB内部でキューイング機構を持っていてもパフォーマンスは変わらないはず）
open/closeをユーザ側に見せている時、ユーザ側の解は以下で、
A. いちいちopen/closeして使う。
B. これがウザイから自前でラッパを用意し、
> アプリから見ると毎回、open/closeしてるように見える (>>791)
ようにする。
C. さらにこれもウザイから、何らかの既存ラッパ(PouchDBとか）を使う。
だろ。俺はまずAを試し、スループットが全く出ないのでBにしたが、車輪の再開発感ありまくりだった。
コネクションプーリングするのが常なら、最初から付けとけよボケ、でしかない。
（なおPouchDBもdb.open必須。多分これがDBのAPIの標準形だからだと思う） DBのAPIは意味不明で、そもそもオブジェクト指向にも反してる。
ユーザがやりたいのはread/writeであって、open/closeではない。
File.openの代わりにHDD.open+File.readというAPIにする奴がいたら、死ねでしかないだろ。
open/closeってもしかして今みたいなパケット相乗り回線ではなく、専用回線を掴んでいた時の名残か？ >>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で隠蔽されていれば数行、といったところか。
(そうなっていない場合は全体ソースを見直す必要があり、現実的ではない） >>796
もうめんどくさいな君w
DBへの接続とトランザクション境界を一致させた画期的APIを作って流行らせればいいよ？
一つのユースケースたけに特化したものとしては別にあっても悪く無いと思うよ
ただなぜそういう設計のものが存在しないのか考えてからね >>797
> ユーザがやりたいのはread/writeであって、open/closeではない。
そのうち二回のwriteを実行して二回目のwriteで
エラーが起きた時に一回目のwriteもロールバックするために
トランザクションがあるんですよ？ https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Using_IndexedDB#Getting_data_from_the_database
データベースからデータを取得する
よーし、今から customers テーブルのデータを読み込むぞー！
var transaction = db.transaction(["customers"]);
おい、ちょっとまて俺はdbオープンした時に
自動的にトランザクション実行するぞ！
全てのテーブルに対してreadwriteロックじゃ
誰も読み込みも書き込みもできない
俺はcutomersテーブルなんか触らないけどなｗｗｗ
こういう迷惑バカが居るから、openとトランザクションは別にするべき >>798
open/closeのパフォーマンスを気にしてるのはお前だけだ
忘れろな >>798
> 問題はこれをそのままWeb側にも解放したことで、
> この場合は一気に端末数が無限大になるのと等価で、コネクションが枯渇した。それだけだろ。
誰もコネクションが枯渇したなんて言ってない >>798
当たり前すぎることだが、MDISのシステムは
「1時間に400以上リクエストを送られると他のリクエストの処理が不可能になる不具合を含んでいた」
と言ってるだけで、
ウェブのクライアントが直接DBに接続したなんて誰も言ってない。
そもそもそんなことはできない
ブラウザからデータベースに接続することなんてできない。
IndexedDBはお前、それブラウザん中に実装されてるもんだ。そこを勘違してたわけかｗ
MDISのシステムはIndexedDBを用意してなんかいない。時代的に使ってすらいないだろう
本当に当たり前のことだが、
> D. Webからの入力を受ける「仮想端末」を用意し
仮想端末じゃなくて、普通はアプリケーション・サーバーっていうんだよ。
PHPだとウェブサーバーの場合もあるな。MDISも当然その仕組みだ
> E. open/closeを毎回やるようにする。(Aと同じ）
open/closeを毎回やっても、パフォーマンス向上のために内部的にデータベースに
接続しっぱなしにする機能がコネクションプールだ。正確言うと
前回のリクエストで使った（使い終わった）コネクションを使いまわす。
> 変更はopen/closeが内部APIで隠蔽されていれば数行、といったところか。
あははｗ ばーかｗｗｗ アプリは毎回open/closeをしてるんだよ。
コネクションプールというミドルウェアがcloseした時になにもしないように置き換えてるんだよｗ >>802
少なくともコネクションプーリングを考えたヤツはopen/closeのコストが大きいと考えてる。
数十ミリ秒と数ミリ秒の差が影響するシステムもある。 連想配列のキーに使用できる文字列の仕様ってどこに載ってますか？ 連想配列にキーが存在するかチェックするのならinが速いな
const o = {
'a': 1,
'b': 2,
'あ b': 3,
};
const key = 'あ b';
const l = 100000;
console.time();
for (let i = 0; i < l; i += 1) {
key in o;
}
console.timeEnd();
console.time();
for (let i = 0; i < l; i += 1) {
o.hasOwnProperty(key);
}
console.timeEnd();
//undefined: 5.921ms
//undefined: 9.741ms 連想配列ならMapが最強
従来のオブジェクト形式が良いにしても
o = Object.create(null)でo[key]の方が早い >>806
だからなんだよ。
トランザクションの話をしてる時に
open/closeのコストを考えるなって話だろうが >>808
> 連想配列にキーが存在するかチェックするのならinが速いな
一回あたり
59.21ナノ秒（＝0.00000005921秒）
97.41ナノ秒（＝0.00000009741秒）
だと10万回〜100万回ぐらいチェックしない限り
速度を気にしたって意味なさそうだね。 Object を連想配列にした場合、キーを、__proto__ にすると誤動作するから、
そのキーだけ、特別な処理が必要
他にも、使えないキーがあるかも >>813
どういう時に __proto__ をキーに使ったの？ 英文から、すべての単語を取り出して、出現回数でも調べたのかな？
どこかのサイトで、そういう質問を見た >>815
そういう場合は、適当なプリフィックスをつけるだけで解決するね
obj['@' + word] = なんとか Object.create(null)で作ったオブジェクトには__proto__は無いし自由に値を設定できるこれ豆 Object.create() は、ECMA 5.1, IE9 以上か
こういう機能が無かった、ES3 の頃の話かな chromeのdevtoolsからconsole.dir({})やるとオブジェクトの中身が見れるけど
nodejsの場合はどうやって見るんでしょうか？ ○次受けが多いほど退場率が早くなる。高くなる
直受けの50万 客：いつまでもうちにいていいよ
3次受けの50万（客は90万払ってる) 客：短期延長していい？
5次受けの50万（客は150万払ってる) 客：作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
フリーランスサイトを運営している零細ITの自称エージェントは労働市場から流れてくる案件を転売してるだけだった。
労働市場に加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×3 = 言い値50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - エージェント×1 悪質な言い値で50万以下
エンド - ユー子 - エージェント-JIET 公表価格 90~60 - JIETに加入して公表価格で応募できる
eJobgo JIET JISA で検索
優良エージェント・優良サイト
首都圏IT(PE-BANK) プログラマーズ https://github.com/rook2pawn/node-ddos
調べ物をしている最中にこんなの見付けたんだけど
Httpdがリクエスト受け取ってる時点でDDoS対策にならないんじゃないの？ >>822
動作の軽いリバースプロキシ立ててそこで対応するほうがよさそう node 8はこの秋LTSになるんだからアグレッシブに最新機能は入れないよ
node 9には入る const o = {
a: {name: 1},
b: {name: 2},
};
↑をObject.create(null)で作りたいんですけど
const z = Object.create(null);
z.a = Object.create(null);
z.a.name = 1;
z.b = Object.create(null);
z.b.name = 2;
console.log(z.a.name, z.b.name);
こう書くしかないんですかね？これだと読みづらくて1番目のようにデータが見やすく作る方法ってないですか？ なんでObject.createしばりなの？
リテラル使っちゃだめな理由は？ >>829
Object.assign(Object.create(null), { a: {name: 1}, b: {name: 2}, }) ;
>>810
undefinedと比較 >>833
Object.assignはシャローコピーだから>>829と同じじゃない
undefinedとの比較は>>809とは違うしどっちみちundefinedを値として使うと破綻する ■ このスレッドは過去ログ倉庫に格納されています
