Подскажите по современной обстановке. Нужно развернуть сервер с возможность отдачи видео-контента. Планирую генерацию html5 со вставками видео. Hunchentoot актуален в современном вебе? Для генерации html хочу использовать closure-template. Сейчас есть относительно бюджетные хостинги, которые поддерживают sbcl/ccl?  

Это будет сайт маргинала для маргиналов. Зачем тебе пердолится  с генерацией html? Я тут нашел мьсе, который html генерировал с помощью cl-who и js с помощью ещё какой-то шняги. Но зачем? А hunchentoot с его моделью 1 полновесный поток на 1 соединение? Сколько конкурентных соединений он тебе даст? 100? 200? Т.е. о какой-нибудь серьезной нагрузки на свой сайт можешь забыть. Как там делается уеб я не очень знаю, но слышал, что весь html пишется шаблонами, а какие-то места просто исправляются. Никто целиком html не генерирует. Лучше возьми nginx и библиотеку fastcgi под cl, думаю, толку больше будет

Ну и опять же 100 -- это потоков, и то, если повезет. А паралелльно их будет обрабатываться всего ничего. А остальные как себя поведут -- зависит от системы

> Лучше возьми nginx и библиотеку fastcgi под cl, думаю, толку больше будет
ЛОЛ. Я даже готов, в общем случае согласиться с вышесказанным, если бы ты сказал что-нибудь вроде Node.js+Angular это самый пшик и наше всё, а сам JavaScript это по сути "правильный" lisp1 (о котором, на самом деле, и менчал Пол Грэм, когда задумывал Arc) и т.п. Но, каким боком здесь могут помочь ngix и fastcgi?

> Hunchentoot актуален в современном вебе
Вопрос актуальности, на самом деле, очень простой. Вот тут http://blog.quicklisp.org/2016/03/quicklisp-download-stats-for-february.html можно посмотреть, что за весь февраль 2016-го года Hunchentoot был скачан 1053 раза. Не думаю, что с тех пор его популярность сильно возросла. С другой стороны, вот здесь https://www.npmjs.com/package/express можно увидеть, что express (который можно считать базовым веб-фреймворк для Node.js) был скачан за последний (!!!) день 210 719 раз (цифра на момент написания поста). Собственно, это всё, что надо знать про актуальность Hunchentoot в современном веб.
Но, если у вас есть какая-то очень ценная (и тонкая) логика на Common Lisp, которую нельзя так же удобно выразить на JavaScript (а такое возможно), то Hunchentoot может быть очень полезен в том, что бы сделать её (логику) доступной через веб пользователям или другим компонентам системы. 

Главное правильно настроить nginx.
Если не обращаться к БД, а всё держать в памяти, то хунч легко обрабатывает тысячу запросов в секунду в 1 (один) поток. Отдаёшь хтмл-ку скомпилированную из closure-template, в которой ссылка на видео, а само видео отдаётся энжинксом напрямую, как и картинки, жс-файлы и прочая статика. (Кроме closure-template есть какой-то парсер джанговских темплейтов. Также глянь https://habrahabr.ru/post/265589/ )
Про хостинги не слышал, пользовал вдс/впс. При отдаче видео, бюджет определяется объёмом и полосой видеоконтента.

Я тебя правильно понял, что на форуме про лисп я дожен был посоветовать JS? Оки

Под актуальностью я имел в виду возможность реализовать современный сервис, по современным меркам достаточно быстрый и легкий в разработке. 
Спасибо всем за развернутые ответы, я вас понял. Мне нравится вариант с не CL-based сервером, к примеру FastCGI и Clack+Caveman2, но отпугивает что нет документации, а только api-reference... 
Пару лет назад я видел пример с быстрым сервером на лиспе, способным обрабатывать 50к+ обращений. По-моему, кто-то из русского комьюнити написал статью, но сейчас уже не могу найти. 

Спасибо за ссылку, много нового увидел.  Года полтора не трогал лисп, а судя по тексту куча нового появилось. Проект делаю в удовольствие, поэтому хочу писать на этом ЯП. 
>>Про хостинги не слышал, пользовал вдс/впс. При отдаче видео, бюджет определяется объёмом и полосой видеоконтента.


То есть приходишь такой к провайдеру, говоришь, мне нужен канал с возможностью принимать и отдавать 100к запросов с видеоконтентом в секунду, сервер будет у меня дома в холодильнике, а лучше серверная, только запросов может быть и в сотни раз меньше и я хочу платить за реальное количество трафика?)

> Я тебя правильно понял, что на форуме про лисп я дожен был посоветовать JS?
Нет, просто проблема, на которую ты указал (1 полновесный поток на 1 соединение) и связанные с ним проблемы масштабируемости связка ngix+fastcgi никак решить не позволяет. С учётом того, что Hunchentoot обычно и так ставят за nginx, то в противопоставление hunchentoot vs fastcgi я вообще не вижу доводов в пользу fastcgi.

