A description of our usual stack for building REST servers in Erlang Sep 06 2016 : Brujo Benavides
A description of our usual stack for building REST servers in Erlang Sep 06 2016 : Brujo Benavides
釣った反響に応えて echo サーバーを改良していて PyCon JP の発表資料作成が進みません。 自業自得です。 methane です。 Erlangとは何だったのか でのベンチマーク結果では Erlang のスコアが奮わなかったのですが、 github で 性能改善する pull request をいただきました。 性能が悪かった原因ですが、実は backlog がデフォルトだと 5 で、ベンチマーク開始時の 大量の接続要求を捌ききれていないという状況でした。 高負荷サイトのボトルネックを見つけるには で紹介されている事例と同じ現象ですが、こちらのほうが backlog が小さく、 しかもベンチマーク用クライアントはほぼ同時に大量に接続をしてくるという条件で よりシビアに現象が発生してしまいました。 この問題が修正された Erlang は、 Go を超えて一気にランキング上位に踊り出
まっちゃら @ FOLIO @matsu_chara なるほど?akka内部でブロックしたい場合はアクター単位でブロックするのは無理だけど、dispatcherを工夫すればブロックしてもExecutionContext的な物がことなるからThread.sleepをよんでも大丈夫そうという知見を得た 2016-02-27 16:57:40 まっちゃら @ FOLIO @matsu_chara 普通のdispatcherでやると同じdispatcherを共有してる奴も(当たり前だけど)止まってしまうけどPinnedDispatcherを使えば1actor1threadになるから影響を受けなくはなる。 gist.github.com/matsu-chara/33… 2016-02-27 17:00:57
View Source Distributed Applications Introduction In a distributed system with several Erlang nodes, it can be necessary to control applications in a distributed manner. If the node, where a certain application is running, goes down, the application is to be restarted at another node. Such an application is called a distributed application. Note that it is the control of the application that is di
When writing Elixir apps you’ll typically find yourself building up state in a map. Typically these maps contain deep nesting. Updating anything deeply nested means you have to write something like: my_map = %{ foo: %{ bar: %{ baz: "my value" } } } new_bar_map = my_map |> Map.get(:foo) |> Map.get(:bar) |> Map.put(:baz, "new value") new_foo_map = my_map |> Map.get(:foo) |> Map.put(:bar, new_bar_map
Once you’re ready to deploy your Elixir application to multiple servers, you’ll want to take advantage of the distributed features that the runtime offers. For example, if you are using Phoenix channels, you’ll want broadcasts to be sent across the cluster. You can setup your deployment as a cluster in a few simple steps: Start by creating a new sys.config file in your project. We’ll conventionall
A battle-tested programming language designed for the concurrency demands of modern computing. Erlang is a programming language designed with high availability in mind. It’s used to build massively scalable soft real-time systems with requirements on high availability. As a result, it is the best programming language to solve many of today’s computing problems. Many of the worlds largest banking,
Erlang の実行環境である BEAM の動作を理解するため、BEAM のスレッド構成を調査しました。 BEAM は SMP(マルチコア) 環境と非 SMP 環境では動作が大きくことなります。SMP環境と非SMP環境に分けてスレッド構成を記載します。 調査対象の OTP のバージョンは R16B03-1です。 非SMP環境 Erlang Interactive Shell を起動する際に、オプションとして '-smp disable' を付与すると、CPUはSMPでも、BEAMとしては非SMPモードで起動できます。 'erl -smp disable' で起動すると、11個のスレッドが見つかりました。11スレッドの内訳は以下のようになります。 スレッド名関数名個数 Main Threadprocess_main1 Async Threadasync_main10 Main Thread
First off, the md5 and sha1 cryptographic hash functions should only be used when security is not a requirement or when compatibility with legacy applications is needed. md5 was physically broken a very long time ago, and sha1 was theoretically broken back in 2005. When you need a hash for secure purposes, use a hash from the sha2 set (at least until sha3 starts appearing in libraries). Versioning
今日はErlangの内部実装周りの記事を書きたかったのですが、それは準備が間に合いませんでした。 代わりに分散Erlangに関連する機能の性能測定をいくつか行ったので、その結果メモを載せさせて貰います。 ※ 測定方法は結構適当なので参考程度に なお、分散Erlang自体に関しては(例えば)『すごいErlangゆかいに学ぼう! 』の29章(web版)が詳しいので、そちらを参照のこと。 目的等 分散Erlangはメッシュ型のクラスタを組むので、台数が増えると性能が頭打ちしやすいかも、という話を以前にどこかで目にした覚えがあったので、実際にどうなのかを試してみたかった、というのがもともとの動機。 今回の目的は、(最大で)数百ノード規模のErlangクラスタを構築する際に、どこが性能上のボトルネックになり得るかをおおまかに把握すること。 特定のシステムやアプリケーションの全体の性能測定ではなく、標
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く