タグ

apacheとnginxに関するuokadaのブックマーク (5)

  • RubyKaigi2014でmod_mrubyやngx_mrubyとその応用について発表して、就職も決まりました - 人間とウェブの未来

    RubyKaigi 2014でmod_mrubyやngx_mrubyとその応用について話してきました。 この写真はhsbtさんに撮っていただいた写真で、その他RubyKaigi中のグレートな写真を沢山撮影されていました。 hsbtさんに感謝します。 RubyKaigi 2014, 18-20 september RubyKaigiは、オブジェクト指向スクリプト言語Rubyの準国際カンファレンスです。 世界中からRubyのコミッターや技術者がRuby発祥の地である日にて一堂に会するイベントです。 2006年からほぼ毎年開催されており、前回のRubyKaigi 2013では公用語に英語を追加するなど、国際カンファレンスとしての場を整え、3日間でのべ1,500名以上の来場者を迎えました。 発表で使用したスライドは以下です。 スライドよく見ると、時間の関係上省いた最後の

    RubyKaigi2014でmod_mrubyやngx_mrubyとその応用について発表して、就職も決まりました - 人間とウェブの未来
  • 人間とウェブの未来 - mod_mrubyとngx_mrubyのv1.0.0をリリースしました+振り返りまとめ

    人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 先ほど、mod_mrubyとngx_mrubyのそれぞれv1.0.0をリリースしました。 2012年の4月のmrubyのソースコード公開を機に開発をはじめ、今振り返ると色々な事がありながらも2年間続けて研究・開発を行い、ようやくここまで辿り着く事ができました。 mod_mrubyとngx_mrubyを実装していく中で、Matzさんをはじめmrubyに関わるすごいプログラマの皆さんと出会い、多くの事を教えていただきながらここまでやってくることができました。もし、彼らと出会うことがなければここまで続ける事はできなかっただろうと思います。 mrubyに関わりながら研究・開発し、その成果物をOSSとして公開しながらやってきたことで、恐縮ながらも産学両

    人間とウェブの未来 - mod_mrubyとngx_mrubyのv1.0.0をリリースしました+振り返りまとめ
  • 僕が考えた最強のサーバ設定 - とあるプログラマの日記 @s025236

    いつの間にかさくらのVPSの標準OSがCentOS6になってたので設定を見直してみました。 月額980円/月から利用でき、2週間のお試し期間もあるのでこれを機会にサーバ設定に足を踏み入れてみてはどうでしょう? 慣れると10分くらいでウェブサーバが立ち上げれるようになります。 すみません。こんなに多くの人が見てると思わなかったんです。 お一人様サーバ向けのつもりで書いてます。 タイトルもタグもネタだったのにツッコまれまくりで恥ずかしい… 公開鍵登録しよう どうせ自分しか触らないなしrootで作業しちゃってもいいんじゃない? リブート(またはsshのrestart)以降秘密鍵がないとsshでログイン出来なくなるので気をつけてください。 mkdir ~/.ssh/ touch ~/.ssh/authorized_keys chmod 700 ~/.ssh/ chmod 600 ~/.ssh/au

  • Apacheをnginxにリプレイスした

    yubitterという携帯向けTwitterクライアントサービスで、ユーザーのアイコンを携帯電話向けに変換している(※1)、いわゆる画像変換サーバーのhttpd部分をApacheからnginxへ変更しました。 処理は単純に以下の流れです。 クライアントからアイコン画像のリクエストが来る 既にハードディスクにキャッシュファイルがある場合は、それをそのまま返す ファイルがない場合は、PHPプログラムがアイコン画像がアップロードされているTwitterのサーバー(現在はAmazon S3/CloudFront)へ取りに行く PHPプログラムが取得した画像データをGDライブラリを利用して加工、ハードディスクに保存、レスポンスを返す 変換するにあたり、以下の2パターンを検討しました。 リプレイス案1は、Apacheのレイヤーを一つ下げてAPサーバーに専念してもらう案で、2案は、Apache+mod_

    Apacheをnginxにリプレイスした
  • 3000req / sec と戦う - だるろぐ

    ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ

    3000req / sec と戦う - だるろぐ
    uokada
    uokada 2011/09/24
    これは単純にスゴイ。アタリマエのチューニングを繰り返せばスゴイことが出来ることの証明。
  • 1