2016-10-11 31 views
6

私はdjangoアプリ(特にdjango-rest)を持っています。このサイトのローカルコピーを実行すると、私のリクエストは50〜400ミリ秒で処理できます。Azure "App Service" - DjangoとSQLite

次に、Microsoft Azure App Serviceに展開できました。今、私が購入できる最も高価な層の下で、800-2000msの範囲で応答が戻ってきます。

アプリはsqliteデータベースで簡単なクエリを実行します。このデータベースファイルは約30メガバイトで、最大のテーブルは12000行です。

データベースへのアクセスはすべて読み取り専用であるため、競合は発生しません。

構成:

DATABASES = { 
    'default': { 
     'ENGINE': 'django.db.backends.sqlite3', 
     'NAME': os.path.join(PROJECT_ROOT, 'mydatabase.db'), 
    } 
} 

web.configファイル:

<?xml version="1.0"?> 
<configuration> 

    <appSettings> 
    <add key="WSGI_ALT_VIRTUALENV_HANDLER" value="django.core.wsgi.get_wsgi_application()" /> 
    <add key="WSGI_ALT_VIRTUALENV_ACTIVATE_THIS" value="D:\home\site\wwwroot\env\Scripts\activate_this.py" /> 
    <add key="WSGI_HANDLER" value="ptvs_virtualenv_proxy.get_virtualenv_handler()" /> 
    <add key="PYTHONPATH" value="D:\home\site\wwwroot" /> 
    <add key="DJANGO_SETTINGS_MODULE" value="myapp.settings" /> 
    </appSettings> 
    <system.web> 
    <compilation debug="true" targetFramework="4.0" /> 
    <!-- Required for websockets. --> 
    <httpRuntime targetFramework="4.5"/> 
    </system.web> 
    <system.webServer> 
    <modules runAllManagedModulesForAllRequests="true" /> 
    <handlers> 
     <remove name="Python273_via_FastCGI" /> 
     <add name="Python FastCGI" path="handler.fcgi" verb="*" modules="FastCgiModule" scriptProcessor="D:\Python27\python.exe|D:\Python27\Scripts\wfastcgi.py" resourceType="Unspecified" requireAccess="Script" /> 
    </handlers> 
    <rewrite> 
     <rules> 
     <rule name="Static Files" stopProcessing="true"> 
      <conditions> 
      <add input="true" pattern="false" /> 
      </conditions> 
     </rule> 
     <rule name="Configure Python" stopProcessing="true"> 
      <match url="(.*)" ignoreCase="false" /> 
      <conditions> 
      <add input="{REQUEST_URI}" pattern="^/static/.*" ignoreCase="true" negate="true" /> 
      </conditions> 
      <action type="Rewrite" url="handler.fcgi/{R:1}" appendQueryString="true" /> 
     </rule> 
     </rules> 
    </rewrite> 
    </system.webServer> 
</configuration> 

Pythonのバージョン2.7。

私はそれをSQLiteのパフォーマンスに絞り込んだ。静的ファイルとAPIインデックスページは〜60msに戻りますが、最も重いクエリは〜2000msに戻ります。これは全体的な応答時間ではなく、Time Till First Byteであり、ネットワーク遅延(地理的近接度のために非常に低い)を排除しています。これは、P3(プレミアムティア)4コア、7GBラム(Azureが呼び出すように)にあります。

ローカルホスト上で実行すると、応答時間はインデックスページで15ms、Macbook 2.2GHz Intel Core i7 16GB 1600MHz DDR3で同じリクエストで約380msです。私はより多くの情報については、Djangoの残りのツールバーをインストールし :これはその(タイミングが数リフレッシュに基づいています)すでに「ホット」

を更新した後であるよう

のApp「ウォームアップ」は問題ではありません。 MacBookのジャンゴDEVサーバ(?純粋なのpython)で

:紺碧アプリサービスIISおよびFastCGI(上記の設定を参照)で

SQL time ~217ms 
Total CPU time ~681ms 

Resource Value 
User CPU time 662.771 msec 
System CPU time 18.415 msec 
Total CPU time 681.186 msec 
Elapsed time 681.326 msec 
Context switches 1 voluntary, 95 involuntary 

SQL time ~854ms 
Total CPU time ~2282ms 
No CPU extended breakdown available. 

は、任意の洞察力に感謝!

+0

あなたのWebアプリケーションにはいくつのインスタンスがありますか?長い応答時間の後、データは正しいですか? SqlLiteデータベースをどのように展開しますか? –

+0

1インスタンス、私はAPIを打つだけです。 sqliteデータベースは、GIT(30 MBファイル)を介して配備されたファイルです。 – beiller

+0

もしあなたがsqliteがdebug-toolbarのsqlタブを見て、いくつのクエリがそこに現れているのか、そして最も遅いものがあるのか​​を調べるならば – e4c5

答えて

0

あなたのローカルとAzureテストの実行には、最高から最悪の場合と同様の倍数が示され、30MBのデータベースファイルしかないことを考えれば、あなたのAzureホストは、はるかに低速のCPUだと思います。

これは、throttling for some spec VMsという事実によってバックアップされています。 comparison to AWSにも記載されています。 App Serviceプラットフォームでも同じことが起こっていると思います。

+0

問題はSQLiteとI/Oのパフォーマンスであることが判明しました。彼らのフロントエンドサーバーが分散され、遅いネットワークファイルシステム上で動作するので、非常に悪いです。 SQLサーバーに切り替えることは唯一の解決策です。 – beiller

+0

おそらく、SQL Server製品のディスクI/Oを向上させるためです。 –

関連する問題