Изобретаем технологию: опыт соединения нескольких open-source проектов

[garex]

Да уж…

Весьма интересно, как это оно так в неожиданном свете.

Вот теперь интересно как оно под нагрузками и все такое.

[Krovosos]

Производительность сложно оценивать в целом поскольку система состоит из нескольких кусков, каждый из которых вносит свою задержку: обмен сообщениями, работа с БД, исполнение js-кода, разбор HTTP, маршрутизация вызовов и т.п.

Видимо в какой-то момент я займусь профилированием и поиском узких мест, но не сейчас.

Пока на двухядерном Dual-Core 1.86 GHz сервер успевает обработать где-то 300 HTTP запросов в секунду.

Запрос включает в себя выборку трех записей из таблицы в базе, их конкатенацию в HTML, добавление даты через new Date(). Запросы лупятся из Хрома с помощью AJAX GET с паузой в 1 ms.

[micktu]

Вы, что ли, лупите ApacheBench'ем. на яваскриптовый тайминг полагаться нельзя.

[micktu]

Я имею в виду, что скорее всего на самом деле задержки намного больше, чем 1мсек.

И, кажется, у вас узкое место в БД. теоретически должно быть в 5-10 раз быстрее.

[savant]

«Эта система пришла на смену CSV»
CSV->CVS

[Krovosos]

ок, исправил

[nayjest]

Очень интересно, что же выйдет

[Krovosos]

Собственно, уже вышло :) Интересно возможно ли на этом всем создать серьезное приложение и является ли эта хрень самодостаточной! ;-)

[max7]

Вы меня заинтересовали. Стоит ли ожидать более детального изложения проекта? Возможно HOWTO?

[Krovosos]

Вряд ли всех заинтересуют детали. Ежели Вас что-то конкретное интересует, то могу ответить.

[foff4ik]

да, хотелось бы узнать что за проект в итоге получился то?

[bsdemon]

«В свое время я занимался довольно плотно веб-программированием и от языка JavaScript у меня осталось очень приятное впечатление. Это очень гибкий и легко расширяемый язык, но отчего-то его не используют в качестве серверного решения.»

Используют — Aptana Jaxer, Persevere, CouchDB и ещё где-то пробегал mod_v8 для Apache ;)

[Krovosos]

Угу, имелось в виду «обычно» не используют, предпочитая ruby, python и т.д.

[sunnybear]

проверьте производительность в IE — будете (не)приятно удивлены :)

[Krovosos]

самый быстрый — Хром, остальные (Opera, IO, Firefox) по разному отстают, некоторые в 2 раза

[Vadi2]

Какой же ето опыт? Весь опен-соурс мир так работает :)

(И не только — уже и линукс используют в разный девайсах, микрософт использует jquery...)

[snusmumrik]

Вы статью прочитали?

[Vadi2]

Да, всю. Вот только линк на получившегося проекта не вижу…

[snusmumrik]

Весь опен-сорс мир видит преимущества JS на сервере? Есть jaxer, но он раскрыл еще не всю мощь JS на сервере, кроме того jaxer не больно-то и популярен.
Весь опенсорс мир использует абстракцию обмена событиями? Используют, не не так повально, как это того заслуживает. То есть я даже не могу назвать конкретных достаточно стабильных проектов, которые бы реализовывали это хотя бы на базе jabber. Подскажете, кстати?
Ну и разве многие так огульно используют SQL базы данных? Я совсем не фанат SQL-баз, но я представляю, как с описываемой автором системой приятно работать тем, кому нравятся реляционные БД.

А проект у автора, вероятно, закрытый. Но я надеюсь, что рано или поздно он свой сервер JS-приложений с описанным транспортом покажет публике.

[koct9i]

неспеша делаю похожее для embedded, но на C вместо С++, lua вместо javascript и ядро самопальное.

[iv_s]

Собрал себе V8. Там есть возможность читать с stdin?
Аргументы скрипту тоже не передаются, хотя в их багтреккере есть исью что должен быть массив arguments.
У меня почему-то ругается…
В мозиловском SpiderMonkey и readline и arguments есть. Здесь нетак?

[Krovosos]

Нет.

У меня массив arguments передается. С ним только не работает for-in цикл, но arguments.length и arguments[i] работают.

[iv_s]

>встроенный веб-сервер(yaws.hyber.org) держит 80 000 одновременных подключений на стандартной конфигурации
Даа, Erlang — это сила!:)

[Krovosos]

если я правильно понял CouchDB хранит XML и не вполне реляционна и все-таки больше похожа на распределенную базу данных

здесь все-таки немного другая задумка — здесь реляционная база, причем везде — включая клиента, причем распределенность не является обязательной

erlang конечно похож, у него я один термин даже украл :)

[bsdemon]

нет хранит он json, они начинали с xml, но потом решили остановиться на json

[Octane]

Были и огорчения, самым значительным из которых наверное следует считать ограничение V8, которые фактически не является мульти-тредовым.

Как бы JavaScript всегда был однопоточным.

[Krovosos]

Нет

[Alik_Kirillovich]

Как бы JavaScript всегда был однопоточным.

