はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Erlangではプロセス間通信はメッセージパッシングを通して行うのが基本だが、それだとやりとりをするプロセス同士が一対多の関係(便宜上、前者を__サーバプロセス__、後者を__クライアントプロセス(群)__と呼ぶことにする)にある場合に、サーバプロセスのメッセージキューが詰まってしまい、スケーラビリティの阻害要因となることがある。 そういった時には以前の記事で書いたように、__protected__ないし__public__なアクセス権限のETSを使って、クライアントのリクエスト時にサーバプロセスとの間でメッセージパッシングが行われない

最近、Rustでコマンドラインツールを書く機会があったのだが、完成物をローカル環境でビルドし、実際の環境で叩いてみたところlibc.soやlibssl.soのバージョンが異なると言われてしまい、実行することができなかった。 もちろん実行先の環境と同じ環境を用意してビルドしたり、もし実行先に不足するライブラリが存在するなら事前にインストールしておけば良いだけではある。 ただ、そのツール自体はいろいろな環境で手軽に使いたいと考えていたので、適当な環境でビルドしたコマンドバイナリをコピーするだけで利用可能な状態にするのが理想ではあった。 そのためいろいろと調べてみたところRustBookのAdvancedLinkingの節で紹介されている方法を使えば「OSはLinux (and マシンアーキテクチャが同一)」という制約はつくが、動的ライブラリへの依存がなく、かなりポータブルなバイナリが作成できそ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 紹介 『Stuff Goes Bad: Erlang in Anger』は『すごいErlangゆかいに学ぼう』の原著者のFred Hebertさんが書いた本。 ライセンスはCC BY-NC-SA 4.0でオンラインでPDFとして公開されている。 Erlang/OTPで構築したシステムの運用や調査に役立つ情報が色々と書かれている割には、周りで読んだことのある人が少なさそうだったので、ここで紹介してみた。 当初は要約的なものを書こうかと思っていたが、ここに書くには分量が多くなり過ぎてしまいそうだったのと、PDF自体が100ページにも満たなく

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

gravizoというサービスを利用すればMarkdownの中にGraphviz互換のグラフが埋め込める模様。 使用例 といった形式で表示するグラフを指定する。 以下、公式HPからの抜粋。 ソース: ![Alt text](http://g.gravizo.com/g? digraph G { aize ="4,4"; main [shape=box]; main -> parse [weight=8]; parse -> execute; main -> init [style=dotted]; main -> cleanup; execute -> { make_string; printf} init -> make_string; edge [color=red]; main -> print

今日はErlangの内部実装周りの記事を書きたかったのですが、それは準備が間に合いませんでした。 代わりに分散Erlangに関連する機能の性能測定をいくつか行ったので、その結果メモを載せさせて貰います。 ※ 測定方法は結構適当なので参考程度に なお、分散Erlang自体に関しては(例えば)『すごいErlangゆかいに学ぼう! 』の29章(web版)が詳しいので、そちらを参照のこと。 目的等 分散Erlangはメッシュ型のクラスタを組むので、台数が増えると性能が頭打ちしやすいかも、という話を以前にどこかで目にした覚えがあったので、実際にどうなのかを試してみたかった、というのがもともとの動機。 今回の目的は、(最大で)数百ノード規模のErlangクラスタを構築する際に、どこが性能上のボトルネックになり得るかをおおまかに把握すること。 特定のシステムやアプリケーションの全体の性能測定ではなく、標

この場を借りて、以下の条件に合致する自作ライブラリ群の紹介をさせて貰います。 Erlangで記述されている 一年以内に更新があった ある程度汎用性が高い ある程度(最低限)ステーブル rebarの構成に準拠 ※ 諸事情で準備時間があまりとれなかったため、今回は本当に軽い紹介だけで、あまり有益な情報はないです... hash_ring https://github.com/sile/hash_ring コンシテントハッシュ法の実装ライブラリ 現状備えている機能 ノードの追加・削除 特定のキーに対するプライマリノードの検索や優先順位に基づくノードの畳み込み 各ノードの重み付け ハッシュアルゴリズムや仮想ノード数の指定 実装上の特徴 Pure-Erlang and No-ETS 副作用なし 仮想ノード群を保持するためにタプルを使っている ノード数が100で、個々の仮想ノード数が256なら、約2.

日本語でHiPEについて触れている文書が少ない気がしたので、自分が知っている範囲の情報を取り留めもなく書いてみた。 ※ 経験ベースで書いているため情報の網羅性や信頼性にはあまり期待しないでください HiPEって何？ 「High Performance Erlang」の略。 HiPEコンパイラはOTPが提供する標準アプリケーションの中に含まれている(OTP17.3現在)。 HiPEコンパイラを使うと、ErlangのソースコードをVM(beam)のバイトコードとしてではなく、ネイティブコードとしてコンパイルしてくれる。 (JavaのJITコンパイラのように、実行時にネイティブコードへの変換を行なうわけではない) そのため、速度を重視したい(けどCで書く程ではない)モジュールを実装する場合に、HiPEが手軽な高速化の手段として重宝することがある。 HiPEを有効にするには ソースコードから自前で

読み込み(検索)処理の方が圧倒的に多いと予想されるようなKVS的なプロセスを、Erlang/OTPでどうやって効率的に(スケールアップするように)実装するか。 少し前にlocalという、名前のスコープを限定可能なプロセス名管理用ライブラリを実装した時に採用した方法のメモ。 結論 結論を先に書いてしまうと名前付きのETSを使うのが良い。 ETSを名前付き(and access=protected)にしておくことで、テーブルの所有プロセスを経由せずに読み込み処理を行うことが可能となる。 そのため、複数クライアントプロセスから同時に要求が来た場合でも、それらが(メッセージパッシングを通して)直列化されることなく、並列的に処理されることが期待できる。 実際に、今回測定した範囲では、ETSを使うことで読み込み処理はコア数に対してほぼ線形にスケールしていた。 実装例と性能比較 以降は、実際にETSを使