Регистрация | Войти
Lisp — программируемый язык программирования
Scheme web
power - 14.04.2010 19:18, Сообщений - 24
Всем привет.
Скажите, использует здесь кто-нибудь Схему в веб-программировании?
Если да - расскажите, пожалуйста, что используете, как, и для чего.
Спасибо :)
[#]
да.
к сажалению досталось
на поддержку.
SISC это scheme поверх Java.
сайт выдерживает ~50 - 80 тысяч
пользователей в день.
Поддержка это просто ужас.
Поэтому собираюсь перевести сайт
либо на чистую яву(spring mvc framework),
либо на Common Lisp(присматриваюсь к restas)
h1t - 16.04.2010 16:05
[#]
> либо на Common Lisp(присматриваюсь к restas)

Хорошая мысль! ;)
archimag - 16.04.2010 18:21
[#]
на SBCL web сервера нормального нет.

3 года назад смотрел на hunchentoot
и мне он не понравился. (тогда я для себя
поставил крест на web разработку на CL).
вчера посмотрел на его исходники
в вашем git репо:
thread per connection в 2010 году
для всех кроме lispworks? no way...

для себя вижу 2 направления
при использовании CL в web:
1. портирование на SBCL
    antiweb web сервера
    сайт - http://hoytech.com/antiweb/
    git    - http://github.com/hoytech/antiweb
2. Пытаться паразитировать на существующем
    web сервере, который предоставляет
    вменяемое C API(например nginx)
h1t - 19.04.2010 13:15
[#]
> Пытаться паразитировать на существующем
> web сервере, который предоставляет 
> вменяемое C API(например nginx)

Да ну, nginx работает в одном потоке и для прикладных целей может использоваться в основном только в режиме прокси, стандартная схема для PHP это когда nginx работает в связке с Apache+mod_php, т.е. по факту всё равно реальная обработка запросов идёт в разных процессах/потоках.

> портирование на SBCL antiweb web сервера

И что хорошего в antiweb? Я помню ,что ничего особо примечательного в нём не обнаружил.

> thread per connection

У меня есть планы форкнуть hunchentoot и перевести его на iolib, но с этой схемой, "thread per connection", не всё так просто. В данный момент альтернативой может быть только event model, но во-первых, какая либа для работы с базами данных поддерживает такой режим? Что делать с вводом/выводом на файловой системе (линуск не поддерживает асинхронных ввод/вывод для fs)? И, плюс, event model очень не удобна (по сравнению с традиционной схемой разработки) и требует значительно больших усилий со стороны разработчика. У меня есть кое-какие соображения на этот счёт (я даже хочу в блоге на эту тему написать), но "однозначно хорошо" - в настоящий момент почти недостижимый идеал.
archimag - 19.04.2010 13:32
[#]
в antiweb мне нравиться дизайн.
hub + workers означает
что горизонтальная масштабирумость
у нас в кармане.
Плюс run time monitoring - ушел поток
вычислений в бесконечный цикл или
стал потреблять много памяти - сняли
и на его место поставили другой.

с базой данных у меня проще -
хочу отказаться от mysql в пользу
базы key/value(моя задача это позволяет)
а у antiweb есть поддержка berkley db

про AIO ничего сказать не могу -
не разбираюсь в этом вопросе.

а в antiweb не реализована эта event model?



h1t - 19.04.2010 17:02
[#]
> hub + workers означает
> что горизонтальная масштабирумость
> у нас в кармане.

Так не бывает в реальной жизни. Масштабируемость  нельзя получить задорма.

> Плюс run time monitoring - ушел поток
> вычислений в бесконечный цикл или
> стал потреблять много памяти 

Никогда не сталкивался с подобным при программировании на Common Lisp. Сфига бы такое происходило?

> а в antiweb не реализована эта event model?

Они там пишут, что именно так он и работает.


Но это всё ерунда. Любой инструмент для разработки веб-приложений, ИМХО, прежде всего необходимо рассматривать с позиций того, насколько легко с его помощью разрабатывать реальные веб-приложения. Ибо, если разработка - боль, то чтобы терпеть её надо иметь очень веские причины. И как раз в плане удобства и простоты разработки antiweb ничего вменяемого не предлагает, я, по крайней мере, не заметил.
archimag - 19.04.2010 17:19
[#]
раньше к hunchentoot'у на SBCL
были претензии из-за роста
потребляемой памяти. может сейчас
уже пофиксили.
и порта antiweb нет на SBCL
(думаю из-за претензий к gc,
других причин я не вижу).

а прикрутить restas к antiweb
я думаю несложная задача.

т.е грубо говоря мне нужна либо
уверенность в сервере
(например я уверен в надежности
 web сервера Tomcat на java),
 либо нужны инструменты мониторинга.

и если hunchentoot работает как часы
без роста потребляемой памяти во времени,
то я без проблем на него перейду.

h1t - 19.04.2010 18:15
[#]
> раньше к hunchentoot'у на SBCL 
> были претензии из-за роста 
> потребляемой памяти. 

Хм, что за претензии? Ведь сборка мусора и т.п. Hunchentoot не работает с foreign-памятью...

> а прикрутить restas к antiweb
> я думаю несложная задача.

Проглядев http://hoytech.com/antiweb/manual.awp/worker.html - думаю, что просто нереальная :) Я обнаружил следующие способы отдачи контента клиенту:
  • Статические файлы
  • CGI
  • Их (ужасная) технология Anti Webpages
Т.е. никакого способа генерации контента с помощью непосредственного исполнения кода не видно.

Также, не видно никакой вменяемой расширяемой системы диспетчеризации запросов (совершенно необходимой для RESTAS).

И вообще, впечатления от просмотра этого дела - самые ужасные, если вы хотите испугаться веб-программиста - покажите ему Antiweb :)

> если hunchentoot работает как часы
> без роста потребляемой памяти во времени

Ну, данный сайт работает без перезагрузки уже пару месяцев и вроде ничего :) На самом деле, вопросы могу быть по управлению памятью к SBCL (слишком много есть виртуальной, например), но не к hunchentoot.

P.S. Пока писал этот пост смотрел на соседнем мониторе вывод top на этом сайте: потребление памяти (RES) колебалось от 160 до 180 Mb (то увеличиться, то сборка мусора пройдёт). VIRT - 651 Mb, не колебалась (вообще, размер виртуальной обычно постепенно растёт до определённого размера и далее практически не меняется).
archimag - 19.04.2010 19:18
[#]
А, я понял, что такое Antiweb:

        Antiweb was created for admins, by admins. 

Ну т.е. это интсрумент не для веб-программистов, а для админов...
archimag - 19.04.2010 19:35
[#]
не согласен по всем пунктам
критики antiweb.
ладно попробую портировать
antiweb на sbcl.
тогда продолжим обсуждение.
h1t - 20.04.2010 09:31
[#]
>SISC это scheme поверх Java.
>Поддержка это просто ужас.

Из-за чего ужас, если не секрет?
Jax - 20.04.2010 10:10
[#]
в 2006 встал выбор:
 1. взять проверенный временем
    сервер(Tomcat) и написанную на коленке
   версию лиспа
2. написанный на коленке веб сервер(Hunchentoot)
    и проверенный временем лисп

выбрали первый пункт.
в результате:
1. нет IDE
2.  нет возможности подключиться
     к REPL на удаленном сервере
3. ВСЕ ошибки обнаруживаются
    только в runtime. Вызвали функцию
    о трех аргументах с двумя аргументами
    и об ошибке узнаете только при вызове.
4. нет модулей.
5. macroexpand выдает кучу мусора
    так что про макросы лучше забыть
6. веб фреймворк на этом SISC - sisc web
    основан на continueation'ах, что усложняет
    отладку

из плюсов:
1. все же это лисп
2. не требуется перезагрузка сервера

т.е если выбирать между SISC и чистой явой
то однозначно ява:
любой сервлет контейнер + JSP + Spring MVC + Spring + Hibernate
и все работает как часы
h1t - 20.04.2010 11:19
[#]
> любой сервлет контейнер + JSP + Spring MVC + Spring + Hibernate
> и все работает как часы

Громоздкие технологии, время от времени нарушающие принципы проектирование. Создавались под влиянием маркетинговых планов.

"Работает как часы" разве что у менеджеров во сне.
LinkFly - 20.04.2010 12:34
[#]
хм, приведите примеры
негромоздких технологий
подобного качества
h1t - 20.04.2010 14:51
[#]
> хм, приведите примеры
> негромоздких технологий
> подобного качества

Тема "качества" не раскрыта. Что такое "подобное качество"? Возможность разработки "промышленных приложений корпоративного уровня" гы?
archimag - 20.04.2010 15:06
[#]
Раз возникла такая тема тут.

>> У меня есть планы форкнуть hunchentoot и перевести его на iolib, но с этой схемой, "thread per connection", не всё так просто.

А я уже форкнул и скоро собираюсь добавить пару бакендов (один почти готов), глядишь он станет немного (а может и на порядок, пока не знаю) производительней :)

Насчёт возможных моделей:

BOT - один блокирующийся поток, просто в качестве упражнения.
SMT - simple multi threading тот самый "thread per connection".
LW(n) - это один поток прослушивающий сокет и n рабочих потоков (по количеству ядер) с очередями epoll.
LF(n,m) - много слушателей и много рабочих - как в HTTP-DOHC

>> Что делать с вводом/выводом на файловой системе (линуск не поддерживает асинхронных ввод/вывод для fs)?

Есть POSIX AIO, и в Linux он поддерживается (почти полностью). Насчёт биндингов для этого дела - я в iolib их добавил, но пока не залил, т.к. там не всё гладко - больно в Linux-е запутанные структуры используются.
treep - 20.04.2010 15:35
[#]
Что пока есть
treep - 20.04.2010 15:37
[#]
to treep: 

Форк я, конечно, видел (github их показывает), но пока не вникал. Но не ты не предоставли никакой концепции ;), так что не совсем понятно куда ты хочешь двигаться. Всё собираюсь, может сегодня если вырву время, написать своё виденье развития hunchentoot, а также смежной postmodern.
archimag - 20.04.2010 16:00
[#]
Я пока что-то выпилил и что-то распилил, чтобы было удобнее делать бакенды. Те модели которые я перечисли, это ведь и есть хорошо известные концепции :) Плюс можно будет сделать поддержку твоих routes на ряду с url-rewrite. В общем в README написано (правда мой английский это ....)

В джаббере ты писал о том что евентовая модель - плохо, я это не совсем понял, - epoll это ведь и есть евентовая модель (?)
Ещё было что-то про базы данных, тоже интересно было бы послушать что там такое.
treep - 20.04.2010 16:12
[#]
> Те модели которые я перечисли, это ведь и есть хорошо известные концепции :)

Поверхностные ;) Скажем так - таким простым образом существенных преимуществ не добиться.

> В джаббере ты писал о том что евентовая модель - плохо, я это не совсем понял, - epoll это ведь и есть евентовая модель

В общем, постараюсь сегодня написать свои соображения.
archimag - 20.04.2010 16:25
[#]
>> В общем, постараюсь сегодня написать свои соображения.

Можно тогда попросить привести там какой нибудь простенький пример (или модель) веб-приложения обращающегося к базе данных - чтобы делать тесты, ну и вообще понять в чём суть проблемы.
treep - 20.04.2010 16:35
[#]
> Можно тогда попросить привести там какой нибудь простенький пример (или модель) веб-приложения 
> обращающегося к базе данных - чтобы делать тесты, ну и вообще понять в чём суть проблемы.

Суть проблемы в том, что существующие библиотеки для работы с базами работают в синхронном режиме, а значит, пока обработчик будет ждать ответа от базы - он ничего полезного делать не будет. Если ограничивать колличество потоков (nginx, например, в одном работает), то значит реально катастрофически уменьшать производительность. По этой причине nginx то и использую в основном как front-end к апачу (т.п. в режиме прокси). 
archimag - 20.04.2010 17:04
[#]
to treep:

Вот, написал кое что: http://archimag-dev.blogspot.com/2010/04/blog-post.html
archimag - 21.04.2010 18:02
[#]
Буду потом ещё раз читать ))

http://www.ibm.com/developerworks/linux/library/l-async - там хорошая табличка есть, - в каком из смыслов асинхронность? Или как концепция - возможность потока "отдохнуть", перейти к другим клиентам, пока что-то другое обрабатывается? Но как этого добиваться?

А так, со всем согласен - как потоко-на-соединение, так и обработка очереди - имеют свои недостатки. А вот промежуточных моделей предлагалось довольно много (LF, LAIO, ещё, наверно, что-то), и все довольно хитрые.

Вобщем есть фич-лист с точки зрения веб-разработчика, который использует интерфейс (чтобы статика, большая нагрузка, динамика, БД)...
И список фич с точки зрения разработчика сервера (соответственно : sendfile, epoll, aio, решения относительно локинга).

Как их сочетать это ещё нужно думать, я пока склоняюсь просто поупражняться на простых примерах - тот же титуриал для iolib перелопатить.
treep - 21.04.2010 18:49
@2009-2013 lisper.ru