Nginxを使ったもう一歩進んだWordPressチューニング
Nginxを使ったWordPressのチューニングといえば、フロントエンドのNginxとバックエンドのNginx（もしくはApache）に分けてproxy cacheを効かせるのが王道です。 さらにWP Super Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。 今回はそこからもう一歩進めたチューニングについて書きたいと思います。 二段階層を廃したシンプルな構成 まずは、図をご覧ください。 前述の王道チューニングの構成はA図となります。 proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。 A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表していま
Rackspace Cloud ServersがAmazon EC2よりも優れている点
Cloud Serversは、メモリ256MB/ディスク10GBのインスタンスから用意されていて、 このミニマムのインスタンスが$0.015/時間で借りることができます。1ヶ月利用で$10.8。 256MB以上のインスタンス、例えばメモリ1GB/ディスク40GBのインスタンスでも$0.06/時間。 ディスク容量がネックになる用途以外では魅力的なラインナップではないでしょうか。 特にテスト機や実験機として一時的に利用したいようなケースでは、ロースペック・ローコストはとても助かります。 自動バックアップサービスが無料 バックアップと言ってもデータ自体のバックアップではなく､LVMのスナップショットベースのバックアップになります。 ファイルを個別に取り出すことはできませんが、データを復元する上では全く問題ありません。 このスナップショットがインスタンスごとに3つまでストックできるようになっていて
簡単！リアルタイム画像変換をNginxだけで行う方法
先週金曜日（12/2）にクックパッドインフラ勉強会に参加しまして、そこで同社の成田さんから「今日からできるApacheモジュール開発と運用」という発表がありました。 リアルタイム画像変換モジュールの「TOFU」を開発するに至った経緯と、Apacheモジュール開発についてのお話でした。 TOFUは、S3に置かれたマスターとなる画像ファイルを取得し、与えられたパラメータでリアルタイム（オンザフライ）にリサイズ・トリミングを行うモジュール（mod_tofu）です。 料理を楽しくする画像配信システム 実際は、モジュールによる画像取得・変換をベースに、キャッシュや配信までも含めた一連の画像配信システムと言えそうです。 この仕組みをNginxを使って実装できないかと考えて、リアルタイム変換の仕組みをNginxだけで実現する方法を実験してみました。 準備するもの HttpImageFilterModul
クラウド環境でのApacheの設定
クラウドのホスティングサービスは、一定リソースの時間極課金＋通信トラフィックの従量課金が一般的です。 CPUやメモリなどのリソースは、1%しか使わなくても100％使っても時間内の料金は同じです。 一方で通信料は使った分だけGB単位などで段階的に課金される仕組みです。 この料金体系では、なるべくリソースを使い切って、且つ通信料を抑えることが最も費用対効果のある利用方法となります。 サーバーからクライアントへのレスポンス、特にブラウザーのロードとレンダリングを高速化させるために、Yahoo!のYSlowやGoogleのPage Speedを使ってチューニングを行うのと同じようなアプローチで、なるべくCPUに仕事をさせて、トラフィックを減らしてみたいと思います。 キャッシュ機能を最大限利用する Expires Apacheのmod_expiresを有効にすることで、レスポンスヘッダーにExpir
Apacheをnginxにリプレイスした
yubitterという携帯向けTwitterクライアントサービスで、ユーザーのアイコンを携帯電話向けに変換している(※1)、いわゆる画像変換サーバーのhttpd部分をApacheからnginxへ変更しました。 処理は単純に以下の流れです。 クライアントからアイコン画像のリクエストが来る 既にハードディスクにキャッシュファイルがある場合は、それをそのまま返す ファイルがない場合は、PHPプログラムがアイコン画像がアップロードされているTwitterのサーバー（現在はAmazon S3/CloudFront）へ取りに行く PHPプログラムが取得した画像データをGDライブラリを利用して加工、ハードディスクに保存、レスポンスを返す 変換するにあたり、以下の2パターンを検討しました。 リプレイス案1は、Apacheのレイヤーを一つ下げてAPサーバーに専念してもらう案で、2案は、Apache+mod_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
