タグ

ブックマーク / qiita.com/cubicdaiya (6)

  • コンテンツキャッシュとVaryヘッダとnginx - Qiita

    Varyヘッダは前段のキャッシュサーバに対して、指定したヘッダの内容ごとにキャッシュを分ける必要があることを伝えるためのものです。例えばサーバがVary: Accept-Encodingをレスポンスヘッダに付加しておくと、キャッシュサーバはAccept-Encodingヘッダの内容に応じたキャッシュを保持します。 こうすることでクライアントのAccept-Encodingヘッダの内容に応じたキャッシュデータをキャッシュサーバは返すことができるというわけです。 nginxにおけるgzip圧縮とVaryヘッダ さて、題です。上記のような事情からかApacheのmod_deflateやh2oなんかはコンテンツのgzip圧縮を有効にすると、自動的にVary: Accept-Encodingをレスポンスヘッダに付加します。一方我らがnginxは設定ファイルにgzip_vary on;と書かないとV

    コンテンツキャッシュとVaryヘッダとnginx - Qiita
    progrhyme
    progrhyme 2016/01/08
    大事。
  • ngx_dynamic_upstreamでnginxのアップストリームを動的に変更する - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

    ngx_dynamic_upstreamでnginxのアップストリームを動的に変更する - Qiita
    progrhyme
    progrhyme 2015/05/20
    reload 不要で upstream を動的に追加・削除可能、と。素晴らしい。
  • Slackboard〜Slackプロキシサーバ in Go〜 - Qiita

    昨年末の話だけどSlackへの通知をプロキシするサーバをGoで書きました。如何せん1〜2時間で書いたので一部洗練されてない箇所があるかもしれませんが、 今年のはじめからすでに実運用をはじめています。 Slackboardの役割 SlackboardはSlackへのプロキシサーバであるslackboardとそのためのクライアントであるslackboard-cliの2つから構成されています。↓の図のようにSlackへの通知をクライアントが行うのではなく、クライアントからのリクエストを受け取ったプロキシサーバであるslackboardが行うという仕組みです。 このようにSlackへの通知を直接ではなくプロキシを介して行うのには以下のメリットがあります。 Slackへの通知設定をプロキシサーバで一元管理できる Slackへの通知リクエストをロギングできる 各サーバに散らばったSlackへの通知プロ

    Slackboard〜Slackプロキシサーバ in Go〜 - Qiita
    progrhyme
    progrhyme 2015/05/01
    daioikachan みたいに複数バックエンドには対応してなさそう。/ "golang - Slackboard〜Slackプロキシサーバ in Go〜 - Qiita"
  • nginxのパラメータチューニングとh2o - Qiita

    (追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調

    nginxのパラメータチューニングとh2o - Qiita
    progrhyme
    progrhyme 2015/04/26
    h2oより高速にできた。h2oの今後の機能追加で逆転されるかも。 / nginxのパラメータチューニングとh2o - Qiita /
  • nginxのssl_engineとAES-NI - Qiita

    AES-NIとは IntelやAMD特定のCPU(主にXeon)でサポートされているAESの暗号化/復号を高速に実行するための拡張命令セット。 nginxにはssl_engineというSSLのハードウェアアクセラレーション機能を利用するためのディレクティブがあります。ちょっと前に社内でこの機能でAES-NI使いたいよね的な話をしていていろいろ調べてたのでまとめてみました。 AES-NIが使えるかどうか調べる AES-NIはCPUの拡張命令セットなのでまず利用しているCPUでAES-NIがサポートされている必要があります。Linuxだと/proc/cpuinfoのflagsにaesが含まれていなければなりません。また、Intelのサイトでもプロセッサの型番レベルで調べることができます。

    nginxのssl_engineとAES-NI - Qiita
    progrhyme
    progrhyme 2015/04/13
    cpuが対応しててopenssl 1.0.1以上なら速くなる。/ nginxのssl_engineとAES-NI - Qiita /
  • nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita

    nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser

    nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita
    progrhyme
    progrhyme 2015/04/02
    良記事 / nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita /
  • 1