Kosei Kitahara's Blog

やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？...

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで...

こんにちは、Python 会の。。。思いつきませんでした。初 " Python Web フレームワーク アドベントカレンダー2010 " に参加させていただくことになりました。よろしくおねがいします。アドベントカレンダー参加者のブログは cielquis.net に綺麗にまとめられていますよ。 ごめんなさい。Web アプリケーションフレームワークの作成なんて 1 日じゃむりぽ＞＜。メインで使ってるフレームワークは、 Django か webapp ぐらい。。。最近 dis られてるので、Django 記事書くのもあれだ・・・。 ということで本題です。Python は WSGI (Web Server Gateway Interface) という Web アプリケーションと Web サーバ間の共通インターフェースがあります。そのインターフェースを実装したオブジェクトは、Web アプリケーションとして動作させることができます。ということで、デスクトップアプリケーションを Web アプリケーションにする方法を書きたいと思います。今回は Qt の Python binding な PyQt / PySide で WSGI アプリケーションを作ってみたいと思います。実装は PySide ですが、 PyQt でも動くはずです。 STEP1: PySide で Hello World! ほんと Web アプリケーションじゃなくて申し訳ないですが、最初に PySide で "Hello World!" を表示します。 import sys from PySide import QtCore, QtNetwork, QtGui class QWSGILabel(QtGui.QLabel): def __init__(self, text, parent=None): super(QWSGILabel, self).__init__(text, parent=parent) class QHttpWidget(QtGui.QWidget): def __init__(self, parent=None): super(QHttpWidget, self).__init_...

" DAMON BLOGONS " の、 " The Perfect Django Settings File " という記事で紹介されていた Django の設定 (settings.py) が面白かったので、私が利用しているものと併せて紹介したいと思います。 環境による DEBUG の切り分け 開発環境では " DEBUG = True " と書くと幸せになれます。Django のデバッガーは強力です。ただし、本番環境にそのままデプロイしてしまうと・・・。デプロイを楽にするためにも、失敗を防ぐためにも自動的に切り分けるのが望ましいですよね。Damon 氏は以下のようなコードで切り分けているようです。 # Set DEBUG = True if on the production server if socket.gethostname() == 'your.domain.com': DEBUG = False else: DEBUG = True 開発環境 localhost (127.0.0.1) と運用環境 your.domain.com のホスト名の違いを利用して切り分けています。 データベース設定 データベースの設定も開発環境と本番環境では違います。Damon 氏は 2 つのファイルを使い切り分ける方法を紹介しています。この方法は私もよく使います。これは pinax でも利用されている方法です。1 つは本番環境の設定をそのまま記述したファイル (settings.py) で、もう 1 つが開発環境の設定を記述したファイル (local_settings.py) です。settings.py の 最後に 、以下のコードを書いておき、 local_settings.py は本番環境にデプロイしないことで設定を切り分けています。 try: from local_settings import * except ImportError: pass local_settings.py で settings.py の内容を上書きします。私はデータベースの設定だけでなく、上述した DEBUG 設定なんかの上書きに使っています。loc...

Ubuntu でしか作ったことなかったけど、CentOS 5 系 で Django をデプロイしてみる とりあえずパッケージを最新に更新 # yum update python 2.6 のインストール CentOS ってデフォルトでは 2.4 なんですね。2.6.4 をソースから入れる。まず zlib, sqlite を入れる。sqlite いれないと import sqlite3 できない # yum install zlib zlib-devel sqlite-devel python ソースのダウンロードとビルド、インストール # wget http://python.org/ftp/python/2.6.4/Python-2.6.4.tgz # tar xvfz Python-2.6.4.tgz # cd Python-2.6.4 /opt/python2.6 にインストール。path は個人的な趣味。 --enable-shared オプションを追加する # ./configure --prefix=/opt/python2.6 --with-threads --enable-shared Setup ファイルで zlib のところのコメントを外す。 # vi Modules/Setup --- #zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz +++ zlib zlibmodule.c -I$(prefix)/include -L$(exec_prefix)/lib -lz # make # make install python 2.6 環境設定 (2.4 と共存させる) パス周りを設定 # vi /etc/ld.so.conf.d/opt-python2.6.conf # /sbin/ldconfig # sudo ln -s /opt/python2.6/bin/python /usr/bin/python2.6 # cd 個人的な趣味で、PATH は.bash_profile, alias は .bashrc にセット # vi .bash_profile --- PATH=$PATH:$HOME/bi...

3/19、 SoozyCon #7 に飛び入り参加させていただいた。 Soozy とはperlベースのWAF(Web Application Framework)らしい。今回の勉強会ははPythonistaとPerlerの集い的な（？）。 PythonistaからPerlerへ Djangoいいよ（ everes さん） フル チン スタックなWAF ModelはCharFieldだけじゃなくて、用途別に用意されている URLFieldなんてsave前にHTTPリクエストなげちゃって存在確認までやってくれる Modelに情報多いから、数行でFormが作れる many2manyは中間テーブル意識しなくてよし 簡単なPythonコードでアクセス出来ちゃう ModelのManagerクラス作って、挙動を制御できちゃう Modelさえ書いちゃえば、GenricViews（汎用ビュー）で追加、編集、削除のIFができちゃう contlibに標準アプリが沢山入ってる バックオフィスなadminはとても便利 テンプレートはかなりデザイナー志向 便利な標準テンプレタグがある（CYCLEとか） [method].alters_data = Trueでテンプレからは呼べないメソッドを作れる Python的なWAF事情（ @mopemope さん） Pylons はプラガブル Nevow はTwistedベース web2py はWebからコードを書ける CubicWeb はキモイ WSGI で Werkzeug が流行り （WebOb, URLRealay, Routes, WebFlash, WebErrorとかの便利なパッケージを組み合わせる） TurboGears の禅の思想は素敵 これはリンクを張っておく: tg.__init__.py （Pythonistaこういうの好きだなｗ） Perler から Pythonista へ Angelosに - 最近のPerlのWAF事情(dannさん) C3はおばーちゃんの遺言で使えない ROSEは名前が嫌い HTTP::Engine、Moose(Mouse?)はいい 自分で作っちゃえがフルスタックなAngelos WAF作成の敷居は下がった あ...