Сервер С приложений - GWAN
На днях пришлось протестировать "самый быстрый" сервер приложений (по заявлению разработчиков) - Gwan. Но к сожалению, он оказался и самым глючным. Но обо всем по порядку.
Gwan - это сервер приложений (хотя так его назвать можно с натяжкой, если держать в голове мысли о Glassfish или JBoss), то есть вы пишете свой сервлет на чистом C с использованием довольно обширного API и сервер исполняет код в нем.
Сервер поставляется уже скомпилированным, в архиве в котором уже организована необходимая структура файлов и директорий. Вся установка сводится к распаковке архива в любую директорию и запуск бинарного файла. На официальном сайте доступна только 32-х битная версия. При этом на вопросы о отсутствии 64-х битной версии автор отвечает, что 32-х битная версия работает и на 32 и на 64, а вот у 64-х битной такой возможности нет.
Теперь к печальному. Исходные коды сервера закрыты. Совсем. На форуме, можно узнать позицию автора данного продукта о его виденье open-source и почему исходные коды Gwan не доступны.
Первая система на которой я проводил тесты была Ubuntu 11.04 32-bit. Как мне казалось в начале, это самое оптимальное решение, так как сервер только 32 бита и советы по установке необходимых библиотек были рассчитаны именно на Ubuntu.
После запуска веб-сервера можно походить и посмотреть на уже готовые примеры сервлетов, дабы базово понять возможности данного продукта. На самом деле возможности довольно интересные, и API реализованное на данный момент покрывает примерно 90% всех потребностей в случае реализации каких-то узких мест в проектах. В общем, после первых 10-15 минут мне понравилась как идея так и реализация. Но после вдумчивых ковыряний эйфория ушла.
Первым местом где Gwan показал себя с худшей стороны - это ошибки. В нем есть функционал, позволяющий красиво выводить простые проблемы в ваших сервлетах:
Но если там что-то более серьезное, сервер падает навзничь при этом выдавая минимум информации и в большинстве случаев бесполезную (пример), так как по косвенным признакам можно определить, что проблема именно в коде самого веб-сервера.
И при закрытости исходников, сделать вы ничего не можете.
Вот пример простой ошибки (явно внутри кода самого веб-сервера). В сервлете показывающем возможности по построению графиков есть 4 строки с разными тестовыми данными. 3 строки закомментированны, то есть вы можете раскомментировать одну и посмотреть как такими данными выглядит построенный график. Вот эти строки:
float tab[] = {10042, 10098, 10182, 10154, 10160, 10132, 10160, 10146, 10215, 10134, 10152, 10122, 10116, 10030};
// float tab[] = {18, 80, 18, 54, 60, 32, 60, 46, 15, 34, 52, 22, -16, 100};
// float tab[] = {1, 8, 3, 5, 7, 1, -6, 4, 5, 3, 5, 2, -1, 1};
// float tab[] = {-1.5, .8, .3, .5, .7, .1, .6, .9, .5, .3, .5, .2, .3, .1};
Если мы запустим сервер и посмотрим на выполнения сервлета, все будет хорошо.
А теперь закомментируем первую и раскомментируем последнюю. Сервер упадет. Вот с таким сообщением. Думаю вам, как и мне мало понятно, что же я сделал не так. При том, что это авторский пример.
Самое интересное, чтобы заставить данный пример работать, достаточно заменить любое значение на целочисленное.
Следующим шагом в тестировании было подтверждение невероятной производительности данного сервера. Для тестов я взял apache2-utils и решил протестировать на все тех же стандартных сервлетах которые шли вместе с сервером. Если сказать коротко, в 10 случаях из 10 ab просто выносила сервер примерно после 1000 запросов (не конкурентных!). При использовании конкурентных запросов (ab -n 10000 -с 16) сервер падал уже на ~ 300 запросах. Ну и генерировал "очень полезные" сообщения об ошибках.
После этого я подумал, что возможно проблема в оси, и решил запустить сервер на RHEL6 x86_64. После установки необходимых библиотек, сервер просто не запускался. Не было никакого вывода, который позволил бы понять в чем причина. И только с помощью strace удалось понять, что же происходило. Сервер проверял наличие 32-х битной версии libgcc, и если её не было просто завершал работу.
При этом в попытках поиска решения на официальном форуме, меня поразили ответы автора. Например этот:
I never used CentOS. Use strace to see what is going on.
или этот:
Using Ubuntu 10.4 64-bit on an i5 (macbook air) laptop I could not get a crash while using your 1m test. I tried it many times, using csp/hello, csp?hello, 100.html, etc.
OMG! Люди предлагающие платить за нормальный саппорт этой поделки 150,000 долларов (поддержка по телефону 24/7/365) не тестируют на чем кроме Ubuntu?! Я понимаю, проблемы тестирования например на каких-то древних версиях редких ОС или проблемы при использовании Itanium. Но не возможность просто протестировать на системе образ которой публично доступен и его можно установить на простую виртуальную машину, это выше моего понимания.
При этом на RHEL были все те же ошибки, что и раньше на Ubuntu.
Я решил, что стоит узнать у автора, в чем же причина проблем. Потратив примерно час, я написал большой пост на форуме, с описанием всех сделанных мной действий и найденных проблем, а так же вывод самого сервера на момент сбоев.
Мой пост прожил всего 12 часов, и был удален автором, со словами, что это дубликат и ссылкой на пост, где говориться, что все проблемы в ab и в настоящих интернетах такого не будет, что крайне странно, так как на странице официального сайта, производительность предлагается мерить именно apache2-utils - http://gwan.ch/faq#benchmarks.
Ладно, вернемся от тестов и посмотрим на данное ПО поближе.
У сервера нет настроек. То есть что-то изменить, указать пути или еще что-то вы не можете. Сервер будет работать именно из той директории куда вы его распаковали. При этом придумана крайне хитрожопая схема настройки хостов (вот до чего доводит экономия на конфигах). Дебаг режима в сервере нет, вы всегда будете получать минимальный вывод о проблемах. Все логирование - только вашими силами, то есть в лог попадет только та информация, что вы будете выводить в ваших сервлетах сами, никакие ошибки сервера не логируются.
Так же есть проблемы с потреблением памяти, так как в данном сервере используются не воркеры с очередями как в nginx, а мастер просто забирает необходимое ему количество памяти под каждый запрос (скриншот взят из очень хорошего поста про сравнение веб-серверов):
Теперь несколько ложек меда в данной бочке меда. Очень хорошее API (но иногда не продуманное до конца), писать сервлеты и читать довольно удобно, сразу понимаешь , что происходит. Автор отвечает почти на все посты на форуме, то есть в любом случае, хоть какую-то информацию вы получите, а не просто ваш пост умрет в одиночестве.
На мой взгляд - Gwan совсем не годится для продакшена и причин для этого много: слабая поддержка разных дистрибутивов, не реальные цены на саппорт , сложность настройки и полное отсутствие возможности дебага.
P.S. А еще у автора ЧСВ огромное.
