Предыстория
Есть сайт на Laravel с посещаемостью real-time в 700-1000 человек. Ранее сайт использовал чат стороннего разработчика. Он использовал WebSockets.
Всё было прекрасно, пока в один прекрасный момент разработчик чата отказался его поддерживать в связи с высокой нагрузкой. С этого момента начались поиски альтернативных чат-систем…
Выбор технологии
Многие скажут, что сейчас уже никто не использует старые браузеры типа Опера12 или ИЕ8, однако таких людей пока еще довольно таки много, поэтому решено было выбрать именно Long Polling.
Изначально сайт был размещен на Shared hosting, из-за чего был огромный ряд ограничений. Тем не менее, справлялся с нагрузкой. Это радовало. И единственной возможной реализацией чата был long polling на PHP.
Реализация
От слов к делу
Принцип понятен и прост. Аяксом посылается запрос на сервер, который считывает сообщения. Длительность запроса, а точнее ответ от сервера, зависит от того, добавил ли кто-то сообщение. То есть, после запроса запускается цикл, который проверяет, нет ли новых сообщений, и если есть новое сообщение — цикл прерывается, возвращается ответ с новым сообщением. После получения ответа запрос повторяется. И так далее.
Реализовать такую штуку на PHP проще не куда. Я потратил на реализацию в сумме около 3х часов своей жизни.
Проблемы
Тем не менее, оставил его в стадии MVP (Minimum viable product). И, как оказалось, не зря. При теситровании функционала на продакшн сайт просто падал. Оперативка заполнялась в течение 1-2 минут и гасила сервер.
Подумав немного, я решил, что дело в сервере. И спустя некоторое время сайт был перенесен на VPS. Скажу сразу, что конфигурация слабенькая, и оперативки всего 1Гб. Тем не менее, на чат держался 3-4минуты. Уже лучше.
В итоге, после длительных раскопок интернета я понял, что писать чат на PHP — бессмысленно, если нагрузка на него будет больше, чем 10 человек.
Осталось 2 варианта:
- Ставить nodeJS и писать чат на веб-сокетах
- Писать сервис на чем-то другом
И как вы думаете, что я выбрал? Конечно же второй вариант, иначе бы не писал эту статью.
Поскольку C++C реализаций серверных приложений не так уж много, тем более кросс-платформенных, и тем более, что я не силен в Сях, я выбрал Lazarus. Хорошо, что у него есть такой компонент как FPHTTPServer и пример реализации приложения.
Оговорюсь еще о том, что у меня нет под рукой Linux. Все приложения я делаю на винде. Я просто был уверен что перекомпилировать приложение на другой системе — это раз плюнуть. Ведь так же гласит девиз! «Write once — compile everywhere!». Впрочем, мне это удавалось, когда на моем ноуте было 2 системы (win7 + linux mint).
Скомпилировав приложение на win, я проверил функцонал локально. Все работало как часы. Тем не менее, это был простой exe-шник и хотелось что-то больше — написать нормальный сервис типа apache. Lazarus — это вам не Delphi, хоть и очень похож. Во-первых он бесплатный, что автоматически вызывает подозрение относительно качества продукта. А во-вторых,… впрочем как и в-третьих и еще н-ное количество — все неудобства связаны с этим. Большинство вопросов на форуме лазаруса так и остаются без ответа. Это очень печально. Так же как и отладка приложения с выскакивающей ошибкой типа «uncatchable error». Но, к счастью по окончанию недельного срока — я завершил аналог того функционала который был написан на PHP за 3 часа.
Довольный как слон, я решил скомпилить приложение на линуксе. Залогинившись под root на сервер и выполнив команду apt-get-install lazarus — я быстро поставил лазаря, скопировал исходники и, с помощью отрытых ранее в интернете команд lazbuild -r project.lpi, скомпилировал приложение. Это был единственный, поистине, самый удачный и быстрый этап.
Проверив работу чата уже на реальной нагрузке, я понял, что моя идея была оправдана. Чат работал, нагрузка на сервер увеличилась не намного. Это радовало. Теперь я мог вернуться на винду и продолжить работу над улучшенной версией — сервис (daemon). Как и следовало ожидать — на винде все получилось, хоть и с небольшой задержкой по времени.
На линуксе проект не скомпилился. При компиляции выдавалась ошибка о том, что не найден юнит Interfaces. Это было очень странно. На форуме лазаря внятного ответа так и не появилось. Многие лишь писали о том, что при переустановке все заработало. Однако переустановка не помогала. В конце-концов я понял, что моя версия лазаря отличается от той, которая стоит на линуксе. Обновить репозиторий не получилось. Точнее репозиторий обновился, а вот лазарь так и остался прежней версии.
Тогда я попытался скачать установочный пакет с помощью wget. В результате вылезла ошибка 177 (точный номер уже не помню). После очередного выплеска эмоций я понял, что проблема в каком-то символе в ссылке. Я перелил установочный пакет на MS OneDrive и создал короткую ссылку, после чего успешно скачал файл.
Далее я удалил старый лазарус и поставил новую версию. И как вы думаете, что сообщил компилятор? Конечно же! Непонятные ошибки!
Опираясь на прошлый горький опыт с поиском ответов в интернете я начал изучать конфиги лазаря. Проблема оказалась проста — при установке лазарус почему-то не создал новую папку с конфигами. Папочка осталась от предыдущей версии, хотя я удалял старый лазарус с помощью apt-get remove --purge. Ну что ж, я забекапил старые конфиги, удалил папку и снова попытался перекомпилить Lazarus IDE. Магическим образом, после этого папка с конфигами создалась и я смог наконец скомпилировать даймон для линукс.
Победа! Или нет?
Сервисное приложение успешно скомпилировалось, но как же его теперь запустить?
Как и следовало ожидать — простой скрипт для создания записи в service start… не сработал. Более того, я опять же нашел посты на форуме с моей проблемой без ответа.
Поковыряв еще часик интернет, я нашел как можно запустить сервис с помощью start-stop-daemon. В итоге я понял, что код скрипта запуска, который выложили в примерах лазаруса — работает, но только если запускать его из терминала. В противном случае он выдавал что-то типа «не найден какой-то файл».
Финиш
Проблему с запускомостановкой даймона через service я так и не решил. Тем не менее, остался доволен проделанной работой. Тем более, что чат смог выдержать 1000 соединений в течение 4х часов. К сожалению, конфигурация сервера не позволила ему работать дольше. Однако эту проблему я решил с помощью кнопочки «показать чат». В результате нагрузку на чат давали только те пользователи, которым он реально нужен.
Автор: AlexSlipknot
