GitHub - devlucky/Kakapo: 🐤Dynamically Mock server behaviors and responses in SwiftYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ngrokみたいなHTTPプロキシを書いてみた
開発中のWebアプリをみんなに試してほしいけど、 サーバなんてなくて開発環境がローカルにしか無くて公開できないということは、 開発初期段階だとよくあることだと思います。 もちろん本格的にやるならテスト用にサーバを建てるべきですが、 小さなものならngrokを使うと簡単です。 ngrokの公開サーバへのHTTPリクエストをローカルにリレーして、 ローカルのサーバをお手がるに公開できるサービスです。 びっくりするほど簡単に公開できて便利ですが、 一応oAuthで制限とかかけたいなーとかカスタマイズしてみたくなってきたので、 似たようなものを自作できないかといろいろ遊んでみました。 その結果、HTTP2 over Websocketみたいな謎なものが出来上がってしまったというお話です。 HTTP2 over Websocketというアイデア ngrokっぽいものを実現するためには、 サーバが受け
書籍「Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門」発売されます - K.Maebashi's はてなブログ
以前よりWebで公開していた「本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう」が、技術評論社さんから本として発売されます(発売日は6/7です)。 技術評論社さんの紹介ページはこちら。 Webサーバを作りながら学ぶ 基礎からのWebアプリケーション開発入門：書籍案内｜技術評論社 私のWebサイトにおける紹介ページはこちら。 http://kmaebashi.com/webserver/index.html amazonはこちらから。 この本は、タイトルにあるとおり、「基礎からのWebアプリケーション開発入門」です。 その前にある「Webサーバを作りながら学ぶ」のあたりでちょっと待てと思う人がいるかもしれませんが*1、私は、冗談でもなんでもなく、本気で「基礎からのWebアプリケーション開発入門」のつもりで書いています。ただし、プログラミングそのものの初心者は対象ではな
2015年Webサーバアーキテクチャ序論 - ゆううきブログ
2023年03月31日追記：この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
本当の基礎からのWebアプリケーション入門――Webサーバを作ってみよう
このページの目的は、 Webアプリケーションの基礎の基礎を説明することです。 さて、ここから下のぐだぐだは読み飛ばして、 いきなり実装の説明に 行ってもらってもかまいませんが、一応趣旨を書いておきます。 現在、プロのプログラマーの方々には、日々の仕事でせっせと 「Webアプリケーション」を作っている人が多いと思います。 そして、いまどきWebアプリケーションを作るのに、 CGIとかあり得ないでしょうから、 それなりの高級言語で、 それなりのフレームワーク等を使用して作っているのだと思います。 私自身、現状、仕事では主にC#とASP.NETを使っています。 そうやって生産性を上げるのは大変よいことだと思うのですが、 ことWebアプリケーションにおいては、 そのような「一見簡単そう」なフレームワークを使っても、 ちょっとややこしいことをやろうとするとすぐにうまくいかなくなって、 職場の先輩に聞
)
Unix Domain Socket において keep-alive が性能に与える影響 (Gazelle vs Meinheld) - methaneのブログ
id:kazeburo さんが Gazelle という高速な Perl 用の Web アプリケーションサーバーを公開されました。 Gazelle - Plack Handler for performance freaks #yokohamapm from Masahiro Nagano Gazelle の特徴のうち幾つかは、 id:mopemope 作の Meinheld と同じです。 IO周りは全てCで書かれている accept4 や writev などの Linux 独自のシステムコールを利用している 一方で異なる点もあります。 Meinheld は HTTP/1.1 に対応していて、 keep-alive が利用できる。 Meinheld は greenlet というコルーチンを利用して、 long polling や SSE に対応している。 Meinheld が http-pa
Unicornの2倍のパフォーマンスを実現したRackサーバ「Rhebok」をリリースしました - blog.nomadscafe.jp
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
「RaptorはどのようにしてUnicornの4倍、Puma, Torqueboxの2倍の速度を達成したのか」を読んでまとめてみた - Qiita
Help us understand the problem. What is going on with this article? 「RaptorはどのようにしてUnicornの4倍、Puma, Torqueboxの2倍の速度を達成したのか」を読んでまとめてみました。 原文はこちらです。紹介については許可を貰っています。 How we've made Raptor up to 4x faster than Unicorn, up to 2x faster than Puma, Torquebox とても読みやすい英語ですので是非原文も読んでみてください。 How Ruby app servers work Rackアプリケーションの構成についての紹介と、コネクションをどのように扱うのかについて。 prefork/threadingやBlocking I/OおよびEvent I/Oの組み
WildFly の Web 基盤、Undertow の紹介
この記事は JavaEE Advent Calendar 2013 の 12/9 の記事です。 昨日は @n_agetsu さんの CDIでアプリケーション設定をインジェクション でした。 明日は @sk44_ さんの JSF で日本語ファイル名のファイルダウンロード？ です。 このエントリでは、WildFly の Web コンテナである、Undertow のご紹介をしたいと思います。 WildFly って何？ WildFly は、OSS の Java EE アプリケーションサーバです。2013-12-09 時点でのリリースバージョンは 8.0.0.Beta1 であり、Java EE 7 の仕様がひと通り実装されています。 公式サイト http://wildfly.org/ 以前は JBoss Application Server(JBoss AS) と呼ばれていたものですが、商用サポート
Go で書いたサーバーを管理するには circus が便利 - methaneのブログ
Go を使うとサーバーとアプリケーションの境界が無くなり、アプリケーションサーバーを書けるようになります。 それは良いことなのですが、アプリケーションを書く人が、従来サーバーを書く人が設計していた機能を理解して実現できないと、運用できないサーバーができあがる結果になってしまいます。 例えば Apache は、 master, worker プロセスが分離していて、設定変更を反映させるときなどは新しい worker を作ってから古い worker を殺すことで、サービスを一瞬も止めずに worker を再起動していました。これを graceful restart と呼びます。 Go で 1024 以下のポートを Listen するアプリを作る で触れたとおり、 Go はプロセス管理システムを作るのには少し向いていない面がありますし、せっかくアプリケーションプログラマーが簡単にサーバーを書ける
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
YappoLogs: 馬鹿でもわかる Application Server と Reverse Proxy Balancer のお付き合いを考える
馬鹿でもわかる Application Server と Reverse Proxy Balancer のお付き合いを考える 一般的な Web Application というのはロードバランサ、Webサーバ、アプリケーションサーバという HTTP を喋るサーバで構成されていると思います。 ロードバランサは高級なハードウェアからソフトウェア(lvs, httpd, etc..)で作るものまで色々ありますね。 アプリケーションサーバでは各種言語に合わせた実装でデーモンが常駐してるでしょう。これはいわゆる普通の Web サーバよりは単純なコンテンツを返す性能が低いです。 そんなわけで動的なアプリケーションサーバが有る構成では js や css や画像など静的なファイルは Apache や nginx などの専用の Web サーバでサービスして、動的なリクエストだけバックエンドのアプリケーションを
Thinは遅い? - lab.ursm.jp
March 02, 2013 「Heroku でアプリケーションサーバを Uniron (or Puma, etc) にしたらn倍速くなったぜ!」みたいな話をたまに見掛けますが、本当なんでしょうか。実験してみましょう。 テスト環境 Funtoo Linux x86-64bit Ruby 2.0.0-p0 Thin 1.5.0 Unicorn 4.6.2 Rainbows! 4.5.0 Puma 1.6.3 アプリケーションは Rack で、50msec の sleep の後に 500KB のレスポンスを返します。各サーバに対して100回のリクエストを、同時接続数を 1-20 の間で変えつつ投げました。詳しくはソースを見てください。 (凡例の c は concurrency、同時接続数です) はい、どう見ても Thin は遅いです。まったくスケールしません。本当にありがとうございました。 こ
The Death of WebSphere and WebLogic App Servers? New Infographic shows the Rise of OSS Java - New Relic Blog
This past September we released one of our Ruby on Rails State of the Stack reports, which presents stats on Ruby usage among our customers. The report shows the most commonly deployed versions of Ruby, the top gems used, the most commonly used app containers, etc. We got to thinking that this might be interesting data to provide for other languages that we support too, such as Java. So…we decided
サーバが重いときの対策メモ - 目の前に僕らの道がある
この話はかなりコンテキスト依存なので、自分メモです。 この辺、体系的に教えてもらったこと無いので、ツッコミどころは満載です。 そのサーバの役割は何か 普通だったらサーバ管理表やサーバ管理アプリに当該サーバの役割とプロジェクトが記載されているはずです。 そもそもpingが通るか pingが通らなければ、どうしようもないです。 サーバが死んだか、gatewayが死んだか、アクセスネットワークが死んだかが考えられます。tracerouteしてみてどこが死んでいるのかしらべてみるといいでしょう。 sshで繋げるか pingが通るけど当該サーバにssh接続できない場合は、単純に重いかOOM Killerが走っている場合があります。 どうしようもなければ、IPMIもしくは管理コンソール経由でサーバを再起動する必要があるでしょう。 ロードアベレージ(LA)は高くないか 何は無くともLAの状態を見ます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - typicode/json-server: Get a full fake REST API with zero coding in less than 30 seconds (seriously)
finatra - nice inspire website
Javaアプリケーションサーバ 構築・運用の勘所
GitHub - frsyuki/serverengine: Moved to https://github.com/fluent/serverengine
GitHub - kazu-yamamoto/mighttpd2: File/CGI web server on Warp
