2016-10-11 3 views
6

У меня есть приложение django (в частности, django-rest). Когда я запускаю локальную копию этого сайта, мои запросы могут обрабатываться через 50-400 мс.Azure «Служба приложений» - Django и SQLite

Далее мне удалось установить службу поддержки Microsoft Azure. Теперь, при самом дорогостоящем ярусе, который я могу купить, ответы возвращаются в диапазоне 800-2000мс.

Приложение выполняет простые запросы в базе данных 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 возвращаются в ~ 60 мс, а самый тяжелый запрос - в ~ 2000 мс. Это время до первого байта, а не общее время отклика, и я исключил задержку в сети (что очень мало из-за географической близости). Это на P3 (Premium Tier) 4 ядра, 7 ГБ оперативной памяти (по мере того как Azure называет его).

Запуск на локальном хосте, время отклика составляет ~ 15 мс для индексных страниц и ~ 380 мс для тех же запросов на моем Macbook 2,2 ГГц Intel Core i7 16 ГБ 1600 МГц DDR3.

App «разминка» не является проблемой, поскольку это после того, как его уже «горячий» (время основано на нескольких обновляемая)

Update: Я установил Джанго Rest панель инструментов для получения дополнительной информации.

На Macbook Джанго DEV сервер (чистый Python?):

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 

На лазурном IIS приложение службы и FastCGI (см конфиг выше):

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

Цените любую проницательность!

+0

Сколько экземпляров имеет ваше веб-приложение? После долгого времени ответа данные верны? Как вы развертываете свою базу данных SqlLite? –

+0

1 экземпляр, только я ударяю по API. База данных sqlite - это файл, развернутый через GIT (файл 30 МБ). – beiller

+0

Если вы подозреваете, что sqlite является виновником, посмотрите на вкладку sql в панели debug-toolbar и посмотрите, сколько запросов появилось там и что самое медленное. – e4c5

ответ

0

Учитывая, что ваши локальные и лазурные тестовые прогоны показывают аналогичные множественные от наилучшего до наихудшего случая, и что у вас есть только файл базы данных 30 МБ, я предполагаю, что ваш Azure-хост просто намного медленнее.

Это подтверждается тем фактом, что они делают throttling for some spec VMs. Это также то, что было отмечено в comparison to AWS. Я полагаю, что то же самое верно и для платформы App Service.

+0

Оказывается, проблема связана с производительностью SQLite и I/O. Это очень плохо, потому что их интерфейсные серверы распределены и работают над медленной ... сетевой файловой системой. Единственным решением является переход на SQL-сервер. – beiller

+0

Предположительно, это потому, что они гарантируют лучшую идентификацию ввода-вывода для своих предложений SQL-сервера. –