任天堂 ネットワークシステム部 わたなべ たいよう 渡邉 大洋 私たちは、家庭用ゲーム機 Nintendo Switch (TM) 向けに、プッシュ通知のシステム「Nintendo Push Notification Service (NPNS)」を開発・運用しています。 NPNS には常…
erlangに関するheavenshellのブックマーク (52)
-
heavenshell 2019/06/02
-
-
-
Erlang(Elixir)の使いどころについて使ってる人から教わった話
t_yano @t_yano Erlang/Elixir（というかBEAM）について「速い」と記事書くと有識者の方々から暗に殴られる事件を数件見つつ、最近読んだbeamのコンテキストスイッチ手法思い出すと、まあ、この動きすごいキレイ（一定頻度でプリエンプティブにスイッチする）だけど、速くはないわなって思った 2016-05-17 21:15:29 t_yano @t_yano BEAM決して速くない、速さを求めるならGoをやれ、安定性を求めるならbeamをやれってことみたい。Erlangイカ本だと、バイナリデータを大量に処理するには向かない、でもAPIサーバなら十分な速度が出るって書いてて、つまり個々の「処理」の速さを求めてはいけないってことかな。 2016-05-17 21:17:35
-
-
How Erlang does scheduling
In this, I describe why Erlang is different from most other language runtimes. I also describe why it often forgoes throughput for lower latency. TL;DR - Erlang is different from most other language runtimes in that it targets different values. This describes why it often seem to perform worse if you have few processes, but well if you have many. From time to time the question of Erlang scheduling
-
ActorDB | Distributed SQL database with linear scalability
Features ActorDB is strongly consistent, distributed and horizontally scalable. Based on an industry-proven reliable database engine. Scalable ActorDB can run on a single server or hundreds. It can store gigabytes or petabytes. Features Full relational database within an actor. Queries and transactions over multiple actors. Redundant. Massively concurrent. No single point of failure. ACID. Connect
-
アクターによる並行処理アーキテクチャの解説 - はこべにっき ♨
社内勉強会でアクターによる並行処理アーキテクチャについて解説した時の資料です。しれっと公開してあった資料に思いの外ブクマがついていたのに気付いたので、せっかくなのでこちらにも掲載しておきます。 既存技術の解説なのでアクターについて知っている人にとって新しい情報はないと思います! 特に何ベントカレンダーでもないです。 今後Erlang使うの? Erlang VMの運用ノウハウなさすぎるので、すぐ使おうという機運はなさそう。ScalaのAkka Actorが十分実用的なアクターシステムらしいし、Scalaは導入済みなのでそちらのほうが有力な選択肢になるか。アクターシステムではないが、goでも近いことはできるのでさくっと並行処理システムを構築するには良いと思う。趣味ならElixirつかいたい。 参考文献 良い資料がいろいろあって、多分に参考にさせていただいています。ながめると理解が深まるかもしれ
-
spawn, proc_lib, gen_server の使い分け
ドワンゴが誇る Erlang ハッカー @soranoba 氏がこのあたりの話をしていたので、自分が考える使いどころを書いていこうと思う。 あくまで個人意見だし、何がベストとかはケースバイケースだろう。アプリを書くなら spawn や proc_lib はできるだけ使わないようにするべきだ。ただライブラリであれば proc_lib を使うのは特に問題ないと思う。 結論: メモリーリークを避けるために gen_server をできる限り使うべき プロセスが依存関係になったり連携するだろう。これをうまく処理するために gen_server を使うべきなのだ。 spawn_link でもうまく取得できるが terminate という概念はなくなる。例外が起きたときに気づけないのが一番まずい。 正常系を考えたらどれを使ってもかまわない。問題は何かが起きたときに何事もなかったように綺麗に処理されるた
-
リアルタイムWebフレームワーク、N2Oを使ってみる - Qiita
これは、Erlang Advent Calendar 2015 の14日目の記事です。 はじめに 私は仕事では主にフロントエンドの開発をしているのですが、時には株価やニュースなどリアルタイム性の高い機能の実装が必要になる事もあります。 先日、WebSocketを使ったリアルタイム性の高いWebアプリを作りたい、と思い調べていたところ、N2Oというフレームワークがあることを知りました。 もともとは別のErlang製WebフレームワークであるChicagoBossを調査していたのですが、プロジェクトのページにComparison of Erlang Web Frameworksという比較表があり、機能が高く速そうだったことから興味を持ちました。 N2Oについて N2O(H2Oじゃないよ)はウクライナのSynrc Research Centerという会社で開発されたWebアプリケーションフレーム
-
アクターによる 並行処理アプケーション アーキテクチャ
社内勉強会でアクターとアクターを使ったアプリケーションのアーキテクチャについて紹介した資料です
-
-
HiPE(High Performance Erlang)について - Qiita
日本語でHiPEについて触れている文書が少ない気がしたので、自分が知っている範囲の情報を取り留めもなく書いてみた。 ※ 経験ベースで書いているため情報の網羅性や信頼性にはあまり期待しないでください HiPEって何？ 「High Performance Erlang」の略。 HiPEコンパイラはOTPが提供する標準アプリケーションの中に含まれている(OTP17.3現在)。 HiPEコンパイラを使うと、ErlangのソースコードをVM(beam)のバイトコードとしてではなく、ネイティブコードとしてコンパイルしてくれる。 (JavaのJITコンパイラのように、実行時にネイティブコードへの変換を行なうわけではない) そのため、速度を重視したい(けどCで書く程ではない)モジュールを実装する場合に、HiPEが手軽な高速化の手段として重宝することがある。 HiPEを有効にするには ソースコードから自前で
-
Erlang 開発専用 Vim 設定 - Qiita
もし、「無人島に行って Erlang を書け。最小限の .vimrc だけは持って行って良い」と言われた場合に備えて設定を考えました。 非同期 無人島では時間を有効に使わないと死が待っています。tag ファイル作成や cache 作成を同期でやっていては死にます。 vimproc https://github.com/Shougo/vimproc.vim NeoBundle を使用していれば、特に設定は必要ありません。 補完 すべてのプログラムを手動でタイプしていては時間切れで死にます。 neocomplete https://github.com/Shougo/neocomplete.vim vim-erlang-omnicomplete https://github.com/vim-erlang/vim-erlang-omnicomplete 特に設定は必要ありません。 " Launc
-
Erlang 基礎ポイント7 - 分散処理 - DukeLab
久しぶりのErlangですね。 今日は分散処理について勉強したいと思います。 Erlangで分散処理? 今までは一つのサーバで一つのErlangシェルを立ち上げて勉強しましたが、 実はErlangは複数のサーバがネットワークを作って、 大規模な動作をするのに適した仕組みを持っています。 簡単に複数のサーバをつなげて何かができるってことは楽しいですね。 Erlangノード 今マシンで動いている一つのErlangプログラムをErlangノードといいます。 正確にいうと、Erlangプログラムを動かしているErlangの仮想マシンをいいます。 JavaのJVMのようなものが立ち上がっていると考えればいいでしょう。 JVMは同じマシンで複数実行できますね。 同様にErlangも同じマシンで複数実行できます。 同じマシンでErlangプログラム2個実行した? つまり、erlコマンドを2個実行したとい
-
-
超高速なJSON APIをElixirフレームワークのPhoenixでビルドしてテストしよう | POSTD
連絡先リストの役割を果たすJSON APIをビルドしてみましょう。ElixirとPhoenixを使って書きます。 Phoenix はElixirベースのフレームワークで、記述の高速化と、低遅延のWebアプリケーションをできる限り楽しく作成する目的で作られています。ElixirやPhoenixのインストール手順についてはここでは触れません。まず初めに Phoenixのガイド を読んでください。 なぜElixirとPhoenixなのか Erlanｇは、ポンコツの板金にくるまれたフェラーリのようなものです。ものすごいパワーを持っていますが、見た目が悪いと感じる人が多いのです。WhatsAppはこれを使って膨大な数の接続を処理していますが、見慣れないシンタックスとツールの不足のせいで多くの人が苦労しています。 Elixir はそこを改善したものです。Erlang上に構築されていますが、美しくかつ楽
-
Akka vs Erlang - Qiita
Erlang Advent Calendar 2014の22日目です。よろしくお願いいたします。 最近すごいErlangゆかいに学ぼう！を読んだので、Akkaとの違いをまとめてみることにしました。 AkkaもErlangもアマチュアなので正しくない部分があるかもしれません。その場合はご指摘ください。 Erlangは特に素人で、AkkaのactorとErlangのプロセス間でメッセージパッシングしてみたの記事で初めて「-compile(export_all)」でないプログラムを書いたレベルです。 Akkaとは AkkaはErlangにインスパイヤされて制作されたオープンソースのライブラリです。 アクターモデルで並行処理を記述し、スーパーバイザーツリーにより高度な耐障害性を実現し、また分散システムを実装してくれるのを助けてくれる、そのようなフレームワークとなっています。 Java用のAPIとS
-
Elixir のプロセスを使ってフェイルセーフなアプリケーションを作る ─ 失敗は恐れず泥水にダイブ - Qiita
[翻訳] Elixirのプロセスアーキテクチャ または私は如何にして心配するのを止めてクラッシュを愛するようになったか にもあるように Elixir においては例外処理は、それを頑張ってなんとかしようとするのではなく、軽量プロセスのコンテキストでむしろすすんでクラッシュさせてしまえ、というのが良い作法である。 クイズ番組で ○ か × か答えを選んで壁に突っ込んだ先に、正解ならクッションが、不正解なら泥水があるという企画があるが、それに喩えるなら 泥水だろうが何だろうが躊躇せずダイブしろ! というのが Elixir 流 (俺調べ) である。 もとい、クラッシュさせてどうするのかというと Supevisor を使って、別プロセスから該当プロセスを監視しておいて、クラッシュしてもアプリケーション全体としては間違いなく動いている状態を保証するのが正しい。 カッとなってちょっとそのための例を書いて
-
リアルタイムウェブな観点からElixir / Phoenix について - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ここ最近、 [翻訳] Elixir - 次に来る大物Web言語 - Qiita とか 超高速なJSON APIをElixirフレームワークのPhoenixでビルドしてテストしよう | POSTD を読んで気になっていたので、勉強していた。 前提: 自分はシングルページアプリケーションに特化したフロントエンドエンジニアであり、サーバサイドのプロダクション運用にはそこまで強くない。あとこれはここ2日の勉強した日記でもあり誤解や勘違いも多々あると思う。 リアルタイムウェブアプリケーションのためのサーバー Railsの次の時代、リアルタイムウェ
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました