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

Недавно я играл с 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, использующий патч-пакет (+ Apache как интерфейс)

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

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

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

Ответы

Ответ 1

Так как никто не ответил, я немного исследовал, и похоже, что моя проблема может иметь отношение к 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 (снова с пакетом исправленных пакетов). На этот раз на реальном хосте (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 мс.