Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby
Websocket Shootout: Clojure, C++, Elixir, Go, NodeJS, and Ruby by Jack Christensen on September 1, 2016 When a web application has a requirement for real time bidirectional communication, websockets are the natural choice. But what tools should be used to build a websocket server? Performance is important, but so is the development process. A performance benchmark alone is not enough. We also need
PCテクノロジートレンド 2016 - 次世代CPU/GPU、メモリはどうなる?
皆さま、あけましておめでとうございます。本年もよろしくお願いします。 ……とか書いてる今はまだ12月29日なんですけどね。それはともかく。2015年はProcessが不調な年であり、主要なチップメーカーがそろって新製品を出せずに苦労した年でしたが、これは2016年も続くことになりそうです。 半導体製造における"鍵"を握ってるのが「Process」という状況に変わりはありません。そんな訳で2016年のPCテクノロジートレンドもまずProcessから話をしていこうと思います。 編集注：PCテクノロジートレンドといえば、「スタッフの方の写真」ということで今回はスタッフ「まめっち」さんの写真をお送りいただきました。記事の各所にご登場いただいております Intel 14nmは落ち着きを見せるもまだまだ課題が 不調が続くIntelの14nm世代。Photo02～Photo04は2014年のInvest
プログラムを高速化する話
9. 9 最適化について 「細かい効率のことは忘れて、時間の 97% について考え よう。時期尚早な最適化は諸悪の根源だ。それでも残り 3% についても機会を逃すべきではない」 - Donald E. Knuth 「プログラム最適化の第一法則 : 最適化するな。 プログラム最適化の第二法則 ( 上級者限定 ): まだするな。 」 - Michael A. Jackson 11. 11 最適化の対象 主に Intel の Haswell マイクロアーキテクチャ以降を対象 多くのテクニックは他のプロセッサにも応用できます ベース マイクロアーキテクチャ プロセスルール 登場年 Nehalem Nehalem 45nm 2008 〃 Westmere 32nm 2010 Sandy Bridge Sandy Bridge 32nm 2011 〃 Ivy Bridge 22nm 2012 Hasw
mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
Macでtmuxのステータスラインに起動時間/ロードアベレージ/メモリ使用率を表示 - よんちゅBlog
タイトルの通り基本Mac限定です。 なぜかというと、メモリ使用率の取得に vm_stat (vmstatじゃないよ)というコマンドを使用しているからです。 vmstatはLinux系では有名なコマンドですが、残念ながらMacにはないんですよね。 Macのvm_statは名前は似ているけど表示される内容は随分違います。 あとメモリ使用率を調べるコマンドといえば free ですが、これもMacにはないですしね。 では前置きはこれくらいにして、どんな感じになるのかをどうぞ 一応説明すると、左から、LANG、起動時間、ロードアベレージ、メモリ使用率、現在時刻が表示されています。 起動時間が1日以上になるとこんな感じになります。 っで肝心の方法ですが、tmuxのステータスラインから自分で作成したスクリプトを実行するという方法です。 ですので以下の3つのスクリプトをPATHの通った場所に置いて、実行権
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Stuff The Internet Says On Scalability For June 3, 2011 - High Scalability -
