ブログエンジン(3) キャッシュ機構とproxy_cache_revalidate - afnf.net
nginx2段化 nginxによるキャッシュを有効にすると、CPU時間のほとんどがnginxのusr時間で占められるようになります。 帯域幅がボトルネックにならないよう、gzip圧縮を有効にしているためです。特に工夫しないとリクエストのたびにgzipが行われてしまいますが、これは無駄です。gzip圧縮済のコンテンツをキャッシュするよう、nginxのリバースプロキシを2段構えにしました。 # for cache server { listen 80; server_name blog.afnf.net; gzip_types text/css application/javascript; gzip_proxied any; gunzip on; location / { include proxy.conf; proxy_set_header Accept-Encoding gzip; p
Docker + Nginx + Let's Encrypt を使ったシングルホストでの複数ウェブサイトお手軽運用法
自宅サーバーにて複数のウェブサイトを設置しているのですが、ある程度知見が溜まったのでここに置いておきます。 前提 シングルホストで複数のウェブサイトを Docker でお手軽に運用したい ダウンタイムゼロのホットデプロイとかオートスケーリングとか冗長化構成とかは考えない − できるだけブラックボックスのないシンプルな構成にしたい お手軽にそれぞれのウェブサイトにバーチャルホストを割り当てしたい お手軽に Let's Encrypt も使いたい（証明書の自動取得・自動更新） Tutum 改め Docker Cloud を使うのもいいですが、お金がかかりますし、何より中身がブラックボックスなので私は見送りました。自分が完全にコントロールできないレイヤをインフラに導入するのは極力避けたいといった方針です。 Docker Cloud とほぼ同じ様なことを実現できる OSS ソフトウェアとして Ra
サーバサイドWebアプリケーションエンジニアにとって必携の一冊。「nginx実践入門」が発売されます | メルカリエンジニアリング
SRE(Site Reliability Engineering)チームの@kazeburoです。 1/16(土)にSREチームの久保(@cubicdaiya)が執筆に参加した「nginx実践入門」が技術評論社から発売されるので、紹介します。 gihyo.jp 電子版も同時に発売されます。こちらもどうぞ gihyo.jp メルカリとnginx このブログでもnginxの利用方法を何度も紹介していますが、メルカリではTLSのターミネーション、リバースプロキシや内部で使用する各種ミドルウェアのロードバランサーなどとしてnginxを利用しています。さらに、軽量スクリプト言語であるluaでnginxを拡張するngx_luaを活用してログ解析基盤を構築したり、ロードバランサーの動作をカスタマイズして一部ミドルウェアのレスポンス速度の向上を実現しています。nginxがメルカリのスケーラビリティを支えて
ハイパフォーマンスngx_lua | メルカリエンジニアリング
Site Reliability Engineering（SRE） Teamの@cubicdaiyaです。 今回は数あるnginxのサードパーティモジュールの中でも一際強力で、メルカリでも活用しているngx_luaの便利な活用方法や最適化集について紹介します。 ngx_luaは軽量スクリプト言語のLuaでnginxを拡張できるモジュールです。 nginxの設定ファイル内にLuaのコードを埋め込んだり、nginxの拡張モジュールをCではなくLuaで開発することができます。以下はngx_luaにおける「Hello, World!」です。 location / { content_by_lua 'ngx.say("Hello, World!")'; } 上記のロケーションにHTTPでアクセスするとnginxはボディが「Hello, World!」のレスポンスを返します。 なお、先月末にリリースさ
Nginxを使ったもう一歩進んだWordPressチューニング
Nginxを使ったWordPressのチューニングといえば、フロントエンドのNginxとバックエンドのNginx（もしくはApache）に分けてproxy cacheを効かせるのが王道です。 さらにWP Super Cacheプラグインを利用してなるべくPHPやMySQLにアクセスさせないようにすると、手軽で絶大なパフォーマンスアップが可能です。 今回はそこからもう一歩進めたチューニングについて書きたいと思います。 二段階層を廃したシンプルな構成 まずは、図をご覧ください。 前述の王道チューニングの構成はA図となります。 proxy cacheはNginxがバックエンドのサーバーに処理を回し、返ってきたレスポンスをキャッシュして、Nginx自身がキャッシュを返すことでパフォーマンスを上げる仕組みです。 A図-1がキャッシュの無いアクセス、A図-2がキャッシュが効いているアクセスを表していま
Consulを利用したTLSセッションチケットの自動更新 | メルカリエンジニアリング
Site Reliability Engineering Team（通称SRE）の@cubicdaiyaです。最近チーム名が変わりました。 今回はConsulを利用して複数台のnginxサーバのTLSセッションチケットを自動更新する仕組みについて紹介します。 TLSセッションチケットは簡単に言うとTLSのセッション情報を暗号化してクライアント側に保存することで HTTPS通信時に行われるTLSハンドシェイクの手順を省略してネットワークレイテンシを削減するための仕組みです。(詳細については一番下の参考情報を御覧ください) 似たような仕組みとしてTLSセッションキャッシュがありますが、こちらはセッション情報をサーバ側に保存します。 HTTPS通信ではTCPのハンドシェイクに加えてTLSのハンドシェイクが必要になるのでHTTP通信よりもネットワークのレイテンシが大きくなりますが、 これらの仕組み
OpenRestyはどれくらいお気軽なウェブアプリ環境なのか。 - Qiita
まとめの後に追記を追加。 OpenResty は Nginx をダイナミック・リバースプロキシーサーバに仕立て上げたり、テンプレートエンジンを仕込んでバックエンドの JSON API サーバにリクエストしたレスポンスデータを元にレンダリングして返したり、と色々便利に使えるお気楽ウェブアプリ環境なのだけれど、画像処理系のCPUに負荷のかかりそうなものでもお気軽にいけるのかなとふと疑問に思ったの実験してみる。 OpenResty や LuaRocks のインストールは homebrew でさっくり入るし、windows はパソコン初心者並の知識しかないのではしょる事にして、とりあえずテーマを決める。 「nginx 画像処理」でググってみると「簡単！リアルタイム画像変換をNginxだけで行う方法 | cloudrop」ってのが一番上にあったり「S3をバックエンドにngx_small_lightで
nginx-proxyによるマルチドメイン環境 | sigelindeの物置
nginx-proxyというdocker imageを使うことで，複数のコンテナによるWebサーバーを構築してみます．nginx-proxyというdocker imageを使うことで，複数のコンテナによるWebサーバーを構築してみます．これによって，サーバコンテナが複数ある場合に，ドメイン名によってアクセスを振り分けることが出来ます． このnginx-proxyのすばらしいところは，サーバコンテナの稼働状態に応じて自動で設定が変更されるところです．例えば，サーバコンテナ3をあとから追加したくなった場合，設定を行ったサーバコンテナ3が起動した時点で自動的にnginx-proxyの設定が変更されます．つまり，nginx-proxyコンテナを手動で設定する必要がなく，変更するサーバコンテナのことだけ考えていればいいのです．非常に便利ですね． 構築手順 docker環境が導入されていることを前提と
Nginx+Luaで実装したリバースプロキシをDockerとGoで自動テストした - Qiita
Nginxでリバースプロキシしつつlua-nginx-moduleを使ってリクエストやレスポンスを書き換える。図にするとこんな感じ。 client proxy app | 🍣 | 🐟 | |-------> 🐟 -------> 🐟 | 🍣 🍚 🐟 | |<--------|<----------| クライアントから寿司が送られてくるけどアプリケーションはネタだけ受け取りたいのでシャリはプロキシに抜いてもらう。 アプリケーションからのレスポンスにはさっきのネタが含まれているので、プロキシはシャリを戻してクライアントに返してあげる。 ローカルにOpenResty入れて適宜luaファイルを書き換えてcurlを叩くとかでもいいんだけど、絶対あとからだるくなってくるのでDockerでコンテナを立ち上げて、それに対してリクエスト投げるテストを書くことにした。 Dockerファイルはこち
Introducing Dockercast – the Docker Podcast | Docker Blog
Learn how to use OpenPubkey to bind public keys to workload identities using GitHub Actions and Docker. And find out how Docker is using OpenPubkey with GitHub Actions to sign Docker Official Images and improve supply chain security. Learn four best practices that your teams can implement to maintain a secure and reliable software delivery process with Docker Hub in Google Cloud. With these guidel
apacheとnginx – 忘れるために記す
主に、オープンソースカンファレンス2014 Tokyo/Spring Apacheコミッターが見た Apache vs nginx http://openstandia.jp/pdf/140228_osc_seminar_ssof8.pdf より webサーバ仕組み – ざっくりリクエストに対して、レスポンスを返却する apache – マルチプロセス、マルチスレッドアーキテクチャ-マルチプロセス、スレッドの場合、1つのプロセスまたはスレッドがこれを処理する。そのため、1アクセスを処理している間は他のアクセスを処理できず、同時接続数分だけプロセスまたはスレッドが必要となる マルチプロセス、マルチスレッドの違いマルチプロセスはメモリ空間を個別に持つが、マルチスレッドはメモリ空間を共有する メモリの使用効率が高く、プロセス切り替え時にメモリ空間の切り替えが発生しないためコストが低くなる マルチ
nginx の拡張モジュールを書いて DoS 対策をした - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。インフラチームの野島です。 最近、cybozu.com はロードバランサを Apache から nginx に置き換えました。 (参考: cybozu.com のリバースプロキシを nginx にリプレイス) 置き換えの一環として、Apache に実装していた DoS 対策の仕組みを nginx の拡張モジュールにする形で移植しました。今回、この拡張モジュール nginx-maxconn-module を OSS として公開しましたので紹介します。 背景 DoS 対策 秒間リクエスト数 v.s. 瞬間同時リクエスト数 実装方針 nginx-maxconn-module 基本的な使い方 高度な使い方 インストール おわりに 背景 本題に入る前に、cybozu.com において、HTTP リクエストがどのように処理されているかを説明します。 cybozu.com では、負荷分散のた
NginxとLuaを用いた動的なリバースプロキシでデプロイを 100 倍速くした
Kubernetesでの性能解析 ～なんとなく遅いからの脱却～（Kubernetes Meetup Tokyo #33 発表資料）NTT DATA Technology & Innovation
Nginx Optimization: understanding sendfile, tcp_nodelay and tcp_nopush
This article a is translation by popular request of Optimisations Nginx, bien comprendre sendfile, tcpnodelay et tcpnopush I wrote in French in January. Most articles dealing with optimizing Nginx performances recommend to use sendfile, tcp_nodelay and tcp_nopush options in the nginx.conf configuration file. Unfortunately, almost none of them tell neither how they impact the Web server nor how the
ngx_mrubyでつくる簡単な動的サムネイル生成サーバー - スペクトラム
動的サムネイル生成 サムネイルは、ユーザアップロード画像を扱うアプリではほぼ間違いなく使われると思う。 サムネイルの生成には、先に作っとくか、後で作るかの2つの方式があるように思う。(気が向いた時とかナシとすると) 先に作っとく サムネイルを先に作る。 つまりは画像アップロードをキータイミングとして画像処理をかけ、 参照するときには静的な画像を見る方法。 メリットは参照に処理を挟まないので高速に動作することが期待できること。 しかしデメリットとして後から画像サイズを変更しようとすると、画像処理が全部やり直しになる。 また、近年ではCDNを使えば静的画像の参照が早かろうがあまり効果が無いことが多い。 後で作る そこで参照側からパラメーターを与えて、リクエストが来た時に画像処理をかける方法をみてみる。 一見参照するたびに画像生成するのは効率が悪すぎる印象があるけど、 その分ちょくちょくサムネイ
簡単！リアルタイム画像変換をNginxだけで行う方法
先週金曜日（12/2）にクックパッドインフラ勉強会に参加しまして、そこで同社の成田さんから「今日からできるApacheモジュール開発と運用」という発表がありました。 リアルタイム画像変換モジュールの「TOFU」を開発するに至った経緯と、Apacheモジュール開発についてのお話でした。 TOFUは、S3に置かれたマスターとなる画像ファイルを取得し、与えられたパラメータでリアルタイム（オンザフライ）にリサイズ・トリミングを行うモジュール（mod_tofu）です。 料理を楽しくする画像配信システム 実際は、モジュールによる画像取得・変換をベースに、キャッシュや配信までも含めた一連の画像配信システムと言えそうです。 この仕組みをNginxを使って実装できないかと考えて、リアルタイム変換の仕組みをNginxだけで実現する方法を実験してみました。 準備するもの HttpImageFilterModul
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - matsuu/kataribe: Access log profiler based on response time
nginxのパフォーマンスチューニング
画像変換Night - 資料一覧 - connpass
実践ngx_small_light入門
