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

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

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

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

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

ок, исправил

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

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

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

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

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

Нет.

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

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

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

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

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

Нет

Как бы 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()

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

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

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

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

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

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

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

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

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