One thing about WebSockets is that you need a lot of resources on the client's side to generate high enough load for the server to actually eat up all the CPU resources.

There are several challenges you have to overcome because the WebSockets protocol is more CPU demanding on the client's side than on the server's side. At the same time you need a lot of RAM to store information about open connections if you have millions of them.

I've been lucky enough to get a couple of new servers for a limited period of time at my disposal for the hardware "burnout" tests. So I decided to use my Lua Application Server — LAppS to do both jobs: test the hardware and perform the LAppS high load tests.

На написание данной статьи меня подвигли комментарии к статье "Как правильно и неправильно спать".

Речь в данной статье пойдёт о разработке многопоточных приложений, применимости lock-free к некоторым кейсам возникшим в процессе работы над LAppS, о функции nanosleep и насилии над планировщиком задач.

NB: Всё обсуждаемое касается разработки на C++ под Linux, но может быть применимо ко всем POSIX.1-2008 совместимым системaм (с оглядкой на конкретную реализацию).

Вобщем всё довольно сумбурно, надеюсь ход мысли в изложении будет понятен. Если интересно то прошу под кат.

Для тех кто не в курсе: LAppS — Lua Application Server, это почти как nginx или apache, но только для WebSocket протокола, вместо HTTP.

HTTP в нём поддерживается только на уровне Upgrade запроса.

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

Самое главное, LAppS по производительности WebSocket стека, превзошёл библиотеку uWebSockets, которая позиционируется как самая быстрая WebSocket имплементация.

Заинтересованных прошу под кат.

Это не про настоящих лапландцев (с одной 'п'). Это про сервер приложений для микросервисов LAppS.

Если интересно то прошу под кат.

Предыстория

20-го декабря прошлого года я ушёл в отпуск, на целых 2 недели. Чем заняться в отпуске? Правильно, — кодом. Кодом, которым некогда заниматься в рабочее время. Последние несколько лет мне кодить приходилось очень мало. Руки стосковались. Какой код пишут в отпуске? Не знаю как вы, а я пишу велосипеды. Зачем? Причин может быть много, но основная, — мне интересно. Я люблю C++ и Lua. Я ещё и bash и awk люблю. Не закидывайте камнями, это личное, так получилось. JavaScript я не очень люблю (хотя последние 2 года если что-то и кодил то на JS), и это тоже личное.

Январь 2016 изменил мир.

Мировые фондовые биржи в кризисе. Hефть дешевеет. Kомпании по добыче сланцевой нефти на грани банкротства. Pазоряются майнинговые компании с 99-ти летней историей, национальные валюты государств привязанных к USD либо инфлируют с неимоверной скоростью (не будем показывать пальцем), либо удерживаются от инфляции титаническими усилиями и валютными резервами в триллион долларов США. Италия станет второй Грецией?



Не всё потеряно!

Недавняя серия статей («Памятка евангелиста PostgreSQL: критикуем MySQL грамотно» 1,2,3) зацепила за живое.

Так получилось, что моя команда унаследовала, истеорически сложившуюся систему, с 300+ объектами, где одним из ключевых компонентов системы выступает именно MySQL. На некоторых объектах также используется репликация. ПО использующее MySQL от стороннего разработчика.

Так как я довольно давно использую ZFS (ещё со времён OpenSolaris), и очень доволен данной ФС в Linux, несмотря на её «неправославную» лицензию, то естественно прочитал свежую статью об установке данной ФС на CentOS.

Заметив в руководстве к свершению подвига несколько ошибок, решил не пройти мимо, как я это делаю обычно. К сожалению, в комментариях отвечать не могу, по совершенно очевидной причине.

Работа над ошибками, и некоторые полезные советы под катом.