ググってみると、投稿があったページのキャッシュデータを削除する機能があるということで、上記の問題解決にぴったりです。 インストール Nginx Cache ControllerプラグインはWordPressの管理画面からインストールすることができます。 プラグイン→新規追加で表示された画面で「Nginx Cache Controller」を入力すると出てきますので、インストールします。私のインストールしたときはバージョン1.5.0になっていて、対応するWordPressは3.4以上となっていました。 インストールに成功したらプラグインを有効化します。 nginxの設定の変更 調べてみると、Nginx Cache Controllerプラグインを使うためには、nginxの設定で「X-ACCEL-EXPIRES」を付け加えなければいけないようです。 Nginx Cache Controller
【nginx】WordPress でキャッシュしてはいけないページ（ファイル、ディレクトリ）設定！！！ ポイント WordPress 関係のクッキーを使用している場合はキャッシュしない WordPress プラグイン Nginx Cache Controller に必要な設定を維持する必要がある。今回の場合は、proxy_cache_key 「POST はキャッシュしない」と「GET 以外はキャッシュしない」は異なる。GET をキャッシュするよう明確にしたいので「GET 以外はキャッシュしない」設定にする。 キャッシュファイルを Linux コマンドから削除する場合は、最新の注意を持って！nginx 以外に、PHP-FPM を再起動したほうがよい WordPress 関係のクッキーを使用しているときはキャッシュしない クッキーを判別することで、ログインしている時やコメントを記入したことある
[追記１] 最後で説明しているproxy cacheの設定を修正しました。 [追記２] nginx proxy cacheでキャッシュしない場合の処理を変更しました。 [追記３] スマートフォンや携帯で閲覧した時にキャッシュしない設定を追加しました。 はじめに 大げさな題名ですが、今回はWordPress単体を速くするのではなく、データベースやWebサーバなどの調整、またnginxのproxy cache機能を使って速くする話になります。 サイトの構成によっては、proxy cacheは使えないかもしれませんが、使わなくても5倍程度速くすることはできましたので、参考にしていただければと思います。 今回行うチューニング一覧 DBを最適化するプラグインを導入する APCを導入してPHPを速くする MySQLを速くする 重いWordPressプラグインを外す nginx+FastCGIにする W
Nginxを使ったWordPressのチューニングといえば、フロントエンドのNginxとバックエンドのNginx（もしくはApache）に分けてproxy cacheを効かせるのが王道です。 さらにWP Super Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。 今回はそこからもう一歩進めたチューニングについて書きたいと思います。 二段階層を廃したシンプルな構成 まずは、図をご覧ください。 前述の王道チューニングの構成はA図となります。 proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。 A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表していま
nginxをリバースプロキシサーバーとして使いました。 明示的に設定しない限り、HTTP Hostヘッダは、nginxが受けたリクエストのホスト名ではなく、プロキシ先として設定したホスト名になってしまう。 下記の例だと、プロキシ先に送られるHostヘッダは'127.0.0.1'になる。 location / { proxy_pass http://127.0.0.1:3000; } こういう環境下でプロキシ先のアプリケーションででHostヘッダを使うと、元々のリクエストのホスト名と一致しないので、妙なことが起こってしまう。 しかも、だいたい開発環境ではリバースプロキシを通していないので、リクエストしたURLのホスト名とHTTPヘッダが一致しない何てことは発生せず、問題の発覚は本番デプロイ時、ということになってしまう。 ドキュメントを見ると、"Note that the HTTP Host
nginx & unicorn で設定してるときに気になった箇所のメモ書き proxy_redirect レスポンスヘッダのうち Location Refresh の書き換え。 Location ヘッダ 201 のとき、新しく作られたリソース(URL)を返す 3xx のとき、リダイレクト先のURLを返す ためのヘッダ 設定例 もし下記のように nginx を設定していて proxy_redirect http://localhost:8000/two/ http://frontend/one/; Location: http://localhost:8000/two/some/uri/. というレスポンスヘッダが返ってきたら、nginx はそれを Location: http://frontend/one/some/uri/. に書き換える。デフォルトは proxy_pass にならう。下
locationディレクティブはパスの条件が評価されて選ばれたものが適応されます。この条件はパスの文字列の前方一致あるいは正規表現による評価です。この評価の順番は以下のようになります。 前方一致（"=", "^~", プレフィックスなし）の条件の評価を実施 最も一致する条件を選ぶ。 選ばれた条件が、完全一致で、プレフィックスが"="であれば、そこで評価を終了し、そのlocationディレクティブを適応する。 選ばれた条件のプレフィックスが"^~"であれば、そこで評価を終了して、そのlocationディレクティブを適応する。 正規表現（"~", "~*"）の条件の評価を実施 正規表現の条件を設定ファイルに定義した順番に評価する。一致したら、そこで評価を終了して、そのlocationディレクティブを適応する。 前方一致の評価で選ばれた条件のlocationディレクティブを適応する。 ここで注意
概要 nginx のログを fluend で収集し、 elasticsearch にデータを格納。 kibana で可視化を行います。 目的 アクセス、ユーザーの属性等のログを可視化し、 サービス改善の新たな企画、施策に繋げる。 各種ツール説明 nginx -> websever apache的な kibana -> データ可視化ツール。グラフ化 elasticsearch -> 全文検索エンジン。Apache Luceneを元に作成されている。同じく Lucene が元になっているものとして solr がある。 fluentd -> ログ収集ツール。様々な input 元、 output 先を設定できる plugin が豊富。Rubyで記述されており、plugin の作成も容易 全体の流れ nginx -> fluentd -> elasticsearch -> kibana 今回は、す
ま、こういう話になりますよね 正直、こういう仕事が一番嫌ですね 何があるかわからないからねぇ nginx のアクセスログを Json に変更して、 一括で elasticsearch にバルクインサートする 結果、25万件のアクセスログを 3分で Json に変更して、 10分でバルクインサートできた トータルで 15分ぐらいかかる Json のバルクインサートについて http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-bulk.html パラメーターについて http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-http.html 以下、やったこと
embulk使ってみる fluentd + elasticsearch + kibanaをやってみたいなと思い既存のログからデータ突っ込めないかなと思い探してみたらちょうどよさそうだったので試してみました。 fluentdのバッチ版と言われているようです 手順もほとんど下記見ながらやればできます embulk インストール curl -o ~/bin/embulk -L "http://dl.embulk.org/embulk-latest.jar" chmod +x ~/bin/embulk サンプルデータを入れる ひな型生成 example サブコマンドでサンプルデータができます # サンプルのひな型生成 bin/embulk example ./sample # sample/example.ymlの中身を読み込んで自動的に設定ファイルを作成してくれる bin/embulk gues
F5 Sites DevCentral Connect & learn in our hosted community F5 Labs The latest threat intel and research to help protect your apps MyF5 Your key to everything F5, including support, registration keys, and subscriptions Partner Central Research and support for partners LearnF5 Guidance, insights, and how to use F5 products Contact F5 Contact F5 Sales Talk to an F5 sales representative Contact F5 Su
ここから少し、楽天モバイルの宣伝になります。 このサイトでアフィリエートや広告を貼るつもりは全然無かったのですが、 6月中に楽天モバイルの契約30件を取るか、船を降りるかするように言われています。 回線の増設を考えている方、お子様に新しく携帯を持たせようと考えている方、 下記リンク先で楽天にログイン後、楽天モバイルの各プランをご検討いただけないでしょうか。 楽天モバイル 紹介リンク この章では、プロキシされたサーバから受け取った応答のキャッシングを有効にする方法と設定方法を説明します。キャッシングが有効になると、NGINXはディスク上のキャッシュの中に応答を保存し、リクエストをプロキシせずにそれらを使ってクライアントに応答します。 応答のキャッシュを有効にする proxy_cache_path ディレクティブを使って、キャッシュのパスと他のパラメータをキャッシュするように設定することができ
はじめに 僕は盲目的にunicornを起動するためだけにnginxを使っていて、設定ファイルの内容とかをほとんど知らない。 なので、ここにnginxの設定内容をまとめる事で自分自身が覚えようと思う。 普段使う大抵の設定は記載しているつもりです。 記載内容は実際に試したものと試してないものが混在してるので、誤った設定などがあるかもしれないのでその辺はコメントでご指摘いただけると助かります。 インストール インストールについては僕が書くより他の人の記事を見た方がいいと思う。 centosに入れるなら以下の記事が参考になる。 CentOS6.xにてnginxの最新版をインストールする手順 CentOS 6.5でnginxを動かす為の最低限の設定 またchefでインストールする場合は以下の記事が役にたつ。 Chefでnginxを導入してみる ChefでNginxをインストールするときにハマった c
前回と同様に、nginx.orgのパッケージからインストールしたnginxが提供している設定ファイルをサンプルとして説明を行います。 今回はnginxのバーチャルサーバの設定を確認していきます。なお、「バーチャルサーバ」はApache HTTP Serverで言うところ「バーチャルホスト」のことです。 バーチャルサーバ毎の設定ファイル nginxの設定ファイルnginx.confに次のような記述を行うことにより、/etc/nginx/conf.dディレクトリにある拡張子がconfであるファイルを読み込みます。 include /etc/nginx/conf.d/*.conf; このconf.dディレクトリにバーチャルサーバ毎の設定ファイルを置くことにより、その設定ファイルが読み込まれます。nginx.orgのパッケージで提供されているサンプルファイルとしては、default.confとex
概要 fluentdでログ転送＆収集を行い、 Elasticsearchでデータを保存し、 kibanaでデータの可視化を行う。 サーバー構成 APIサーバー（複数台） 【nginx】→【fluentd】→ログ収集サーバーへ転送 ログ集約サーバー（兼 解析サーバー） APIサーバーから転送→【fluentd】→【Elasticsearch】⇔【kibana】 サーバー設定 APIサーバー nginx nginxはインストール済みとする。 nginxのアクセスログをltsvフォーマットにする log_format ltsv 'time:$time_iso8601\t' 'remote_addr:$remote_addr\t' 'request:$request\t' 'request_method:$request_method\t' 'request_length:$request_len
こんにちは。 インフラチームの野島（@nojima）です。 チームのメンバーに nginx の設定について気をつけるべき点を共有するために、レビュー観点を書きました。 せっかくなのでここで公開します。 ほとんどの項目は自分やチームのメンバーの実体験に基いています。 レビュー観点 server server_name が他のやつと被っていないか。 listen する IP アドレスが同じ場合、server_name で区別できないといけない。 TLS を使う場合、SNI をサポートしないクライアントでは TLS 用の設定が default_server のものが使われる点にも注意。 TLS を使う場合、listen ディレクティブに ssl オプションを書いているか。 location location のマッチの順番に注意 正規表現の location は前方一致の location より
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く