uwsgiでのgraceful reloadについて - Qiita
uwsgiのgraceful reload(hot reload)について日本語で解りやすくまとまっている記事が無かったのでまとめてみようと思いました。 既に稼働しているアプリケーションサーバを更新する際に、既に接続しているクライアントが切断されないようにreloadを行うための技術です。v1からv2の状態へと移行するためにreloadした場合v1のworkerを保持しつつv２のworkerを立ち上げてv1の接続がなくなったら順次そのworkerを切って行き、接続を切断せずに移行して行くような方法があります。 参考ドキュメントと動画 ○ The Art of Graceful Reloading ○ [動画] pycon jp 2015 uWSGI/Dockerを利用したWebサービス運用事例 graceful reloadの種類 今回はuwsgiのtouche-reload系のoptio
Apacheにかわるwebサーバ: uWSGIパフォーマンスチューニング - Qiita
背景 PythonとDjangoでソマートフォンゲームのアプリケーションサーバを開発しており、そのwebサーバとしてuWSGIを使っています。 uWSGIには多くのパラメータがありすぎてどれを選んでいいかわかりにくいです。 実際に負荷試験をして、各種パラメータを変え、安定的にパフォーマンスが出せるようになったので、 そのときにどのように計測して、どのパラメータを変えたのかを共有したいと思います。 環境 python: 2.7.10 uWSGI: 2.0.11.1 locust: 負荷試験のツールです。ユーザシナリオを作ってアプリケーションサーバの各種API負荷試験をしました。 EC2: c4.2xlargeの8コア 性能測定ツール という言葉がありますが、何をおいても計測できなければ改善したかどうかわかりません。 主に以下のツールが今回役立ちました。 NewRelic: おなじみですね。有
uwsgiメモ
uwsgi関連ではまった点などをメモ invalid request block size ajaxでサーバ側からデータを読み込むライブラリを使ってると、条件によって502エラーが出てる(=大体djangoとかのプログラム側のエラーで出る)ので、uwsgiのログを調べると、invalid request block sizeというエラーが出てた。 んで、調べてみると、uwsgiがリクエストのサイズが大きすぎるとエラーを吐いているらしい。ライブラリ側で勝手にパラメーター付けて送られてリクエストのサイズが大きくなっているので、こりゃ調整しないとなということで調べてみた。起動時にオプション設定するか、iniファイルで設定したらいけるらしい $ uwsgi --buffer-size=xxxx ... buffer-size= xxxx ... 参考：uwsgi invalid request b
uWSGIのログローテートが出来てなかった話 – taichino.com
先日uWSGIのログをfluentdで取り始めたと書きましたが、寝て起きてみると早速問題が発生していて、zabbixにデータが送られてなくてグラフが空の状態になっていました。何で、と思ってみて見るとuWSGIのログが空になっていました。どうもログローテートが走った後にuWSGIがログを開き直しておらず、新しいファイルが空のままになっていたようです。これは酷い。 それでどうするんだっけと、/etc/logrotate.d/の他のファイルをチラチラ見てると、HUP送ったり再起動したりするのが定石っぽいので、uWSGIでもそうするのかなと思ってuwsgi –helpを読んでいると、 --touch-logreopen というオプションを見つけました。このオプションにファイルを指定すると、そのファイルを監視して変更されたタイミングでログを開き直すというものです。再起動するよりコチラの方が良さそうな
nginx + uwsgi でアプリケーションをサブディレクトリで動かす設定 - Qiita
やりたいこと 複数のアプリケーションを、同一の virtualhost 内で動かす。 http://example.com/app1/hello にアクセスすると、 localhost の uwsgi で動いているアプリの /hello に飛ばすとか。 基礎知識 (多分CGI由来の) 3つの重要な変数を理解しましょう。 REQUEST_URI が、ユーザーがアクセスしたホスト名以降のパスです。 SCRIPT_NAME が、アプリが動いている場所です。 CGI だったら .cgi とか php だったら .php とか拡張子があったりします。 PATH_INFO が、 SCRIPT_NAME 以降のパスです。アプリのURLディスパッチャはこの変数を見たりします。 この3つの変数がきちんと設定できていないと、URLディスパッチやリダイレクトが上手く動かない事になります。 デフォルトで用意されて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blog - Industry Leader In Affiliate Marketing Solutions | Skimlinks
[uWSGI] Default Log Format Explained?
uWSGI, cherrypy and threading
ちゃんと運用するときのuWSGI設定メモ - Qiita