[Из песочницы] Писать веб-сайты на ассемблере полезно и приятно
Конечно, многие скажут, что это ни-ни и писать для веба нужно только на PHP, ну или на один из модерных языках Питон, Руби, Node.js и т.д.
Но дело в том, что написание сайтов на ассемблере очень полезно, а с подходящими инструментами — легко и приятно.
Вообще-то, это утверждение было лишь гипотезой. Чтобы доказать или отвергнуть ее, этой весной я занялся писать форум на ассемблере.
Раньше у меня уже было веб-приложение на ассемблере — CMS для малого сайта. Только оно работает в режиме «один пишет, многие читают». При том, использует CGI интерфейс и поэтому «многие» читать одновременно тоже не получается.
Техзадание
И так я решил написать веб-приложение, чтобы:
- Было от типа «много читают — много пишут».
- Работало очень быстро и не загружало сервер.
- Использовало очень мало памяти, опять чтобы не загружать сервер.
- Работало на дешевом виртуальном хостинге.
На всех этих условиях отвечает именно веб форум. Поэтому было решено писать именно его. Задание выглядит так:
Написать веб форум, который:
- Использует интерфейс FastCGI, чтобы обслуживать заявки быстрее чем CGI и чтобы не было ограничение на число одновременно исполняющихся процессов на сервере (у моего хостинг плана такое ограничение есть в 60 процессов).
- Использует транзакционную базу данных, чтобы хранить информацию в одном месте и чтобы можно было несколько посетителя писать одновременно.
- Функциональность была достаточна чтобы использовать продукт в реальной жизни для общения потребителей.
- Вид форума было можно полностью менять из конфигурации. Скины — наше все. Да и не каждый может редактировать код на ассемблере.
Кроме FastCGI можно было использовать и SCGI, которой даже выглядит несколько проще для имплементации. Только оказалось, что моя хостинговая компания поддерживает только FastCGI.
Но об этом мне жалеть не пришлось. Оказалось, что несмотря на сложность спецификации, FastCGI очень хорошо подходит для реализации именно на ассемблере. Так что код получился простой и понятный.
Для базы данных была выбрана SQLite. Во первых, я знаю ее очень хорошо и часто использую ее в связке с ассемблером. Во вторых, используя виртуального хостинга, хотелось чтобы все приложение находилось в директориях сайта, включая база данных. В третьих, у SQLite есть возможность «Free text search — FTS», которая работает быстро и придется очень кстати для поиска в форуме.
Но здесь появилась проблема. Форум я решил писать на 32 битном ассемблере для x86, чтобы можно было работать и на 32 и на 64 битных серверов. Но дело в том, что 64 битные серверы, как правило, не предусматривают 32 битных библиотек. Для ассемблера это не важно, но SQLite мне тоже нужна 32 битная, а ей нужна стандартная библиотека C. А вот glibc (GNU C library) нельзя скомпоновать статически.
Но решение нашлось — использовать альтернативную библиотеку C — MUSL у которой есть динамический линкер, которого можно поместить в директорию приложения. Дополнительной плюс является и то, что библиотека очень небольшая.
Реализация интерфейса FastCGI писалась так, чтобы можно было использовать его и в других проектов.
Для разметки постов форума было решено использовать markdown подобная разметка, которая у меня уже была написана для CMS-а.
И так, что в итоге получилось?
Писал я в свободное от работы время. Иногда на работе, иногда дома. Код, конечно открытый. Лицензия распространения: EUPL. Первая версия, сохранена 6-го Марта 2016-го года. Официальная версия 1.0, сохранена 7-го Апреля 2016-го года.
Все это заняло ровно 53 коммита.
Так как ассемблер я знаю, то больше всего затруднения во время работы вызвало незнание веб протоколов. Пришлось читать RFC документы насчет SMTP и FastCGI.
Умения веб дизайнера у меня тоже не выдающиеся, так что получилось так, как получилось. Но так как весь дизайн вынесен в конфигурационных файлов, то заменить его дело простое — нет необходимости менять код движка.
Так же, в начале мне совершенно не было известно ничего насчет XSS атаки и другие аспекты веб безопасности. В конце, все более-менее изъяснилось. Особенно во время тестов, которые некоторые товарищи из болгарского форума проводили. В результате, появилась защита от боттов, а также тема в которой были 15000 постов.
Приложение получилось очень маленькое. Все файлы в дистрибуции 1.8МБ, от которых 992КБ SQLite и 622КБ MUSL библиотека. Само приложение на ассемблере состоит из одного файла «engine», размером в 68.5КБ (v1.2). Все остальное — темплейты и картинки.
Инсталляция очень простая — архив распаковывается в директорию сайта и настраивается '.httaccess' файл. Ну или 'lighttpd.conf'. Открывается сайт в браузере и создается потребитель-администратор.
Во время исполнения, приложение использует приблизительно 2МБ RAM на сервере, на запущенном процессе. В зависимость от нагрузки, apache сервер может запускать несколько экземпляров процесса.
К сожалению никакие сравнения с других форумов не могу привести, потому что данных насчет потребления памяти популярных форумов не публикуются (ну или я не нашел), но типовое потребление памяти например cpanel, около 20МБ на PHP процесс — примерно в 10 раз больше.
Демо инсталляция форума доступна для посещения и тестов.
Хостинг план, на котором находится демо, (самый дешевой которой я смог нанять), виртуальный (shared). Ограничения таковы (сообразно спецификацию):
- Одноядерное CPU
- 1GB RAM
- 30 минут процессорное время в сутки.
- Максимальное количество работающих процессов — 60.
Slashdot эффект тест.
В Августе, совершенно случайно удалось протестировать систему на нагрузке в реальном режиме. Некто (так и не понял кто) опубликовал в Твиттер ссылку на хранилище кода. Сразу несколько десятков перепостили ссылку, а потом опубликовали ее и в reddit и наверное в других социальных сетях.
К большому моему сожалению, ссылка была на хранилище кода, которое работает на CGI и совершенно не может держать нагрузки.
В течение сутки форум посетили несколько тысяч посетителей — около 8000 на хранилище кода, которое счастливо падало и вставало (из-за превышения лимита процессов).
Но некоторое количество посетителей (около 3000) все таки попали на форуме и сделали более 30000 заявок.
Форум совершенно не почувствовал нагрузку и все время исправно работал без замедления или потеря заявок. В эти сутки использовано около 7 минут процессорного времени.
Вердикт гипотезы
Я считаю, что всем этим гипотеза сформулирована в начале моего рассказа, была доказана.
Веб программирование на ассемблере возможно, не очень сложно, а результаты получаются весьма хорошие. В добавке, такая работа весьма повышает общая культура разработчика и позволяет ему получит глубокое понимание насчет протоколов Интернет и как все работает на самом деле.
Использование веб программы на ассемблере может сэкономить много денег от хостинга и позволит использовать дешевый виртуальный хостинг там, где другие используют нанятые серверы и другие дорогие решения.
Заключение
Ну, вот и все. Если кому понравилось, используйте на здоровье. Всякие тесты на уязвимость и производительность весьма приветствуются. Новый код и исправления багов принимаются. Новые хорошие скины тоже весьма нужны.
И в конце некоторые ссылки:
» Хранилище кода проекта
» Демо инсталляция
» Как качать и инсталлировать
» Как зарегистрироваться без почты
Комментарии (11)
stas404
2 января 2017 в 21:14
+1↑
↓
Блин, неужели так трудно проверить статью перед публикацией или попросить об этом кого-нибудь, чтобы потом не кровоточило из глаз при чтении? Это уже за гранью. Безотносительно к содержанию.
kAIST
2 января 2017 в 21:25
+2↑
↓
Насколько я понял, русский для автора не родной язык.-
stas404
2 января 2017 в 21:43
0↑
↓
При всем понимании.
-
kAIST
2 января 2017 в 21:36
+4↑
↓
С одной стороны интересно, эдакая потивоположность современным языкам с тонной фреймворков и детяском уровней абстракций.
Но с другой стороны, плюсов никаких. С точки зрения производительности, разницы особо думаю не будет — 99% у тебя займёт шаблонизатор и база данных, или 95%.2 января 2017 в 22:44
0↑
↓
Без тестов я не стал бы утверждать что разницы не будет. Беда в том, что непонятно, с чем сравнивать — в зависимости от движка форума результат будет разным. Но я бы напротив, ожидал ускорения на порядок.Беда в другом. Никому не нужен хороший и оптимизированный софт. Стоит взглянуть на любой продукт крупных компаний — это становится ясно. Важна скорость и стоимость разработки. Ассемблер при всей любви к нему не может похвастаться хорошими показателями в этих категориях. Увы, так устроено наше общество.
Randl
2 января 2017 в 21:38
+2↑
↓
Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба ассемблер можно превратить в троллейбус язык веб-программирования… Но зачем?
2 января 2017 в 22:01 (комментарий был изменён)
0↑
↓
Писать веб-сайты на ассемблере полезно и приятно
Жесть
Для базы данных была выбрана SQLite.
Жестокая жесть
Ну, вот и все. Если кому понравилось, используйте на здоровье.
Спасибо, как нибудь в другой раз. В другой жизни.
evgenymarkov
2 января 2017 в 22:10
+3↑
↓
Надо было публиковать это в хаб «Ненормальное программирование» :)2 января 2017 в 22:27
+2↑
↓
> Использование веб программы на ассемблере может сэкономить много денег от хостинга[sarcasm] Хостинг-провайдеры кусают локти и ждут обрушения рынка. [/sarcasm]
Ничего. Левша вон блоху подковал, и тоже не взлетело — бывает.
farcaller
2 января 2017 в 22:45
0↑
↓
Free text search — FTS
Full Text Search же:-)
2 января 2017 в 23:09 (комментарий был изменён)
+1↑
↓
С одной стороны, писать сайт на ассемблере — не-кост-эффективно.С другой — проблема производительности все же есть, не зря акамаи и подобные востребованы. Сам веб — неэффективная технология со стороны клиента, потому все мучаются со стороны сервера.
В ту же копилку — любой SQL также не особо эффективен по отношению к конкретной задаче. Но до определенного предела (SQL кстати, забывают что погрешим), весьма удобен.
А что потом? Ищем оптимальные, или используем подставные планы исполнения, пытаемся как то обмануть абстрактные машины типа sql, jvm и прочие байт код интерпретаторы.
Это тлен, во имя «быстро написать и сдать».
Дальше скупые платят уже нам вдвойне, «за оптимизацию»
Просто бизнес