JavaScript сам по себе не является ни однопоточным, ни много поточным.

Все зависит от реализации.

Браузерная реализация JavaScript, действительно, является однопоточной.

Но, например, реализация, на платформе Mozilla Rhino позволяет создавать многопоточность, использую стандартную работу с потоками в JVM.

Вот пример:

//Создаем объект с функцией
obj = { run: function() { print ('Hello, world!'); } }

//Создаем Java-поток
t = new java.lang.Thread(new java.lang.Runnable(obj))

//Запускаем функцию в потоке
t.start()

[markshevchenko]

А как Вы SQLite в клиенте используете? Это же сишная библиотека, а у Вас клиентский код в браузере запускается, где ничего кроме JavaScript.

Что я недопонял?

[Krovosos]

см. Google Gears: code.google.com/intl/ru-RU/apis/gears/api_database.html

[markshevchenko]

Интересно. Лично вряд ли буду пользоваться, но идея понравилась. Смело.

[Alik_Kirillovich]

Здорово, что Вы используете JavaScript на сервере.

В нашем проекте мы тоже используем серверный JavaScript на платформе Mozilla Rhino.

Mozilla Rhino компилирует JavaScript в байт-код JVM. Благодаря этому, наш серверный JavaScript не становится «вещью в себе», а может использовать все обилие библиотек и наработок мира Java.

Хотелось бы узнать Ваши впечатления от JS-движка V8 и сравнить его с Rhino.

См. мою статью: «Совершенный Ajax» – новый подход к построению настоящих клиент-серверных web-приложений

[Krovosos]

Любопытно! Если позволите, я сразу отпишу что приходит в голову.

Я не вижу резона отказываться от возможности получать CSS, HTML, клиентские скрипты с веб-сервера.
Это по сути есть централизованное хранение, иначе придется их распространять клиентам каким-то другим способом.

«Несмотря на недооцененность многими разработчиками, JavaScript — удивительно мощный, гибкий и красивый язык» — абсолютно согласен!

«прототипно-ориентированная парадигма JavaScript позволяет гораздо более гибко работать с базой данных через ORM» вот мне кажется, что существует какое-то более красивое решение, чем то что обычно делается в ORM. Надо подумать. Я не уверен, что вообще нужна какая-то объектная прослойка для работы с реляционными данными…

Далее что касается контролов и прочего. Ведь это не обязательно вносить в ядро. Можно написать на javascript все необходимое.

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

[snusmumrik]

Это очень круто. И хотя я совсем не согласен с выбором SQL как наиболее удобного доступа к данным, да и «клиент — браузер» на сегодняшний день довольно шаткий выбор (вообще говоря, а не в конкретном случае), видно, что ваша система четкая и жизнеспособная. JS на сервере это прекрасно, как и где-либо еще.

[snusmumrik]

Кстати, а почему STLplus, а не boost? boost, казалось бы, более стабилен, с огромным сообществом…

[Krovosos]

Спасибо, boost очень большой и всеобъемлющий. Чтобы его серьезно использовать, надо его серьезно изучать. Это лично мое мнение, конечно…

[snusmumrik]

В общем-то да, да и он требует глубокого знания тонкостей C++ (чтобы в нем хорошо разбираться). В его защиту можно сказать, что boost не монолитный, а разбит на много не очень больших библиотек, причем каждая из них хороша в отдельности ;). Но коль STLplus работает и вполне устраивает, то почему бы и нет ;)

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

[Krovosos]

Интересный вопрос. Боюсь, что отчуждение этого проекта — непростая задача. Когда мы закончим свое решение на его основе я подумаю.

[maashaa]

А почему вы писали свой сервер вместо модуля к Nginx или Apache (Light)? Слушающий socket, конечно, просто написать, но в 1.1, например, надо склеивать multipart post запросы, не говоря уже о том, что быстро это будет работать, если Вы слушаете через epoll. Да, сервера содержат много кода, но можно же работать с ними из своего модуля по простому интерфейсу, концентрируясь на своей специфике и давая серверам делать свою работу хорошо. Или нет?

[Krovosos]

epoll я не использую, но все равно работает довольно быстро. multipart немного заморочен. Мне было интересно, но главная причина в том, что я точно знаю где и как что работает. Не будет сюрпризов в производительности и т.п.

[maashaa]

спасибо

[alekciy]

>Следующий шаг — встраивание веб-сервера. Ничего подходящего в open-source я, к сожалению, не нашел.
Хм… мне кажется, что подобных проектов более чем достаточно. Берем к примеру Yaws.

Опять же в контексте: «Это не должен быть C++ или Java. Эти языки привнесут ненужную сложность и не дадут необходимой гибкости.» вам бы очень неплохо мог бы подойти Erlang. Там и СУБД есть. Mnesia. А для любителей собственных разработок ETS/DETS (ETS находиться в памяти).

>То же недоумение постигло меня, когда я возжелал быстро отыскать простейший скриптик для отправки
>формы через AJAX POST-запрос.
Опять же к вопросу о поиске. Сам лично еще в начале 2006-ого писал заметку «AJAX. Так что же это?» в которой шла оправка именно POST данных.