F5 NGINX: Built for cloud-native apps. Ready for AI traffic.Deliver, secure, and scale apps, APIs, Kubernetes services, and AI workloads through a lightweight, high-performance solution designed for distributed, hybrid multi-cloud environments.
前回のリプレイスでどのくらい変化があるかを調べてみました。構成などはそちらをご覧ください。 対象サーバーをDNSから外してアクセスを止め、リプレイス作業後、DNSに再登録しました。 そのビフォアとアフターのグラフです。 Apacheのアクセス数 横軸のひと目盛は6時間なので、4日午前0時にアクセスが止まって、5日の午前2時にアクセスがもどっていることがわかると思います。（3日のアクセス数が少ないのはラウンドロビン環境下のサーバーを2台から3台に増やしたからです。5日には再び2台に戻しています。） nginxのリクエスト数（アクセス数） nginxも5日の午前2時頃からアクセスされ始めました。ビフォア（Apache）もアフター（nginx）もちょうどピーク時に160リクエスト程度を受けているので、アクセス数は同じくらいと考えられます。 トラフィック ビフォアとアフターでピーク時に2Mbits
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
nginx+memcachedがめちゃ気になったので試してみました。 元ネタは下記です。 A 53,900% speedup: Nginx, Drupal, and Memcache bring concurrency up and page load time way down | TechnoSophos nginxをリバースプロキシに利用した構成で、バックエンドの出力をmemcachedにキャッシュしておけば、次回リクエストではnginxがそのキャッシュを読み取ってそのまま出力してくれます。 つまりバックエンドにリクエストを経由させずにnginxから即出力するのでかなりの高速化が見込めるという優れものです。 リンク先ではバックエンドにDrupalを利用していたのですが、ここではCakePHPを利用してみます。 1. 全体構成 リバースプロキシにnginx(Port: 80)を使い、バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
