nginxに関するshin1x1のブックマーク (103)
-
shin1x1 2018/01/16
-
ISUCON7予選1日目にチーム「ババウ」で参加して最終スコアは205148でした - このブログはURLが変更になりました
Webサービスをいい感じにパフォーマンスチューニングするコンテスト ISUCON7予選1日目に @netmarkjp, @ishikawa84g, @matsuu でチーム「ババウ」にとして参加しました。最終スコアは 205148 でした。 考察 netmarkjp 例年通りの役割分担がしっかり機能して気持ちよくできた 視点を変えたり休憩とったりがいい感じにできた 去年の何もできなかった無念は多少供養できた 練習をきちんと活かせた ベンチが安定しててすごくよかった BGMは東京スカパラダイスオーケストラでした matsuu トラフィックがボトルネックになる問題をなかなか解決できずにいたが、Cache-Controlにpublicを入れることを思いつけた 304応答が安定して発生しない理由が生成される画像の更新日時がサーバ毎に異なるためであることに気づけた自分を褒めてあげたい tcpdump
-
NginxでWebサーバ間をトレースするrequest_id - Qiita
$request_id Nginx 1.11.0 以降に限りますが、リクエスト毎に発番されるIDの変数として $request_id が追加されたようです。 http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_id この変数を利用することにより、Nginxコアだけでサービス間のトレースを簡単に行うことが可能になります。 シンプルな例 以下のように、$request_idをログに含めるだけでリクエスト毎のIDを記録できます。 http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "
-
Redirecting to ssl-config.mozilla.org...
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
-
mruby + ngx_mrubyでアプリケーションを実装するという選択肢 - LIFULL Creators Blog
はじめまして、技術基盤部の相原(kaihar4)です！ 今回は、アプリケーションのクラウドサービスへの移行の一環で、 Amazon S3から取得した画像URLを含むファイルを元に、そのURLの外部画像を取得して返す機能 をmrubyで書き直してAWSに移行した話をしていきたいと思います。 この機能は元々モノリシックなアプリケーションの一機能として動いていたもので、これを切り出してAWSに移行するというのが今回私に与えられたミッションでした。 このアプリケーションは歴史が長く、その間ほとんどメンテナンスされていませんでした。 ディストリビューションは古くPHPのバージョンも4系、したがってそのまま持っていくという選択肢はなく、AWS上に新規にインスタンスを構築することになります。 弊社にはAPI部分をPHPからRubyに移行する方針があるということもあり、Amazon Linux上にRuby
-
Mitigating the HTTPoxy Vulnerability with NGINX
On 18 July 2016, a vulnerability named ‘HTTPoxy’ was announced, affecting some server‑side web applications that run in CGI or CGI‑like environments, such as some FastCGI configurations. Languages known to be affected so far include PHP, Python, and Go. A number of CVEs have been assigned, covering specific languages and CGI implementations: Apache HTTP Server (CVE-2016-5387)Apache Tomcat (CVE-201
-
mod_mrubyとngx_mrubyの最新のアーキテクチャとリファレンス公開（まだまだAdvent Calendar募集中です） - 人間とウェブの未来
この記事は、mod_mruby ngx_mruby Advent Calendar 1日目の記事になります。 現在既に13日分が登録されており非常に楽しみです。といっても、まだ12日分空いていますので今もなお募集中でございます！是非是非ご登録を！ 今日は1日目なので、mod_mrubyとngx_mrubyの最新のアーキテクチャとリファレンス公開ということで、2014年11月に情報処理学会のジャーナルに採録され公開されたmod_mrubyの元になるアーキテクチャの論文を下記のリンクからPDFで無料で公開します。どうぞ皆さんタブレットにPDFを保存したり印刷したりして読んでみてください。謝辞には馴染みの方々のお名前を書かせていただきました。 最新のアーキテクチャ論文 論文 [pdfダウンロード] mod_mruby：スクリプト言語で高速かつ省メモリに拡張可能なWebサーバの機能拡張支援機構 ス
-
ngx_mrubyでmemcachedやmysqldのコネクションを使いまわす(性能測定) – kelp
はじめに どうも、GMOペパボ 久米です。 そろそろ（最初から）雇用形態の話は面白くないので、これからのはじめの挨拶は何にしようか悩んでいます。 さて、今回は以下で作った ngx_mruby の性能の検証をしようと思います。 ngx_mrubyでmemcachedやmysqldのコネクションを使いまわす 性能検証の目的 ngx_mrubyからリクエスト毎にmemcachedに接続する場合と、 mruby-userdata でコネクションを使い回す場合とでどの程度の性能差が出るのかを確認したい。 前提 実行環境: MacBook Pro (Retina 13-inch、Early 2015) CPU 2.7 GHz Intel Core i5 RAM 16 GB 1867 MHz DDR3 Virtual Box上の仮想マシン 今回は測定結果の値そのものではなく、それぞれの性能差を比較す
-
Auto ScalingではなくてAuto Cachingという考え方 - Copy/Cut/Paste/Hatena
今年の3月くらいからずっと悶々としていて、なかなか手が出せなかったアイデアがやっと実現できました。 mod_mrubyでやりたいことできたー！— k1LoW (@k1LoW) June 16, 2016 （試行錯誤して書いてみたら、結果たった数行という。。。） Auto ScalingではなくてAuto Cachingという考え方 AWSではAuto Scalingという、サーバの負荷の変化などによってEC2インスタンスをスケールする便利な機能があります。 が、大抵はクラウド環境でないと容易には実現できません。 例えば、クラウドではなく サーバリソースは増やせない。 普段はキャッシュはしてほしくないコンテンツ。 ただ、アクセスが多くなるとかで何かしら負荷が高くなった時には「仕方なく」キャッシュを使っても良い。落ちるよりはマシ。 負荷が戻ったらキャッシュを使わないようにして欲しい。 という状
-
Docker と infrataster で nginx の振る舞いをテストする
こんにちは。吉川 ( @rrreeeyyy ) です。今期オススメのアニメはリゼロです。 Nginx は設定ファイルの記述力も高い、大変便利な Web サーバです。 便利な反面、設定ファイルの複雑化や、設定に依っては意図しない挙動を引き起こしてしまうこともあります。 そこで本稿では docker 並びに infrataster を使用し、 Nginx の挙動をテストすることによって、安全に Nginx の設定を記述する方法について紹介します。 テスト対象の Nginx の仕様 今回は例として、次のような仕様の Nginx のテストについて考えます。 ネットワーク帯は 10.0.0.0/16 を使用している Nginx の前段として L7 ロードバランサが存在している L7 ロードバランサが https を終端している Nginx 自体は 80 番ポートと 8080 番ポートにて待ち受けてい
-
３つのnginxをうまく使い分けよう〜nginx、OpenResty、Tengine〜
OpenRestyはnginxのほかにngx_luaをはじめとするCで書かれた各種サードパーティモジュールとngx_luaのAPIを利用したrestyモジュール、そしてLua/LuaJITで構成されています。 OpenRestyに含まれているnginx自体は本家のnginxと基本同じなので、別にOpenRestyを利用しなくても自分でngx_luaを組み込んだり、サーバ上にrestyモジュールを配布することで似たような環境を構築することは可能ですが、OpenRestyであれば主要なモジュールやライブラリが./configure、make、make installの一連の流れですべてゴソッとインストールされますし、OpenRestyのconfigureスクリプトはnginxのconfigureスクリプトを継承したものなのでnginxのconfigureオプションをほぼそのまま利用することもで
-
100行あったmod_rewirteを ngx_mrubyで書き換えた話
第5回ペパボテックカンファレンス〜インフラエンジニア大特集〜 で発表した資料です http://pepabo.connpass.com/event/30348/
-
-
Tuning TCP and NGINX on EC2
Chartbeat measures and monetizes attention on the web. They were experiencing slow load times and TCP retransmissions due to default system settings. Tuning various TCP, NGINX and EC2 ELB settings like increasing buffers, disabling Nagle's algorithm, and enabling HTTP keep-alive resolved the issues and improved performance. These included tuning settings like net.ipv4.tcp_max_syn_backlog, net.core
-
ngx_mrubyがHomebrewで超簡単にインストールできるようになった - 人間とウェブの未来
タイトルの通りなのですが、つい先日Homebrewでngx_mrubyがインストールできるようになりました。 github.com うおお、なるほど超便利と思って手元で試すと、mrbgemで使うライブラリのリンクまわりでコケていてビルドできませんでした。 そこで、必殺の「Hi, I'm ngx_mruby author.」PRによってバグ修正を最速でマージしていただき、無事ビルドできるようになりました事をここにお知らせします。 github.com 実際、ngx_mrubyをちょっと検証してみようかな、という用途でめちゃくちゃ便利で、以下のようにするだけであっという間にMac上でngx_mrubyを組み込んだnginxが動くようになります。 brew tap homebrew/nginx brew install nginx-full --with-mruby-module または、最新の
-
Consulを利用したTLSセッションチケットの自動更新 | メルカリエンジニアリング
Site Reliability Engineering Team（通称SRE）の@cubicdaiyaです。最近チーム名が変わりました。 今回はConsulを利用して複数台のnginxサーバのTLSセッションチケットを自動更新する仕組みについて紹介します。 TLSセッションチケットは簡単に言うとTLSのセッション情報を暗号化してクライアント側に保存することで HTTPS通信時に行われるTLSハンドシェイクの手順を省略してネットワークレイテンシを削減するための仕組みです。(詳細については一番下の参考情報を御覧ください) 似たような仕組みとしてTLSセッションキャッシュがありますが、こちらはセッション情報をサーバ側に保存します。 HTTPS通信ではTCPのハンドシェイクに加えてTLSのハンドシェイクが必要になるのでHTTP通信よりもネットワークのレイテンシが大きくなりますが、 これらの仕組み
-
Mitigating DDoS Attacks nginx + ngx_mruby + http-dos-detector
Mitigating DDoS Attacks nginx + ngx_mruby + http-dos-detector https://github.com/matsumoto-r/http-dos-detector Detect Huge Number of HTTP Requests on Apache and nginx using mruby code. http-dos-detector use same Ruby code between Apache(mod_mruby) and nginx(ngx_mruby). It seems, programmable DDoS firewall by mruby on nginx. This solution provides regulating the incoming HTTP/S traffic and controll
-
nginxをWebSocketのリバースプロキシとして使う - the glue
経緯 WebSocketを使ったアプリケーションを作ったが、ポートが80しか使えない nginxでどっちも80に流したい ポイント / はまり所 WebSocketのプロキシにはUpgradeヘッダ(HTTP 1.1)への対応が必要 Upgradeヘッダへの対応は nginx v1.3.13以降 参考: WebSocket proxying 厳しい条件から先に書く デフォルトだと30秒通信がないと切断される（！） nginxでリバースプロキシしているときだけ一定時間で接続が切れるので何かと思えば、 普通のHTTPの通信と同様に30秒（だったはず）通信がなかった場合はタイムアウトってことで自動でコネクションを切ってくれていたみたい。 ping/pongを30s以内にやればいいんだろうけど、とりあえず5分に設定。 config server { listen *:80 default_serv
-
ApacheやNginxのSSL関連のおすすめ設定を生成する便利サイト - cakephperの日記(CakePHP, Laravel, PHP)
ApacheやNginxとopensslのバージョンを指定するとおすすめの暗号スイートなど、SSL設定ファイルを表示してくれるMozillaのサイトがあります。 https://mozilla.github.io/server-side-tls/ssl-config-generator/ これを使えば安全な暗号スイートのみを使ってる設定などが簡単に生成されますので、この通りに指定すれば良いです。 Apacheの場合はデフォルトでは暗号スイート設定の記述はなかったと思いますが、下記の3つは表示通りに指定しておくのが良いかと思います。 SSLProtocol SSLCipherSuite SSLHonorCipherOrder Oldを選択すると、古いブラウザにも対応してる暗号スイートを含めます。ただ暗号強度が弱いものが含まれるためサイトのアクセス傾向をみて古いブラウザのアクセスが無いのであれ
-
Nginxと名前解決の話 - Masteries
Nginxでは, serverコンテキストのlocationコンテキストにおいて, proxy_passディレクティブを利用することで任意のホストにアクセスを転送することができます. 例えば, serverコンテキストにおいて, location / { proxy_pass http://127.0.0.1:5000; } みたいに書いてあげれば, localhostの5000番ポートにアクセスを転送することが出来ます. Webサービスでは, こういう感じでNginxが443番(HTTPS)や80番ポート(HTTP)で受けたアクセスを5000番ポートなどで動いているWebアプリケーションに転送している訳です. で, このproxy_passディレクティブは, IPをそのまま書くのではなく, 次のようにドメインを書くこともできます. location / { proxy_pass http
[HOWTO] Get real IP coming via AWS CloudFront and ELB to nginx
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
