Introduction of Happy Eyeballs Version 2 (RFC8305) to the Socket library

Introduction of Happy Eyeballs Version 2 (RFC8305) to the Socket library
よくある背景 よくある理由でIE対応を迫られて、ありがちな理由でPOSTなのにURLにパラメータがくっついてくるという ありふれた問題にぶつかったまでは良かったのだが(悪かったのだが) RESTfulなAPIに対応するという点で少しはまったのでメモ。 試したこと 最初はよくある解決策として、PUTで送りたいときに POST http://hostname/api/member/1?_method=putと、POSTと_methodによるディスパッチを試みた。 とりあえすSinatraを使っていたので、公式サイトを見て require "sinatra" configure do enable :method_override end put "/" do "koreha put desu." end post "/" do "post desu. shippai desu." end と設
はじめに いま開発中のRailsアプリケーションのRackサーバーは最初Unicornを使っていたのですが、諸々の事情でPumaの方を使いたいということになった。 まだリリースもしていないのでやるなら早めに変えちゃおうということでPumaについて調べてみた。 Pumaとは Pumaとはスピードと並列性を追求したRubyのWebサーバーです。 RubyでWebサーバーを作るときの標準となっているRackに対応したライブラリになっています。 スレッドベースのWebサーバー Pumaではリクエストの並列処理を実現するためにスレッドを利用しています。 リクエストを処理するためのスレッドを予めスレッドプールに指定した数だけ用意しておきます。リクエストが来るとそのスレッドに処理を任せることでスレッドベースの並列処理を行っています。 Rubyの処理系について Pumaではスレッド用いるため、Rubyの処
Rack や WSGI の代わりになる仕様を考えてみました (ライブラリ (rack.rb や wsgiref.py) のほうではなく、プロトコル仕様のほうです)。自分のアイデアを書き連ねただけなので、まとまってないかもしれませんがご了承ください。 なお本稿は、今後何度か改訂すると思います。ご意見があればご自由にコメントしてください。 【対象読者】Rack や WSGI に興味のある人 【必要な知識】Rack や WSGI の基礎知識 Rack と WSGI の概要 Ruby の Rack や Python の WSGI は、HTTP のリクエストとレスポンスを抽象化した仕様です。 たとえば Rack では: 引数として、リクエストを表す Hash オブジェクトを受け取り、 戻り値として、レスポンスのステータスコードとヘッダーとボディを返します。 class RackApp def cal
Rhebok, High Performance Rack Handler / Rubykaigi 2015 This document discusses Rhebok, a high performance Rack handler written in Ruby. Rhebok uses a prefork architecture for concurrency and achieves 1.5-2x better performance than Unicorn. It implements efficient network I/O using techniques like IO timeouts, TCP_NODELAY, and writev(). Rhebok also uses the ultra-fast PicoHTTPParser for HTTP reques
unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help help / color / mirror / code / Atom feed* [ANN] unicorn 5.0.0 - Rack HTTP server for fast clients and *nix @ 2015-11-01 8:55 Eric Wong 0 siblings, 0 replies; only message in thread From: Eric Wong @ 2015-11-01 8:55 UTC (permalink / raw) To: ruby-talk, unicorn-public Unicorn is an HTTP server for Rack applications designed to only
(追記:2012-12-25) 本記事およびこれに続くRackの記事(全4本)をまとめて電子書籍化しました。「Gumroad」を通して100円にて販売しています。内容についての追加・変更はありませんが、誤記の修正およびメディア向けの調整を行っています。 電子書籍「エラーメッセージから学ぶRack」EPUB版 このリンクはGumroadにおける商品購入リンクになっています。クリックすると、オーバーレイ・ウインドウが立ち上がって、この場でクレジットカード決済による購入が可能です。購入にはクレジット情報およびメールアドレスの入力が必要になります。購入すると、入力したメールアドレスにコンテンツのDLリンクが送られてきます。 詳細は以下を参照して下さい。 電子書籍「エラーメッセージから学ぶRack」EPUB版をGumroadから出版しました! 購入ご検討のほどよろしくお願いしますm(__)m Rac
新規アプリケーションの構成 Rack::VCR リクエストの記録 リクエストのモック リクエストの再生 おまけ: Androidアプリのテスト 弊社での利用例 未来 こんにちは、会員事業部の小室 (id:hogelog) です。気づけば弊社に入社してから2年と2ヶ月が経っていました。 今回はその2年2ヶ月で初めて会社プロダクトを rails new したRailsアプリケーションと、そのアプリケーションで利用したRack::VCR (https://github.com/miyagawa/rack-vcr) について簡単に解説します。 新規アプリケーションの構成 今回私が新規に作成したRailsアプリケーションは仮にここではomoikane(仮)と呼ぶことにします。omoikaneはリクエストがあると社内の汎用APIサーバにアクセスし、APIサーバから取得した情報を元にレスポンスを返すアプ
What turns URL params like http://site.com/people?name=bobo into { :name => "bobo" } in Ruby? And what turns extra-weird Rails or Sinatra params like /path?people[][name]=bobo&people[][first_love]=cheese into hashes and arrays? What the Hell is That? Googling “rails query param names with square brackets” doesn’t help much. And Rails doesn’t make it easy to find docs for this. So what’s going on w
Rackについて調べても、「ではまず簡単なRackアプリケーションを作ってみましょう。config.ruを開いて……」みたいな資料しか出てこなくて、サーバー側からみたRackインターフェースがどうなってるかという記事が全然見当たらなかった。んだけど、何やら外国の人のブログでちょうど望んでる内容のものがあったのでざっくり翻訳と紹介します(許可とった)。言い回しとかで解釈わかんないところがあって飛ばしたりしているので本文とニュアンスだいぶ変わってしまっているかもなのですが、まあ最低限の内容が伝われば……ご了承ください。 元記事:http://www.blrice.net/blog/2015/05/31/make-your-own-rack-server/ 自分のRackサーバーを作ってみよう Ruby触ってたら必然Rackについて学ぶよね。RailsとかSinatraとかRubyのWAFの心臓
概要 webアプリでとあるパスへのリクエストをフックしてゴニョゴニョする。 そんな方法ないかなぁと思っていたらタイムリーな記事を見つけた。 開発環境でのみ、リクエスト毎になんか処理をフックしたい in Ruby しかしrack middlewareってどんなもの?状態なので勉強からスタート。 rack middlewareの簡単なお勉強 Rackミドルウェアの作り方を勉強した ここみたら何となく分かった。 簡単なmiddlewareを書いてみる /hogeにアクセスが来たら、"hogehoge"を返すmiddleware。 元のアプリに/hogeの処理が定義してあっても、その処理を通さずにクライアントへ結果を返す。 そんなmiddlewareを書いてみた。 class MyRackMiddelware def initialize(app) @app = app end def call(
先月、heroku の推しサーバが unicorn から puma に変わったという発表がありました。unicorn だとスロークライアントの影響を受けやすいというのが理由なようです。 もう少し詳しく調べてみましょう。 そもそもスロークライアントってなに その名の通り遅い回線のクライアントです。3G環境のモバイル端末などが該当します。 「unicorn だとスロークライアントの影響を受けやすい」とは unicorn はプロセスモデルのサーバであり、blocking I/O モデルを採用しています。つまり、クライアントとの通信中プロセスが専有されるということです。 例えば unicorn がワーカプロセスを3つ立ち上げていて、そこへ通信完了に10分かかるようなスロークライアントが3つ接続されたら…、続くクライアントはスロークライアントの通信が完了するまで実行を待たなければならなくなります。プ
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く