VirtualBoxを使って固定IPを設定してみましょう。

VirtualBox独自のDHCPサーバーを持っており、192.168.56.xxxのサブネットワークを形成しています。固定IP設定するには、まずこのDHCPサーバー機能を停止し、独自の固定IPを付与する必要があります。さらに、ホスト側のサブネットワークと通信できるように、例えばWinXPならブリッジネットワークにVirtualBoxのネットワークアダプタを追加して同じサブネットワーク内で通信できるようにする必要があります。

以下、ホストOSがWinXP、ゲストOSがDebian5の場合の設定方法です。

Djangoには、キャッシュバックエンドとして様々な機構をサポートしています。

1. メモリキャッシュ
2. データベースキャッシュ
3. ファイルキャッシュ

また、バックエンドとは別に、キャッシュ化できるデータの単位も様々です。

• サイト全体をキャッシュ化
• ビュー単位でキャッシュ化
• テンプレートの一部をキャッシュ化
• オブジェクトの単位でキャッシュ化

特に「オブジェクト単位」でキャッシュ化できるため、原理的には変数ひとつだけをキャッシュデータ化することも可能で、まさに究極の粒度をもったキャッシュ機能であると言えます。

また、もっと上流のキャッシュ機能とDjangoベースのWebサーバーを連携させることも可能です。例えば、squidなどのProxyベースのキャッシュ機能との連携がそれに該当します。

まさに、なんでもあり、のDjangoキャッシュ機能ですが、今回はその中でも最も高速なメモリベースのキャッシュを中心に、キャッシュの設定方法を見ていきましょう。

サイトマップを作成すると、Google, Bingなどの検索エンジンに効率的にクローリングしてもらえるようになるだけでなく、ホスティングしているページ全体に対して、何割がインデックスされているのか？検索エンジンの進捗を確認することが可能となり、SEO効果が期待できます。
しかし、サイトマップ一つとっても、そのフォーマットを覚えたり、XMLを整形したりするために多分の労力を払う必要があり、容易ではありません。

しかし、Djangoにはサイトマップを簡単に作成する機能が組み込まれています。
この機能を提供するのが、 django.contrib.sitemap クラスです。

開発者は、モデルに対するサイトマップクラスを定義するだけで、サイトマップ用のビューを生成することが可能です。

簡単なアプリを例にとり、サイトマップの作成方法を見ていきましょう。

Djangoでは、アプリ、context_processorsなど様々なプラグイン機能が提供されており、画一的なフレームワークの中でソフトウェアを実装することで効率化・高可搬性を実現しています。

しかし、一旦システムを実装開始すると、システムは様々な環境が依存しあうもので、一つの関数を書き換えると様々なビューやテンプレートファイルに修正範囲が波及する。。。なんてことがよく起こります。

せっかくMVCフレームワークを提供しているのに、それを正しく使わないのが悪い！などと怒られそうですが、理想と現実は異なる訳で、プラットフォームにはそのどちらもフォローできる柔軟な環境が求められます。

既存のシステム全てに共通で処理をフックしたり、テンプレート変数を追加したい。。。などということを実現するにはどうしたら良いのでしょうか？

これを簡単に実現できる方法がDjangoにはあります。
それがミドルウェアです。

Djangoでは、ビュー関数名やビューに付けた名前（＝名前付きURLパターン）から対応するURLを逆引きする機能をサポートしています。

これを URLの逆引き と呼びますが、この機能を使うとHTML上でURLを直接記述する必要がなくなり、アプリケーションの可搬性が高まります。つまり、通常URL設計を変更する場合、テンプレートやビュー内で変更対象となる部分を書き換える必要が出てきますが、このような書き換え作業から開放されるのです。

それでは、URLの逆引き方法を見てみましょう。

Djangoには、テンプレートファイル内でのみ利用できるテンプレート変数と、グローバル変数のように、どのテンプレートファイルからも利用できるテンプレート変数も存在しています。

そのようなグローバル変数的なテンプレート変数のことをcontext_processorと呼びます。settings.pyにて、TEMPLATE_CONTEXT_PROCESSORS変数に、テンプレート変数を返すメソッドを登録しておくと、どのビューからでも当該変数をコンテキストに追加することが可能となります。

    $ emacs settings.py
      TEMPLATE_CONTEXT_PROCESSORS = (
         "hogeapp.context_processors.user_name",
         ...,
      )

    $ emacs hogeapp/context_processors.py
      def user_name(request):
         if ( request.user.is_authenticated() ):
            return {"uname": request.user.username}
         else:
            return {"uname": None}

上記の例は、ログインしている場合に、アカウント名を常に「uname」というテンプレート変数に格納するような設定です。

Apache2系ではデフォルトのプロセスモデルが「Worker + Prefork」方式になりました。 簡単に言うと、

• HTTPリクエストに応答するWebサーバープロセスを予め複数起動しておくことで プロセス生成時間を排除することで応答時間（スループット）を短縮しようというのがPrefork。
• 当該プロセスからさらに応答スレッドを複数生成して大量のリクエストに応答しようというのが Worker。

上記モデルが採用されたことでApacheはさらに応答速度、同時応答数の性能を増加させた 訳ですが、一方で隠された仕様変更も生じています。
CGI内でSIGALRMシグナルを使用できないというのもその代表例です。