Jython + Django не готовы к производству? - PullRequest
Новая
       19

Jython + Django не готовы к производству?

11 голосов
/ 14 февраля 2011

Так что недавно я играл с Django на платформе Jython и хотел увидеть его производительность в «производстве».Сайт, на котором я тестировал, представлял собой простое return HttpResponse("Time %.2f" % time.time()) представление, поэтому база данных не использовалась.Я попробовал следующие две комбинации (измерения сделаны с ab -c15 -n500 -k <url>, все в Ubuntu Server 10.10 на VirtualBox):

  • Сервер приложений J2EE (Tomcat / Glassfish), развернутый файл WAR

    Я получаю результаты типа 

    Requests per second:    143.50 [#/sec] (mean)
[...]
Percentage of the requests served within a certain time (ms)
  50%     16
  66%     16
  75%     16
  80%     16
  90%     31
  95%     31
  98%    641
  99%   3219
 100%   3219 (longest request)

    Очевидно, что сервер время от времени зависает на несколько секунд, что недопустимо.Я предполагаю, что это как-то связано с перезагрузкой Jython, потому что запуск оболочки jython тоже занимает около 3 секунд.

  • Обслуживание AJP с использованием пропатченного пакета flup (+ Apache в качестве внешнего интерфейса)

    Примечание: flup - это пакет, используемый manage.py runfcgi, мне пришлось его исправлять, потому что поддержка потоков / разветвления flup, похоже, не работает на Jython (-> AJP был единственным рабочим методом).

    Здесь почти такие же результаты, но иногда последние 100 запросов вообще не получают ответа (но серверный процесс все еще жив).

Я спрашиваю об этом на SO (вместо serverfault), потому что это очень специфично для Django / Jython. У кого-нибудь есть опыт развертывания сайтов Django на Jython?Есть ли другой (более быстрый) способ обслуживания сайта?Или просто слишком рано использовать Django на платформе Java?

1 Ответ

17 голосов
/ 23 февраля 2011

Так как никто не ответил, я исследовал немного больше, и кажется, что моя проблема, возможно, связана с VirtualBox.Используя разные серверные ОС (Debian Squeeze, Ubuntu Server), у меня были похожие проблемы.Например, при простой обработке статических файлов я получил такой результат от веб-сервера Apache (на Debian): 

> ab -c50 -n1000 http://ip.of.my.vm/some/static/file.css

Requests per second:    91.95 [#/sec] (mean)    <--- quite impossible for static serving
[...]
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2  22.1      0     688
Processing:     0  206 991.4     31    9188
Waiting:        0   96 401.2     16    3031
Total:          0  208 991.7     31    9203

Percentage of the requests served within a certain time (ms)
  50%     31
  66%     47
  75%     63
  80%     78
  90%    156
  95%    781
  98%    844
  99%   9141                            <--- !!!!!!
 100%   9203 (longest request)

Это привело к выводу, что (у меня нет заключения, но) яЯ думаю, что перезагрузка Java не может быть проблемой здесь, скорее, виртуализация.Я опробую его на реальном хосте и оставлю этот вопрос без ответа до тех пор.

FOLLOWUP

Теперь я успешно протестировал сайт Django (на самом деле просто страницу приветствия), используяJython + AJP через TCP / mod_proxy_ajp на Apache (снова с исправленным пакетом flup).На этот раз на реальном хосте (i7 920, 6 ГБ ОЗУ).Результат подтвердил, что мое предположение было верным и что я действительно никогда не должен снова тестировать виртуальный хост .Вот результат для страницы приветствия: 

Document Path:          /jython-test/
Document Length:        2059 bytes

Concurrency Level:      40
Time taken for tests:   24.688 seconds
Complete requests:      20000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      43640000 bytes
HTML transferred:       41180000 bytes
Requests per second:    810.11 [#/sec] (mean)
Time per request:       49.376 [ms] (mean)
Time per request:       1.234 [ms] (mean, across all concurrent requests)
Transfer rate:          1726.23 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.5      0      20
Processing:     2   49  16.5     44     255
Waiting:        0   48  16.5     44     255
Total:          2   49  16.5     45     256

Percentage of the requests served within a certain time (ms)
  50%     45
  66%     48
  75%     51
  80%     53
  90%     69
  95%     80
  98%     90
  99%     97
 100%    256 (longest request)   # <-- no multiple seconds of waiting anymore

Очень многообещающе, я бы сказал.Единственным недостатком является то, что среднее время запроса составляет> 40 мс, тогда как сервер разработки имеет среднее значение <3 мс. </p>

...