>... сервер будет у меня дома в холодильнике, а лучше серверная, ...
Это юмор такой? Что такое VDS? VPS - что это?, там же "Сравнение VDS/VPS с виртуальным (shared) хостингом".
На хостинге обычно из языков только ПХП, изредка Питон. На вдс - ставишь свою ОС (фря, центос, винда...). Я обычно ставлю стабильный Дебиан, а СБЦЛ устанавливаю из тестовой ветки (обычно последний или предпоследний релиз из www.sbcl.org).
То есть приходишь такой к провайдерузаказчику, узнаёшь минимальное гарантированное количество запросов и минимальную гарантированную ширину канала, а потом идёшь к провайдеру и выбираешь соответствующий тариф.
Пример энжинкс-конфига (svg вместо видео) в соседней теме.

что-то не особо радует быстрый woo... у меня получилось что-то типа такого для nginx:
siege -c 255 -r 100 -b http://127.0.0.1:8081
Transactions: 24498 hits Availability: 96.07 % Elapsed time: 39.09 secs Data transferred: 14.30 MB Response time: 0.07 secs Transaction rate: 626.71 trans/sec Throughput: 0.37 MB/sec Concurrency: 45.52 Successful transactions: 24498 Failed transactions: 1002 Longest transaction: 5.55 Shortest transaction: 0.00то же самое для woo(через proxy в nginx) вообще дало:
Heap exhausted (no more space for allocation). 162430976 bytes available, 268435472 requested.правда woo генерирует на каждый вызов новый шаблон для index.html через (djula:compile-template* (princ-to-string template-path))), а nginx выдает статичную страницу, но как-то не очень радостно. Получается, что woo может примерно 300 простых запросов в секунду на том же железе, где nginx даёт в два раза больше и это, вероятно, не предел? Я не сведущь в вебе - 300 запросов в секунду это много? при учёте, что есть потерянные(с кодом 200)? Сколько у популярных ресурсов? Вот данные для woo, на которых он не убил мой sbcl:
siege -c 100 -r 100 -b http://127.0.0.1:8080 Transactions: 19668 hits Availability: 98.91 % Elapsed time: 73.82 secs Data transferred: 7.32 MB Response time: 0.21 secs Transaction rate: 266.43 trans/sec Throughput: 0.10 MB/sec Concurrency: 55.47 Successful transactions: 19668 Failed transactions: 217 Longest transaction: 26.48 Shortest transaction: 0.00 _________________________________
HUNCHENTOOT просто для сравнения:
siege -c 100 -r 100 -b http://127.0.0.1:8080 siege aborted due to excessive socket failure; you can change the failure threshold in $HOME/.siegerc Transactions: 12478 hits Availability: 92.40 % Elapsed time: 47.71 secs Data transferred: 4.82 MB Response time: 0.21 secs Transaction rate: 261.54 trans/sec Throughput: 0.10 MB/sec Concurrency: 53.76 Successful transactions: 12478 Failed transactions: 1026 Longest transaction: 26.26 Shortest transaction: 0.00 _________________________________Может я что-то не так делаю?
у меня нет заказчика, я сам интересуюсь для своих целей и с вебом никогда дела не имел.

> что-то не особо радует быстрый woo..
Просто выкинь его.  Если интересует асинхронность, то смотри http://wookie.lyonbros.com/.

Хотя я не прав, перепутал, ничего не могу сказать про woo...

> ... wookie...
Пробовал им заменить связку hunchentoot+clws. Соединения постоянно рвались, что полностью нивелировало сокеты.
В итоге выбрал hunchentoot+hunchensocket.

