О, спасибо, очень точно! Я подозревал что-то подобное…
Вообще, выбор виртуальной машины для реализации проекта — это вещь, над которой нужно очень хорошенько думать…
Согласен, это интересная задача. Но когда я думаю о том, какой это необъятный объем работы — у меня прямо руки опускаются… И все «бонусы» теряют свою привлекательность :-)
Присоединяюсь :-) Несмотря на то, что объектно-ориентированную модель Javascript многие ругают, мне очень нравится программировать на Javascript. Возможность создавать inline-функции без особых забот, использовать или не использовать $ в именах переменных, и, в общем, круто все делать — и при этом никаких обязанностей, как в Java, где обязательно создавать подо все классы и постоянно new'кать :-)
Здорово!
Еще одна тема для «подумать» — интересно, Node.js, у которого разбор request body написан на Javascript, будет ли сравним по скорости с кодом на Си? С учетом того, что виртуальная машина v8 очень и очень даже быстрая — может быть, и не имеет смысла усилия тратить на низкоуровневое программирование правда :-)
v8 действительно быстрее (хотя все зависит, конечно от задач) — я пробовал тестировать скрипты в javascript shell, вот только результаты в виде красивых графиков пока не оформил.
TraceMonkey же выбрал по следующим причинам:
— По сравнению с v8, можно писать на чистом Си (хотя TraceMonkey написана на C++)
— Не нашел явного указания на то, что v8 является thread-safe. Хоть он и слинкован с libpthread по умолчанию, но делать большой проект, а потом прекращать его из-за проблем с потокобезопасностью не очень хотелось…
Детали всегда интересны :-)
А потом, качественно сделанный самокат с возможностью доработки до чего-то более цивильного — он ведь может и получше китайского велосипеда. Метафора, ессно…
Не могу не согласиться, что определенный набор модулей действительно необходим.
Но, на самом деле, нужно осознавать, что 90% (или сколько?) задач решаются с помощью очень небольшого количества модулей. Я их попытался перечислить в статье.
Ну например, часто ли вы используете работу с shared memory или mssql? А XMLRPC? Так стоит ли заморачиваться этими модулями? А из сисколов — вот, например, popen() или exec() — на очень многих хостингах тупо закрыты.
И, кстати, будучи в поисках серверной реализации Javascript я не нашел сколь-нибудь приемлемой реализации разбора строки запроса или POST-данных. А, на мой взгляд, с этого следовало начать (я, впрочем, может быть пропустил чего?)
Действительно, досадное упущение…
Во время поисков, самым удачным мне показался проект jslibs. Он действительно содержит многое из того, что хотелось бы иметь для standard library (разные базы данных, работа с файлами, и т.п.) А вот перечисленных вами проектов не находил, спасибо за ссылки.
Я правильно понимаю, что они тоже позволяют (в разной степени) создавать и использовать стандартные библиотеки, а также создавать приложения (fastcgi и другие)?
Нет… Манипуляция с текстом страницы, который клиент получит все равно статичным, и использование для этого сложных интерфейсов и компонентов — опасная штука, на мой взгляд…
Практика показала, что нет :-(. Если 10 клиентов одновременно запрашивают страницу со скриптом sleep(1), то один из них обязательно увидит страницу после 10 секунд.
Почему так — я не очень понял (в API nginx не до конца разобрался пока что, поэтому тестировал «по-колхозному»). Но основной обработчик запрограммирован не так, как в perl-модуле, без глобальной блокировки.
Что действительно успешно получается — так это одновременная отправка данных из выполненных скриптов нескольким «медленным» клиентам (одним рабочим процессом). Правда, это не совсем то, что хотелось бы получить в идеале (и не то, о чем был вопрос, это я понимаю :-) )
nginx+php я видел в двух вариантах: apache+php+nginx в качестве reverse-proxy (самые простые мои тесты показали, что минимальные скрипты в такой реализации работают в несколько раз медленнее, чем просто apache+php, что и понятно — тесты были на локальном компьютере, без учета скорости сети), и nginx+php как fastcgi. Сравнить действительно было бы интересно (и, скорее всего, я даже этим займусь), но вот некоторое предубеждение против php, установленного как fastcgi, у меня есть. Неспроста я упомянул про 502 ошибку сервера, которая возникает при сбоях в fastcgi-процессах.
Хотя, не исключаю, что мои знания в этой области уже устарели, и сейчас все используют fastcgi без особых проблем.
Скрипты, которые тестировались — это обычные «Hello, World!» на PHP и на Javascript (каждый из одной команды). Я не стал сравнивать более сложные программы, потому что тогда на скорость работы влияли бы еще другие факторы: внутренняя реализация арифметики, циклов, функций, работы с памятью, и т.д. в PHP и Javascript. Это, согласитесь, тема отдельного обсуждения (не менее интересная, впрочем).
Модулем. FastCGI при некоторых условиях теряет стабильность (я упомянул про 502 ошибку, очень распространенную на сайтах с FastCGI) и работает, все-таки, несколько медленнее.
Вообще, выбор виртуальной машины для реализации проекта — это вещь, над которой нужно очень хорошенько думать…
Еще одна тема для «подумать» — интересно, Node.js, у которого разбор request body написан на Javascript, будет ли сравним по скорости с кодом на Си? С учетом того, что виртуальная машина v8 очень и очень даже быстрая — может быть, и не имеет смысла усилия тратить на низкоуровневое программирование правда :-)
TraceMonkey же выбрал по следующим причинам:
— По сравнению с v8, можно писать на чистом Си (хотя TraceMonkey написана на C++)
— Не нашел явного указания на то, что v8 является thread-safe. Хоть он и слинкован с libpthread по умолчанию, но делать большой проект, а потом прекращать его из-за проблем с потокобезопасностью не очень хотелось…
А потом, качественно сделанный самокат с возможностью доработки до чего-то более цивильного — он ведь может и получше китайского велосипеда. Метафора, ессно…
Но, на самом деле, нужно осознавать, что 90% (или сколько?) задач решаются с помощью очень небольшого количества модулей. Я их попытался перечислить в статье.
Ну например, часто ли вы используете работу с shared memory или mssql? А XMLRPC? Так стоит ли заморачиваться этими модулями? А из сисколов — вот, например, popen() или exec() — на очень многих хостингах тупо закрыты.
И, кстати, будучи в поисках серверной реализации Javascript я не нашел сколь-нибудь приемлемой реализации разбора строки запроса или POST-данных. А, на мой взгляд, с этого следовало начать (я, впрочем, может быть пропустил чего?)
Во время поисков, самым удачным мне показался проект jslibs. Он действительно содержит многое из того, что хотелось бы иметь для standard library (разные базы данных, работа с файлами, и т.п.) А вот перечисленных вами проектов не находил, спасибо за ссылки.
Я правильно понимаю, что они тоже позволяют (в разной степени) создавать и использовать стандартные библиотеки, а также создавать приложения (fastcgi и другие)?
Почему так — я не очень понял (в API nginx не до конца разобрался пока что, поэтому тестировал «по-колхозному»). Но основной обработчик запрограммирован не так, как в perl-модуле, без глобальной блокировки.
Что действительно успешно получается — так это одновременная отправка данных из выполненных скриптов нескольким «медленным» клиентам (одним рабочим процессом). Правда, это не совсем то, что хотелось бы получить в идеале (и не то, о чем был вопрос, это я понимаю :-) )
Хотя, не исключаю, что мои знания в этой области уже устарели, и сейчас все используют fastcgi без особых проблем.