:(

>что-то не особо радует быстрый woo...
не пробовал
>Я не сведущь в вебе - ... 300 запросов в секунду это много? ... Сколько у популярных ресурсов? ...
Зависит от железа. Лет 5 назад в описании хайлоад-архитектур сходились на 500 запросов в секунду на сервер, что для вконтактика, что для мордокниги. Похоже, дальше упиралось в полосу пропускания канала.
Примерно в то же время делал тесты АБ (апач бенчмарк) на Пентиум 200 ММС, 348 ОЗУ, в режиме роутера:
чистый энжинкс ~2200
чистый хунчентут = 169 (запомнил, потому что ровно в 13 раз медленнее)
хунч за энжинксом ~150
подключение рестас на скорость не влияет
сб-фастцги (естественно, за энжинксом) - раза в 3 быстрее хунча (не помню, могу ошибиться)
хунч на ЦЛОС - если найдёшь что-нибудь на структурах, возможно будет побыстрее.
Фукамачи (автор ву) честно предупреждает: "This software is still BETA quality."
В доках вуки встречал совет в продакшене использовать хунчентут (может доработали)
_Обычные_ ЦРМки на пхп/питоне - типичное значение до 10 запросов в секунду (друпал, вордпресс, джумла...). Хорошо оптимизированные - 30-50
>у меня нет заказчика, я сам интересуюсь для своих целей и с вебом никогда дела не имел.
Тогда ищи что-то вроде VDS Разминка "Всего 90р. в месяц". фёствдс - не рекомендация, а просто первый ответ на https://www.google.ru/#newwindow=1&q=vds. Раньше в Германии были хорошие тарифы, как сейчас в связи с курсом евро - не знаю.
Смысл энжинкса в том, что он держит огромное количество соединений, встречал ссылку на 2500000 (два с половиной миллиона), не плодя массу потоков. То есть, по очередному запросу лисп/си/перл/пхп за пару микросекунд сгенерили динамический контент, пихнули ответ в энжинкс, а он будет час отдавать этот ответ по меееедленному каналу. А пока идёт отдача, лисп/си/перл/пхп может обработать в том же потоке ещё тыщу запросов. Ну а статику, в том числе и видео, вообще надо отдавать напрямую из енжинкса, не тревожа лисп/си/перл/пхп. Более того, если ответ огромный и не помещается сразу в енжинкс, есть смысл создать в ОЗУ виртуальный диск, записать ответ в файл на этом диске, и отдать энжинксу этот файл в качестве ответа.

по поводу статики я уже понял, что её не просто отдавать через nginx надо, а её просто невозможно отдавать через woo без ковыряний в его внутренностях, потому что файлы не успевают закрываться и довольно быстро доходит до предела открытых файлов на юзера. Или держать всё в памяти лиспа. Разработчики nginх, видимо, этому уделили больше внимания чем разработчики woo. Хотя в целом, сейчас вырисовывается вполне радужная картина по связке woo+nginx, но надо ещё потестить.

> Хотя в целом, сейчас вырисовывается вполне радужная картина по связке woo+nginx
Что бы получить быстрое решение, оно должно быть асинхронным (как nginx), но в большинство практических приложений упирается в то, что для этого нужен асинхронный движок БД и т.п., т.е. вообще всё асинхронное, иначе проще использовать Hunchentoot.

"Большинство практических приложений" - обычные веб-морды к БД и лисп там нафиг не нужен, разве что очень хочется. Асинхронный движок БД возможен только на распределённой БД, т.к. на одном компе всё упрётся в скорость шуршания головками винта, т.е. максимум два потока.
А вот высоконагруженный сервис и/или критичный ко времени ответа - тут ву на порядок быстрее хунча. Правда в этом случае я бы поставил ву _не_ЗА_ энжинкс, а рядом с ним, возможно на соседний ИП, т.к. энжинкс замедлит ву в полтора-два раза. Например:
pseudo-cat.ru            - ву
static.pseudo-cat.ru - энжинкс

Не понял ваших рассуждений. Если речь идёт о селектах, то многие СУБД позволяют высокую степень параллельности и даже асинхронности (открываешь курсор и асинхронно извлекаешь данные). Головки винта не при деле, база может полностью поместиться в кеш, а для транзакций на запись есть кеширование записи (другой вопрос, насколько это приемлемо по надёжности). 

> Не понял ваших рассуждений. Если речь идёт о селектах,
Берёшь, например, Postmodern (хорошая библиотека) и делаешь select или ещё какую операцию и postmodern вернёт тебе управление только тогда, когда операция будет выполнена и будут полностью завершены все сопутствующие операции ввода/вывода. На практике это означает, что в одном потоке ты можешь обрабатывать только один запрос от браузера. А если ты возмёшь асинхронный веб-сервер (например, wookie) и postmodern то, фактически, ты получишь возможность одновременной обработки не более одного запроса от клиента. Т.е. для асинхронный веб-сервер требует асинхронной же библиотеки для работы с БД. Условно, node.js может в одном потоке обрабатывать параллельно тысячу запросов именно потому, что практически все библиотеки используют неблокирующий ввод/вывод.

>Т.е. для асинхронный веб-сервер требует асинхронной же библиотеки для работы с БД.
В БД (если не брать какие-нибудь специально продуманные вырожденные случаи) формирование ответа происходит гораздо быстрее чем выборка данных с носителя. Если данные уже в ОЗУ, БД сразу _без_ожидания_ формирует ответ и нахрена здесь асинхронность? Если данные надо выбирать, то единственное возможное распараллеливание - после завершения выборки с диска сначала послать на выборку следующий запрос, а затем уже формировать ответ для только что выбранных данных. То есть параллелится, и то частично, только два запроса.
Есть вариант когда кто-то из ОС/ФС/драйвер_винта позволяет менять порядок запросов на чтение физических секторов. Например, головка на первых дорожках, приходит запрос на чтение с последних дорожек, а затем запрос на чтение со средних дорожек. Умная ФС, понимая как будет двигаться головка поменяет порядок чтения. Но даже в этом случае таких запросов в очереди будет очень малое количество.
У постгреса по умолчанию ограничения в 100 сессий подключения к базе данных. Создай два (ну ладно, четыре) потока в каждом используй своё соединение - вот и вся асинхронность. Всё свыше будет гарантированно простаивать в очереди или постгреса, или веб-сервера - выбирай.
2pseudo-cat
Почитай Масштабируемая конфигурация nginx

> хунчентут
Хунхентот, спасибо.