Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 166
Очень толковое предположение. Особенно вам понравится тот факт, что в одной VM можно запустить кучу всего и оно не будет друг другу мешать.
Единственное что я не уверен, что вам сходу подойдет RabbitMQ. Этот прекрасный продукт заточен под быструю доставку чудовищного количества сообщений, а вам бы иметь возможность послать сообщение с таймаутом.
Возможно обойдетесь малой кровью в виде небольшого фронт-прокси перед RabbitMQ.
github.com/noss/ifastcgi Это видели? Нерабочее?
Единственное что я не уверен, что вам сходу подойдет RabbitMQ. Этот прекрасный продукт заточен под быструю доставку чудовищного количества сообщений, а вам бы иметь возможность послать сообщение с таймаутом.
Возможно обойдетесь малой кровью в виде небольшого фронт-прокси перед RabbitMQ.
github.com/noss/ifastcgi Это видели? Нерабочее?
Замечательная статья.
Симбиоз стейтлесс-языка для комет, очередей, шаблонизации и кэширования/маршрутизации и php в качестве дешёвого для разработки бизнес-логики бэкенда давно напрашивается.
Если вы будете открывать проект под совместимой с работой сообщества лицензией — то отписывайте прогресс, будет интересно.
Симбиоз стейтлесс-языка для комет, очередей, шаблонизации и кэширования/маршрутизации и php в качестве дешёвого для разработки бизнес-логики бэкенда давно напрашивается.
Если вы будете открывать проект под совместимой с работой сообщества лицензией — то отписывайте прогресс, будет интересно.
Что-то мне показалось, что некоторые пункты притянуты за уши.
Отправка писем — в линуксе, на сколько я знаю, письма мгновенно встают в системную очередь, а дальше почтовый демон думает об отправке, о повторной отправке и прочем хламе. Если под виндой нет такого демона, то именно его и стоит завести.
Реализовывать крон на эрланге — микроскоп и гвозди. Напишите свой крон на пыхе универсальный и кросплатформенный. Я так и не понял, чем вам пых запущенный надолго не угодил.
Очереди — так вы сами и ответили. Есть разные решения для организации очередей сообщений.
Зачем без особой на то нужды нанимать программиста на довольно экзотическом языке программирования? Другое дело, если б вы уже использовали где-то Erlang.
Отправка писем — в линуксе, на сколько я знаю, письма мгновенно встают в системную очередь, а дальше почтовый демон думает об отправке, о повторной отправке и прочем хламе. Если под виндой нет такого демона, то именно его и стоит завести.
Реализовывать крон на эрланге — микроскоп и гвозди. Напишите свой крон на пыхе универсальный и кросплатформенный. Я так и не понял, чем вам пых запущенный надолго не угодил.
Очереди — так вы сами и ответили. Есть разные решения для организации очередей сообщений.
Зачем без особой на то нужды нанимать программиста на довольно экзотическом языке программирования? Другое дело, если б вы уже использовали где-то Erlang.
письма мгновенно встают в системную очередь
И на smtp-сервер мгновенно отправляются?
Если вместо миллиарда костылей и риторики можно сделать красивое решение — почему бы нет?
Я где-то предложил костыли?
Наоборот я как раз думаю, чтобы нарисованная связка заработала как раз и потребуется миллиард костылей.
Наоборот я как раз думаю, чтобы нарисованная связка заработала как раз и потребуется миллиард костылей.
Думаю, я некорректно сформулировал мысль. В статье автора приведён список костылей для решения определённых задач, и, как итог — решение (вдруг изкоробочное и монолитное?), которое может от этих костылей избавить. Разве это плохо?
Плохо, что нет обоснования нафига всё это надо объединять в монолит или коробку. В монолит имеет смысл объединять систему решающую определённый класс задач.
Какие же задачи будет решать эта система? Лонг поллинг и отложенное выполнение для PHP?
Для этого предлагается объединить 3 монстров (сервер очередей, вебсервер и крон) и после этого ожидать, что это будет надёжная среда.
Наоборот, мне кажется, это будет комшар разработчика при отлавливании багов.
Какие же задачи будет решать эта система? Лонг поллинг и отложенное выполнение для PHP?
Для этого предлагается объединить 3 монстров (сервер очередей, вебсервер и крон) и после этого ожидать, что это будет надёжная среда.
Наоборот, мне кажется, это будет комшар разработчика при отлавливании багов.
Обоснование простое — нужно сделать коробочную систему планирования. К сожалению, изначально был выбран не очень подходящая для реализации систем непрерывного действия инфраструктура (насколько я понимаю — целиком на PHP и сопряжённых технологиях) со множеством подставок. Как водится, теперь проще построить новый инфраструктурный фундамент из Erlang (при должной сноровке разработчиков багов там практически не будет), который заменит собой дуэт японских плохишей-годзилл (а, в перспективе — и вебсервер) и уже потом, используя почти непотопляемый (а в случае с Erlang это так и есть) остов, перестроить пхп-бэкенды. Либо на том же пхп, либо на Erlang ( вдруг понравится?). Я даже не хочу говорить о нагрузках, которые будет способен пережевать такой фундамент ( особенно с энджайниксом в качестве фронта).
Вроде нормальное обоснование. На словах, по крайней мере, не знаю уж как там с экономической составляющей.
А кошмара для разработчиков при условии нормального проектирования API к этому монолиту просто не видно.
Вроде нормальное обоснование. На словах, по крайней мере, не знаю уж как там с экономической составляющей.
А кошмара для разработчиков при условии нормального проектирования API к этому монолиту просто не видно.
Про должную сноровку разработчиков. Я бы как раз не стал выбирать эрланг именно по этой причине. Питон и Ява более понятны пхп-разработчикам и специалистов на них гораздо больше. Проект на Эрланге может встать на пол года из-за ухода / болезни и т.п. 1-2 вменяемых разработчиков, которым замену просто так не найти.
Про непотопляемость. Вот этого я никак понять не могу. Какая нагрузка будет у коробочного решения? Компания из 1000 пользователей? 1-2 клика в секунду в пике нагрузки? На это хватит любого, даже коряво настроенного, сервера. Тут нагрузка играет крайне малую роль. А размах такой, что с аналогичными трудозатратами можно писать демонят на чём угодно. На Сях, Питоне, Яве, вкомпилированными модулями для Пхп и т.д. и т.п.
Про непотопляемость. Вот этого я никак понять не могу. Какая нагрузка будет у коробочного решения? Компания из 1000 пользователей? 1-2 клика в секунду в пике нагрузки? На это хватит любого, даже коряво настроенного, сервера. Тут нагрузка играет крайне малую роль. А размах такой, что с аналогичными трудозатратами можно писать демонят на чём угодно. На Сях, Питоне, Яве, вкомпилированными модулями для Пхп и т.д. и т.п.
Это какое-то очень странное выссказывание: «ява понятна пхп разработчикам». Я проверял: переучить на erlang — неделю, две. На яву в месяц не уложишься.
Перефразирую. Код на Яве читать проще, ООП роднее и понятнее. На Эрланге надо думать по-другому. За 2 недели можно выучить синтаксис, но не вывихнуть себе мозг.
Да — что на яву, что на шорпиё, что на любой другой язык человек, в общих чертах знакомый с целевой парадигмой и приличным опытом переходит за две-три недели, а уверенно использовать может через месяц-три. Это, конечно, если есть фуллтайм-занятость и мотивация. ПМСМ.
Мне кажется, что в первое время разработчики будут писать «php-код» что на Яве, что на шарпах… Я много раз видел подобные примеры. Кстати, видел и обратный пример — когда Ява-разработчик писал на PHP… разбираться в этом было очень непросто. Всё таки у разных языков разный подход.
Для php — это обычно написать что-то, а потом узнать, что это решение делает 100+ запросов к базе и надо переписывать нормально.
А что плохого в подходе «преждевременная оптимизация — зло»? :)
Другое дело, что для PHP обычно, увы, сначала написать что-то своё, потом дописать к нему кучу костылей, потом
Да и сейчас, вроде, строгого архитектурного стандарта де-факто (читай — доминирующего фреймворка) для PHP как-то не наблюдается. Одни тянут совместимость чуть ли не с PHP3, другие на неё забивают и ориентированы на вчерашний релиз. Одни не используют магию, другие используют, причём каждый свою. Одни, складывается впечатление, видят своим идеалом ту часть мир Java, что с километровыми XML-конфигами, другие — RubyOnRails, которые сами знают, что нужно разработчику, а если ошибаются, то не рельсы, а разработчик, думая что ему нужно то, чего в гемах нет :)
Я боюсь оказаться голословным и самонадеянным, но, смею полагать, что то, что будет написано на эрланге — оно не потребует фуллтайм-программиста на поддержку. Также я думаю, что разработчики мегаплана подумали об этом и сознательно пошли по этой дорожке.
Непотопляемость — это дополнительное свойство. Я так понимаю, что планируется на базе одной «платформы» построить локальные системы, саас и общедоступный сервис. Вполне возможно, что в последних двух случаях отказоустойчивость будет очень к месту.
Непотопляемость — это дополнительное свойство. Я так понимаю, что планируется на базе одной «платформы» построить локальные системы, саас и общедоступный сервис. Вполне возможно, что в последних двух случаях отказоустойчивость будет очень к месту.
вот здесь написано про окамл, как боялись писать проект на окамле по тем причинам, которые вы называете, и как написали, и как все эти риски оказались надуманными.
(да, окамл, конечно, не эрланг, но тоже эзотерический язык с точки зрения среднего пхп-программиста)
что касается явы/питона, то вы представляете себе затраты времени и людей на переписывания проекта на эти языки?
(да, окамл, конечно, не эрланг, но тоже эзотерический язык с точки зрения среднего пхп-программиста)
что касается явы/питона, то вы представляете себе затраты времени и людей на переписывания проекта на эти языки?
Так речь не идёт о том, чтобы разработчики, которые пишут прикладной софт на PHP изучали для решения описанных задач Erlang. Речь о том, чтобы сделать документированный продукт, с помощью которого PHP-разработчики будут решать задачи, используя только PHP и соответствующее API.
По опыту с 99% вероятностью рано или поздно придётся влезать в код соседнего продукта. Причины могут быть разные. Чаще всего чтобы посмотреть как что-то устроено.
Среднестатистический похапэ-разработчик часто залезает в код MySQL, Apache или, не дай бог, самого PHP?
Соседнего — который разрабатывают в той же конторе, где он сам работает.
Чем в НОРМАЛЬНОЙ конторе (даже гетерогенный по средствам реализации) софт отличается от приведённых мной примеров?
Я понимаю, что иногда можно залезть внутрь исходников, поглядеть, почитать, посамообразовываться. Но если это нормальный софт с документацией, пройденным QA, актом ввода в коробочную эксплуатацию — то на правку туда лезть никому не дадут, а, следовательно, минусов никаких быть не может.
Разве что несколько самых вменяемых пхп-кодеров мутируют в нормальных программистов и уйдут из проекта на эрланг-поля с зарплатой в два-три раза повыше. Но это же хорошо для индустрии, нет? ;D
Я понимаю, что иногда можно залезть внутрь исходников, поглядеть, почитать, посамообразовываться. Но если это нормальный софт с документацией, пройденным QA, актом ввода в коробочную эксплуатацию — то на правку туда лезть никому не дадут, а, следовательно, минусов никаких быть не может.
Разве что несколько самых вменяемых пхп-кодеров мутируют в нормальных программистов и уйдут из проекта на эрланг-поля с зарплатой в два-три раза повыше. Но это же хорошо для индустрии, нет? ;D
Ага-ага. Софт с документацией, пройденным QA, актом ввода в коробочную эксплуатацию… Вы такое часто видели? В идеальном мире конечно так и бывает, но в реальности как всегда «по самым разным причинам», всё происходит иначе. Как говориться, пусть кинет в меня камень тот, кому ни разу в жизни не приходилось выкатывать «сыроватый» продукт. Ну и далее, недотестированность, косяки и, самое страшное, устаревание документации и т.д. и т.п. Это же рапид-девелопмент, привет! ) Быстро и с идеальным качеством никто ничего никогда не выпустит.
Видели. Россия не везде страна безответственных жизнерадостных алкашей и идиотов. Просто не надо документацию делать бездумно для галочки, QA отпускать на самотёк (экономя на этом денежку на новый кожаный диван для жаханья секретарш), а акты подписывать за бутылкой армянского коньяка.
Это аргументы из серии «ну а может вот так?». Не надо этого, пожалуйста. Как правило, всё очень хорошо, если на это хорошо не смотреть через чёрные очки.
Это аргументы из серии «ну а может вот так?». Не надо этого, пожалуйста. Как правило, всё очень хорошо, если на это хорошо не смотреть через чёрные очки.
Так чего вы сидите. Бегите подавать заявку в книгу рекордов Гиннеса. Вы — уникум. Ну или у вас мало опыта, но по возрасту не скажешь. Или ещё вариант — контора из 3-х человек. Или работа на забугорье (и то там тоже очень разное бывает). Всё. Других объяснений я придумать не могу.
Давайте не будем опускаться до уровня низших приматов.
Я не уникум, просто надо любить свою работу (иногда даже через «не хочу»), пускать в неё хороших людей и устраивать её так, чтоб этим людям было комфортно. А это тоже работа. Которую у нас в стране делать не любят.
Я не уникум, просто надо любить свою работу (иногда даже через «не хочу»), пускать в неё хороших людей и устраивать её так, чтоб этим людям было комфортно. А это тоже работа. Которую у нас в стране делать не любят.
В конечном итоге искренне рад за вас, если у вас правда всё бело и пушисто. Но гложет то, что своими глазами я идеального мира не видел и от друзей о таком не слышал, хотя и сам работал в не последних компаниях рунета, а уж некоторые из друзей вообще в компаниях мирового уровня.
Другое дело что иногда тест-драйв-девелопментом или проходом QA называют наличие в 4 тестов, которые написал «самый умный». Документацией называют прогон конвертилки из камментов к коду в красивый html для соответствующего языка. Ну и т.д. и т.п.
Любить работу — это правильно и хорошо. Но обычно практичность бьет чистоту. Иногда слишком сильно…
Другое дело что иногда тест-драйв-девелопментом или проходом QA называют наличие в 4 тестов, которые написал «самый умный». Документацией называют прогон конвертилки из камментов к коду в красивый html для соответствующего языка. Ну и т.д. и т.п.
Любить работу — это правильно и хорошо. Но обычно практичность бьет чистоту. Иногда слишком сильно…
Если задача — сделать мощную инфраструктуру с вбесервером и очередями, то почему бы не взять что-то готовое на Java? Я считаю использование Erlang для данной задаи экономически неоправданным.
Они и берут готовое, только на Erlang, вебсервер и очереди уже реализованы, достаточно лишь связать их в единое целое.
Вам больше Java нравится? Хорошо, вот и делайте на ней что хотите, только не надо другим капать на мозги, что это самое лучшее решение. Не факт, что по времени и деньгам на Java выйдет лучше, скорее наоборот.
Вам больше Java нравится? Хорошо, вот и делайте на ней что хотите, только не надо другим капать на мозги, что это самое лучшее решение. Не факт, что по времени и деньгам на Java выйдет лучше, скорее наоборот.
Что специфично. Точку зрения, что это надо делать на Эрланге, отстаивают именно эрлангеры. Нет поклонение своей плфтформе — дело хорошее.
Но вот экономическая целесообразность использование эрланга для данной задачи — совсем неоправдана. Начиная от подбора персонала, заканчивая долгосрочной персективой поддержки.
Я сейчас рассуждаю сейчас не как воодушевлённый фанатик, а как практик. Чего не скажешь о вас. Где вы видите, что я «капаю на мозги, что это лучшее решение»? Я задал вопрос про альтернативное решение.
Для себя бы я наверняка выбрал Erlang, ибо пишу на нём уже несколько лет. Но вот для фирмы Мегаплан как таковой, я не вижу смысла вкладываться в Эрланг, если у них нет своих Эрланг разработчиков.
Но вот экономическая целесообразность использование эрланга для данной задачи — совсем неоправдана. Начиная от подбора персонала, заканчивая долгосрочной персективой поддержки.
Я сейчас рассуждаю сейчас не как воодушевлённый фанатик, а как практик. Чего не скажешь о вас. Где вы видите, что я «капаю на мозги, что это лучшее решение»? Я задал вопрос про альтернативное решение.
Для себя бы я наверняка выбрал Erlang, ибо пишу на нём уже несколько лет. Но вот для фирмы Мегаплан как таковой, я не вижу смысла вкладываться в Эрланг, если у них нет своих Эрланг разработчиков.
Вы, видимо, ничего не поняли.
Как они могут написать «свой на пыхе», если есть четко описанные проблемы с демонизацией. Есть проблемы с администрированием всего этого.
Когда выкатываешь коробку клиенту надо, что бы была только одна движущаяся деталь: один демон запустил/остановил.
Как они могут написать «свой на пыхе», если есть четко описанные проблемы с демонизацией. Есть проблемы с администрированием всего этого.
Когда выкатываешь коробку клиенту надо, что бы была только одна движущаяся деталь: один демон запустил/остановил.
Отправка писем — это всего лишь один из возможных вариантов фоновых задач. Ну и вы сами сказали, что в windows красивой локальной очереди писем нет.
Я пытаюсь найти правильный инструмент для решения задачи. Пых — плохой инструмент для реализации демонов, для меня это очевидно и холиварить на эту тему я не буду.
Erlang — хороший инструмент для организации надёжных систем, к тому же очень интересный, несмотря на то что немного экзотичный. А ещё он один подходит для решения всех описанных задач.
Я пытаюсь найти правильный инструмент для решения задачи. Пых — плохой инструмент для реализации демонов, для меня это очевидно и холиварить на эту тему я не буду.
Erlang — хороший инструмент для организации надёжных систем, к тому же очень интересный, несмотря на то что немного экзотичный. А ещё он один подходит для решения всех описанных задач.
Гм… интересное решение, кстати, спасибо на ссылки на мои статьи :) приятно.
По существу — я раньше тоже рассматривал AMQP, но потом попробовал, что связка Node.JS + PHP + Redis решает все эти задачи, не требует экзотического языка, а редис в качестве решения для подписок, реалтайма и хранения части данных показал себя идеально. Комет реализуется на базе Node.JS, кластеризируеться через Redis.
По существу — я раньше тоже рассматривал AMQP, но потом попробовал, что связка Node.JS + PHP + Redis решает все эти задачи, не требует экзотического языка, а редис в качестве решения для подписок, реалтайма и хранения части данных показал себя идеально. Комет реализуется на базе Node.JS, кластеризируеться через Redis.
Вы связываете аж два экзотических решения (Node.js, Redis) с третьим, используя четвертое, пятое и шестое для запуска PHP.
Люди же хотят оставить вместо целой пачки всякого софта только один надежно работающий кусок: это сервер на erlang, который будет сам запускать всё что надо и следить.
Люди же хотят оставить вместо целой пачки всякого софта только один надежно работающий кусок: это сервер на erlang, который будет сам запускать всё что надо и следить.
они никак не экзотические. По крайней мере не более, чем ерланг. Уж JS то знают все :) А то, что например, ерланг даже не ставиться в дебиане на нескольких серверах, и понять что и почему никак нельзя, а тех кто может понять — их раз два и обчелся на весь город…
Почему вы говорите о том, чего не знаете? В squeeze по умолчанию достаточно свежий эрланг, в sid вообще валяется самый свежий. Отсутствие зависимостей делает бекпорт тривиальным. Плюс к тому эрланг без проблем упаковывается в standalone бинарь с зависимостями в виде единственного libc, что вообще нивелирует проблему развёртывания на продакшне. Да, признаю — сейчас нет (ну или я не знаю) готового решения, обеспечивающего выкатывание горячих апгрейдов поверх такого стендалон-бинаря, его нужно написать самому (порядка нескольких десятков строк кода, я полагаю, и хорошее понимание принципов работы OTP). Но это возможно, в отличие от остальных упомянутых вами языков.
Далее. Аргумент «JS знают все» — не аргумент хотя бы потому, что так же все знают, что JS — порождение ада. Писать сервер на чём-то, что не умеет всё это и нахваливать может только похапешник, привыкший к таким прелестным вещам, как текстовые инклюды без неймспейсов или пляски с бубном вокруг демонизации.
И наконец аболютно все, кто изучал эрланг, в один голос утверждают, что он не прост, а очень прост в изучении. За 2-3 недели можно спокойно подтянуть до такого уровня, чтобы садиться и писать код в готовом проекте. Полтора-два месяца — и можно начинать свой проект (потому как OTP сложнее, чем сам erlang, но если в команде есть хотя бы один опытный человек, проблем не будет).
Далее. Аргумент «JS знают все» — не аргумент хотя бы потому, что так же все знают, что JS — порождение ада. Писать сервер на чём-то, что не умеет всё это и нахваливать может только похапешник, привыкший к таким прелестным вещам, как текстовые инклюды без неймспейсов или пляски с бубном вокруг демонизации.
И наконец аболютно все, кто изучал эрланг, в один голос утверждают, что он не прост, а очень прост в изучении. За 2-3 недели можно спокойно подтянуть до такого уровня, чтобы садиться и писать код в готовом проекте. Полтора-два месяца — и можно начинать свой проект (потому как OTP сложнее, чем сам erlang, но если в команде есть хотя бы один опытный человек, проблем не будет).
да именно так — все это не особо нужно. нужен гибкий и красивый язык, а не треды и прочее, тчо вы там написали в комментарии. А то так можно сразу заявить, что языки без статик типизации вообще не нужны :)
если так просто — почему ерланговцев так мало?
P.S. Извините, но я знаю о чем говорю — когда пишу, что я ставил и даже отр среда не установилась из коробки на свежем дебиане ленни на ес2 инстансе.
если так просто — почему ерланговцев так мало?
P.S. Извините, но я знаю о чем говорю — когда пишу, что я ставил и даже отр среда не установилась из коробки на свежем дебиане ленни на ес2 инстансе.
>свежем дебиане ленни
>свежем
>ленни
Извините, у меня не парсится.
>нужен гибкий и красивый язык, а не треды и прочее
Прошу прощения, а «треды и прочее» — не свойства языка, что ли? Или вы про синтаксис? Ну так синтаксис эрланга приятнее лично мне, чем питоновский, например.
>языки без статик типизации вообще не нужны
На самом деле не нужны. Просто пока что многовато нужно знать для того, чтобы писать нормально на языках с нормальными системами типов, хотя код и может выглядеть очень красиво, пруф.
При этом абсолютно точно не нужны языки со слабыми системами типов (см. JS, см. PHP). В эрланге как раз сильная типизация и опциональный тайпчекер (см. Dialyzer), всё более становящийся обязательным (ну или правилом хорошего тона).
>если так просто — почему ерланговцев так мало?
Если всё так просто — почему программистов так мало по сравнению с менеджерами? Программисты не нужны, разогнать всех и работать менеджерами.
>свежем
>ленни
Извините, у меня не парсится.
>нужен гибкий и красивый язык, а не треды и прочее
Прошу прощения, а «треды и прочее» — не свойства языка, что ли? Или вы про синтаксис? Ну так синтаксис эрланга приятнее лично мне, чем питоновский, например.
>языки без статик типизации вообще не нужны
На самом деле не нужны. Просто пока что многовато нужно знать для того, чтобы писать нормально на языках с нормальными системами типов, хотя код и может выглядеть очень красиво, пруф.
При этом абсолютно точно не нужны языки со слабыми системами типов (см. JS, см. PHP). В эрланге как раз сильная типизация и опциональный тайпчекер (см. Dialyzer), всё более становящийся обязательным (ну или правилом хорошего тона).
>если так просто — почему ерланговцев так мало?
Если всё так просто — почему программистов так мало по сравнению с менеджерами? Программисты не нужны, разогнать всех и работать менеджерами.
Многопоточность и очереди сообщений прекрасно решает gearman. Отложенный запуск вроде в последних версиях прикручивали, сам не пробовал.
Опять же клиенты и воркеры могут быть на разных языках, у нас вот Java и PHP. Под виндой gearman запустить можно, ибо есть перловая версия. Думаю C-шную тоже не так долго поправить.
Опять же клиенты и воркеры могут быть на разных языках, у нас вот Java и PHP. Под виндой gearman запустить можно, ибо есть перловая версия. Думаю C-шную тоже не так долго поправить.
С-шный на libevent'е вроде, вряд ли его легко переделать.
А к перлу у меня личная неприязнь, сори :)
А к перлу у меня личная неприязнь, сори :)
Ну если вы не любите ни perl ни C, есть еще Java вариант сервера :).
Правда как я понимаю у вас нет цели найти простое решение, есть цель обсудить решение с erlang
Правда как я понимаю у вас нет цели найти простое решение, есть цель обсудить решение с erlang
В принципе, java — единственный альтернативный кроссплатформенный вариант решения всех обозначенных задач.
Но java — это универсальный монстр, на котором вроде как даже операционную систему написали уже. А erlang — инструмент, который хорошо решает именно те задачи, которые нужно, и есть подозрение, что эти задачи он решает лучше, чем java.
Кроме того, вам не кажется каким-то странным сочетание java и php? Сразу напрашивается вопрос — если уже java стоит, на фига php? На java можно решать все задачи, которые решаются на php. А вот на erlang писать веб-приложения, конечно, можно, но это не самый прямой путь.
Вот и получается, что по охвату функциональности: erlang + php = java :))
Но java — это универсальный монстр, на котором вроде как даже операционную систему написали уже. А erlang — инструмент, который хорошо решает именно те задачи, которые нужно, и есть подозрение, что эти задачи он решает лучше, чем java.
Кроме того, вам не кажется каким-то странным сочетание java и php? Сразу напрашивается вопрос — если уже java стоит, на фига php? На java можно решать все задачи, которые решаются на php. А вот на erlang писать веб-приложения, конечно, можно, но это не самый прямой путь.
Вот и получается, что по охвату функциональности: erlang + php = java :))
Erlang очень хорош для своего круга задач, тут я не спорю, приходилось сталкивать немножко. Просто он в наших краях все-таки экзотика и найти хорошего специалиста написать и поддерживать сервис реализующий все что вам надо и поддерживать мне кажется будет не самой простой задачей.
C Java таким проблем нет. А то что Java универсальный монстр меня не смущает ни капли. Использовать Erlang только потому что на нем НЕудобно писать то что должен делать PHP по-моему странная мотивация.
Соответственно проект переписывать на Java я бы не стал. Инфраструктурные вещи — Java, бизнес-логика PHP. Опять же Java Bridge есть, так что если надо можно напрямую вызывать Java без прочих замороков прямо из PHP, не говоря уж о том же gearman.
C Java таким проблем нет. А то что Java универсальный монстр меня не смущает ни капли. Использовать Erlang только потому что на нем НЕудобно писать то что должен делать PHP по-моему странная мотивация.
Соответственно проект переписывать на Java я бы не стал. Инфраструктурные вещи — Java, бизнес-логика PHP. Опять же Java Bridge есть, так что если надо можно напрямую вызывать Java без прочих замороков прямо из PHP, не говоря уж о том же gearman.
Спасибо за конструктивный ответ. Я «помедитирую» над вашим предложением :)
C Java таким проблем нет.
Ну вот опять. Почему вы думаете, что раз проект написан на java, значит любой java программист сможет его сопровождать?
Если человек до этого писал только бизнес логику с SQL-ем и всякие GUI, а вы его посадите на сопровождение чего-то масштабируемого, многопроцессорного или асинхронного, то его опыт никак ему не поможет. Пусть там хоть «java — 10 лет», он вам так накосячит, оставит скрытые race conditions, которые вы будете потом 5 лет вылавливать. Тут нужен совсем другой опыт, а не знание синтаксиса языка.
Вы отправите объявление о вакансии, и к вам повалят java программисты, потом вы будете гадать, много он вам накосячит или нет? Он будет работать с ядром, критической частью. Опасно. Десятки собеседований, десятки отказов. Семь потом сойдёт.
А вот с эрлангом таких проблем нет. На нём ничего другого не пишут. 1 год эрланга === 1 год concurrency и масштабируемых систем. Даже во время обучения, ставятся мозги так, чтобы человек по минимуму косячил.
На объявление откликнутся 3-4 человека. Нужный навык будет у всех.
Ну вот опять. Почему вы думаете, что раз проект написан на java, значит любой java программист сможет его сопровождать?
Если человек до этого писал только бизнес логику с SQL-ем и всякие GUI, а вы его посадите на сопровождение чего-то масштабируемого, многопроцессорного или асинхронного, то его опыт никак ему не поможет. Пусть там хоть «java — 10 лет», он вам так накосячит, оставит скрытые race conditions, которые вы будете потом 5 лет вылавливать. Тут нужен совсем другой опыт, а не знание синтаксиса языка.
Вы отправите объявление о вакансии, и к вам повалят java программисты, потом вы будете гадать, много он вам накосячит или нет? Он будет работать с ядром, критической частью. Опасно. Десятки собеседований, десятки отказов. Семь потом сойдёт.
А вот с эрлангом таких проблем нет. На нём ничего другого не пишут. 1 год эрланга === 1 год concurrency и масштабируемых систем. Даже во время обучения, ставятся мозги так, чтобы человек по минимуму косячил.
На объявление откликнутся 3-4 человека. Нужный навык будет у всех.
Я не говорю что прям любой, но как минимум выбор будет. Когда нам надо было поковыряться с Erlang на прошлой работе пришлось осваивать самим. Сугубо с этой точки зрения, впрочем у нас провинция, может в Москве ерлангистов хоть жопой жуй.
Еще тут также как в случае Erlang все компоненты кроме разве что менеджера FastCGI уже более-менее готовы, надо лишь собрать в кучу. Так что опыт в написании инфраструктуры конечно нужен, но супермен который будет писать все с нуля годами нет.
Еще тут также как в случае Erlang все компоненты кроме разве что менеджера FastCGI уже более-менее готовы, надо лишь собрать в кучу. Так что опыт в написании инфраструктуры конечно нужен, но супермен который будет писать все с нуля годами нет.
Все разглагольствования на тему явы закончатся после запуска приложения на erlang, которое влезет в 40 метров памяти и на яве, которой не хватит 1 гб
Сначала попробуйте эрланг :)
> идеальную, проверенную универсальную платформу, благодарную во всех отношениях
питоноёб детектед
питоноёб детектед
да ну не бывает «идеальных универсальных платформ хороших во всех отношениях». нету серебряной пули. пхп говно полное. питон говно. эрланг говно. го говно. си плюс плюс говно. ассемблер говно. си говно. си шарп говно. джава ваще говно. хаскель говно. лисп говно. окамл говно. схеме говно. эф шарп говно. немерле говно. вижуал бейсик говно. вижуал фортран говно. просто фортран говно. кобол говно. ада говно.
так, что я забыл?
у каждого решения есть плюсы и минусы. у каждого. нет ничего идеального. нет «универсального» решения. нет «идельного». нету никаких «благодарную во всех отношениях». если кто-то заявляет обратно, нужно его бить по голове.
так, что я забыл?
у каждого решения есть плюсы и минусы. у каждого. нет ничего идеального. нет «универсального» решения. нет «идельного». нету никаких «благодарную во всех отношениях». если кто-то заявляет обратно, нужно его бить по голове.
обджектив си говно. паскаль говно. перл говно. лого говно.
JavaScript, Java Script забыли!!!
И то же самое другими словами: tonsky.livejournal.com/281876.html
Питон не даст как минимум одного — нормального production-решения для закрывания исходников и лицензирования коробочных продуктов, по крайней мере так было 4 года назад, когда мы начинали писать Мегаплан.
Не соглашусь. Можно pyc-и выкладывать.
Если вам всерьёз (зачем-то) нужно закрывать исходники программы, бинарники которой будут у пользователя, то весьма большое подмножество Python-а можно компилировать Cython-ом.
А на практике, мне вот с лёту не удалось найти рабочий способ, способный декомпилировать .pyc-шки (не говоря уже про .pyo-шки) моего рабочего проекта. depython.com, depython.net/, svn-овый UnPyc на них падают (http://crazy-compilers.com/decompyle по ряду причин не проверял ;) ). И это Python 2.6, даже не 2.7…
А на практике, мне вот с лёту не удалось найти рабочий способ, способный декомпилировать .pyc-шки (не говоря уже про .pyo-шки) моего рабочего проекта. depython.com, depython.net/, svn-овый UnPyc на них падают (http://crazy-compilers.com/decompyle по ряду причин не проверял ;) ). И это Python 2.6, даже не 2.7…
У питона тоже есть проблемы.
1) проблемы с лёгкими тредами
Ок, мы можем решить их с помощью gevent, но тут…
2) отсутстие ОТР
… приходится велосипедить всю ту отлаженную инфраструктуру, что уже есть в эрланг/ОТР. Супервизоры, behaviours, gen_server и т.д. При этом всё это в отсутствии настоящей конкурентной многопоточности — если один гринлет блокируется, блокируются все.
1) проблемы с лёгкими тредами
Ок, мы можем решить их с помощью gevent, но тут…
2) отсутстие ОТР
… приходится велосипедить всю ту отлаженную инфраструктуру, что уже есть в эрланг/ОТР. Супервизоры, behaviours, gen_server и т.д. При этом всё это в отсутствии настоящей конкурентной многопоточности — если один гринлет блокируется, блокируются все.
Может вместо того, чтобы писать фреймворки, конвертеры, адаптеры для PHP, просто изучить и использовать полноценный язык?
Я вот тоже автора не понял, он не захотел использовать одни кастыли, а взял другие, помощьнее.
А почему бы просто не взять и не переписать на языке и технологии в котором всё это давно решено и удачно: Java, Ruby, C# и т.п.
А почему бы просто не взять и не переписать на языке и технологии в котором всё это давно решено и удачно: Java, Ruby, C# и т.п.
с одной стороны, для данной конкретной задачи Gearman подходит лучше. с другой стороны, выбранная вами модель позволит безболезненно постепенно (при необходимости) перепиписывать приложение на эрланг.
довольно необычное решение. и вроде не костыльное.
довольно необычное решение. и вроде не костыльное.
Чудовищно, если честно.
Остается ощущение, что автор намеренно путает понятия «язык программирования», «ОС», «платформа» и еще десяток.
Скажите пожалуйста, а почему PHP, как язык, должен вообще что-то знать о Вашем желании запустить программу в определенное (или через определенное) время? Вам не приходит в голову, что для этого нужно просто грамотно пользоваться средствами операционной системы, которая умеет это давно и хорошо?
Ровно такой же вопрос по поводу Windows — PHP не должен вообще знать о Ваших половых трудностях с платформой.
Ну и конечно вызов скрипта планировщиком по HTTP — это классика жанра, браво. Жду тему «как мы подняли производительность в 2 раза, отказавшись от HTTP при вызове скрипта с того же сервера».
Налицо попытка решить архитектурные проблемы костылями.
Остается ощущение, что автор намеренно путает понятия «язык программирования», «ОС», «платформа» и еще десяток.
Скажите пожалуйста, а почему PHP, как язык, должен вообще что-то знать о Вашем желании запустить программу в определенное (или через определенное) время? Вам не приходит в голову, что для этого нужно просто грамотно пользоваться средствами операционной системы, которая умеет это давно и хорошо?
Ровно такой же вопрос по поводу Windows — PHP не должен вообще знать о Ваших половых трудностях с платформой.
Ну и конечно вызов скрипта планировщиком по HTTP — это классика жанра, браво. Жду тему «как мы подняли производительность в 2 раза, отказавшись от HTTP при вызове скрипта с того же сервера».
Налицо попытка решить архитектурные проблемы костылями.
Вы вообще читали пост?
У операционных систем нет единого способа запустить задачу в указанное время.
У операционных систем нет единого способа запустить задачу в указанное время.
Вы вообще читали хоть что-то?
cron и at — вполне себе кроссплатформенны
это раз
Второе — пусть даже есть определенные различия между cron и nncron. Так напишите адаптер, е-мое, общий-то принцип одинаков.
Зачем тащить еще один язык просто для запуска задачи?
cron и at — вполне себе кроссплатформенны
это раз
Второе — пусть даже есть определенные различия между cron и nncron. Так напишите адаптер, е-мое, общий-то принцип одинаков.
Зачем тащить еще один язык просто для запуска задачи?
В отличие от вас, я ещё и много писал, посложнее чем цмс-ки на пхп. И деплоил софт под виндой, делал коробку которая развертывается потом у кучи разных, среднеквалифицированных людей.
Людям нужно наиболее безгеморойное решение целого класса задач. Erlang — лучшее решение, которое дешевле всего с точки зрения последующей поддержки.
Вы же предлагаете онанизм в виде дополнительных строк пользовательской документации «поставьте это, следите за этой программой».
В их случае ни за чем вообще администратору коробки следить не надо будет.
Людям нужно наиболее безгеморойное решение целого класса задач. Erlang — лучшее решение, которое дешевле всего с точки зрения последующей поддержки.
Вы же предлагаете онанизм в виде дополнительных строк пользовательской документации «поставьте это, следите за этой программой».
В их случае ни за чем вообще администратору коробки следить не надо будет.
Мы сейчас как раз используем nncron в качестве подпорки для Windows. Это неудобно.
Суть идеи в том, чтобы вместо того, чтобы для каждой задачи таскать своё решение, взять одно решение — Erlang — и сделать всё на нём.
Было бы совсем замечательно, если бы можно было всё сделать на самом PHP и не думать о других решениях, но, мне кажется, я достаточно подробно описал, почему PHP плох для целого ряда задач.
Суть идеи в том, чтобы вместо того, чтобы для каждой задачи таскать своё решение, взять одно решение — Erlang — и сделать всё на нём.
Было бы совсем замечательно, если бы можно было всё сделать на самом PHP и не думать о других решениях, но, мне кажется, я достаточно подробно описал, почему PHP плох для целого ряда задач.
Что всё сделать на PHP?
Диспетчер очереди сообщений?
Аналог cron-а?
Зачем?
Есть готовые и проверенные временем решения, встроенные в ОС. То, что Вы не умеете пользоваться cron-ом либо планировщиком Windows, не значит, что надо писать свой планировщик.
То, что Вы не умеете пользоваться CLI в PHP — не значит, что Ваши программы надо запускать исключительно по HTTP.
И так далее.
Диспетчер очереди сообщений?
Аналог cron-а?
Зачем?
Есть готовые и проверенные временем решения, встроенные в ОС. То, что Вы не умеете пользоваться cron-ом либо планировщиком Windows, не значит, что надо писать свой планировщик.
То, что Вы не умеете пользоваться CLI в PHP — не значит, что Ваши программы надо запускать исключительно по HTTP.
И так далее.
Диспетчер очереди сообщений?
я не предлагаю делать диспетчер на PHP, я предлагаю использовать одно из лучших решений на рынке, написанный на Erlang — RabbitMQ
Аналог cron-а?
Он у нас уже есть, поскольку сам крон не умеет решать задачи типа «сделать что-то каждую вторую пятницу чётного месяца в 11:00», а нам это нужно.
На Erlang нужен только инициатор, который вовремя запустит PHP.
То, что Вы не умеете пользоваться CLI в PHP — не значит, что Ваши программы надо запускать исключительно по HTTP.
А что там, собственно, нужно «уметь»? Мы сейчас используем запуск задач по cron. Могу сказать, что это неудобно как минимум тем, что трудно контролировать количество таких задач, работающих в данный момент — довольно просто себя задосить.
Что касается производительности — я не проводил бенчмарков, а вы проводили? Откуда информация, что запуск через HTTP+FastCGI будет работать дольше, чем через прямой CLI вызов? Как мы все знаем, FastCGI для того и придумали, чтобы не разбазаривать ресурсы на постоянный fork при использовании CGI.
К тому же я не уверен, что на JVM можно элегантно решить проблему масштабного comet'а.Чтобы развеять сомнения, посмотрите Netty.
или на худой конец Scala/Akka — будет то же, за что хотите ерланг. А вместо RabbitMQ логично взять HornetQ
Меня искренне забавляют предложения заменить отлаженную, компактную и проверенную временем инфраструктуру на сырые академические поделки типа Akka.
Зачем??
Зачем??
есть такая пословица — каждый кулик хвалит свое болото :) То что вы пиарете ерланг, конечно все круто, но не значит, что идеальная система. Пруфлинк плиз про сырость акки :) При этом получая все из мира java а не несколько десятков странно написаны непонятных модулей и всего 2 — 3 реально работающих продукта в мире. Это как говорит о платформе?
Буквально недавно мой бывший однокурсник нашел в скаловском unlink-е утечку памяти. Стоит ли дальше продолжать насчёт сырости продукта?
Ну всё же менять RabbitMQ на что-то другое я бы не стал, его можно отлично использовать и с Java/Scala решениями, тем более, что у него есть официальное Java API.
Erlang и решения на нём — штуки отличные, поэтому я с удовольствием использую их (CouchDB, Riak, RabbitMQ) из других языков/платформ, совсем не обязательно для этого погружаться в «кухню» эрланга конечно же.
Erlang и решения на нём — штуки отличные, поэтому я с удовольствием использую их (CouchDB, Riak, RabbitMQ) из других языков/платформ, совсем не обязательно для этого погружаться в «кухню» эрланга конечно же.
Для данной задачи хорошо подходит Node.JS/npm. Работает и под Windows, и прекрасно подходит для Comet и имеет неплохие клиенты для очередей и нереляционных баз данных.
+ Redis
> Для данной задачи хорошо подходит Node.JS/npm. Работает и под Windows, и прекрасно подходит для Comet и имеет неплохие клиенты для очередей и нереляционных баз данных.
И отлично падает на сраных 100k сообщениях — github.com/Papipo/socket.io-erlang-vs-nodejs
И отлично падает на сраных 100k сообщениях — github.com/Papipo/socket.io-erlang-vs-nodejs
У кого-то на машине :)
Кстати, ничего не мешает добавить Cluster, чтобы распаралеллить на все ядра.
Кстати, ничего не мешает добавить Cluster, чтобы распаралеллить на все ядра.
Простите, я не знаю что такое Cluster, но я знаю правильный вопрос — а оно умеет общаться между процессами работающими на разных ядрах (shared state, messaging)? А между процессами на разных машинах?
Т.е. не умеет.
Умеет, стандартные сообщения Web Workers никто не отменял.
просто для меня ZeroMQ предпочтительней, ибо при этом границы процессов и машин расплываются.
Почитайте про эту технологию, это нормальный нативный код, так что производительность на хорошем уровне.
просто для меня ZeroMQ предпочтительней, ибо при этом границы процессов и машин расплываются.
Почитайте про эту технологию, это нормальный нативный код, так что производительность на хорошем уровне.
Акжан, тебе явно стоит поработать там, где есть продакшн =)))
Люди хотят оставить один процесс, а ты предлагаешь целую пачку и ещё дать им возможность общаться через дополнительный демон. Очень весело это всё будет развертываться на клиентской винде.
Люди хотят оставить один процесс, а ты предлагаешь целую пачку и ещё дать им возможность общаться через дополнительный демон. Очень весело это всё будет развертываться на клиентской винде.
Максим, у нас для большинства проектов есть и staging, и production :)
ZeroMQ — библиотека, предоставляющая транспортный слой (сообщения внутри процесса, вне процесса, вне узла сети), а не демон. Это не RabbitMQ etc.
Автор хочет внедрить прослойку в виде Erlang, я в его случае мог бы заменить на прослойку в виде Node.JS.
P.S.: кстати, потихоньку читаю по Erlang, восхищаюсь местами :)
ZeroMQ — библиотека, предоставляющая транспортный слой (сообщения внутри процесса, вне процесса, вне узла сети), а не демон. Это не RabbitMQ etc.
Автор хочет внедрить прослойку в виде Erlang, я в его случае мог бы заменить на прослойку в виде Node.JS.
P.S.: кстати, потихоньку читаю по Erlang, восхищаюсь местами :)
это трабла именно либы Socket.io а не ноды
там ничего не падает, там проблема с тем, что для websocket transport'а не совсем правильно реализована поддержка «сердцебиения» из-за чего закрывается соединение. Если отключить поддержку сердцебиения (а в erlang'овской реализации ее кстати и нет), то все нормально работает:
twitter.com/#!/3rdEden/status/74884695933980673
twitter.com/#!/3rdEden/status/74879359017680896
twitter.com/#!/3rdEden/status/74884695933980673
twitter.com/#!/3rdEden/status/74879359017680896
Нам не нужны по-настоящему изолированные лёгкие треды. Нам не нужен нормальный паттерн-матчинг без костылей. Нам не нужна статическая проверка типов с типовыведением. Нам не нужны средства автоматического рефакторинга, способные гарантированно корректно менять код. Нам не нужна реальная многопроцессорность из коробки. Нам не нужен сверхнадёжный фреймворк для построения любых сервисов (ОТР). Нам не нужна готовая инфраструктура для управления ошибками и crash recovery. Нам не нужна горячая замена кода. Нам не нужны средства для разворачивания кластера. Нам не нужны cluster-wide эвенты, регистрация потоков, загрузка нод по сети. Нам не нужен Erlang. Мы выбираем server-side JS и node.js, ведь мы уже знаем JS.
а вы действительно не научились еще программировать без паттерн-матчинга, без статическиз типов (а я так рад что слез с этой фигни)?
Erlang у нас тоже используется, но не для Comet-сервисов.
Кроме того, хоть по многим факторам Node.JS уступает Erlang, не стоит забывать, что область применения все-таки отличается. А некоторые перечисленные вами возможности давно есть для Node.
Так что ваши предпосылки неверны.
Кроме того, хоть по многим факторам Node.JS уступает Erlang, не стоит забывать, что область применения все-таки отличается. А некоторые перечисленные вами возможности давно есть для Node.
Так что ваши предпосылки неверны.
>некоторые перечисленные вами возможности давно есть для Node
Подробнее же!
>область применения все-таки отличается
>некоторые перечисленные вами возможности
>Так что [все] ваши предпосылки неверны.
У вас ошибка в кванторе.
Подробнее же!
>область применения все-таки отличается
>некоторые перечисленные вами возможности
>Так что [все] ваши предпосылки неверны.
У вас ошибка в кванторе.
Основная ваша предпосылка — «потому что мы знает JavaScript». Ну да, знаем :) Но это не основная причина :)
Ну а тогда нет ни одной причины взять ноду вместо эрланга. Я допускаю, конечно, что это может быть не так, но никто до сих пор не смог привести ни одного аргумента нормального кроме «JS все знают». Это неправда, сервер-сайд JS гораздо сложнее того, что под ним подразумевает большинство верстальщиков со своими «вау-вау, я подключил плагинчик на jquery, теперь я погромист». Совсем не в последнюю очередь из-за граблей, заботливо разложенных самим языком — см. wtfjs.com хотя бы.
Боюсь, что я даже не смогу перечислить все используемые нами языки, каркасы, и т.д… В них входят и ObjectiveC/MLFoundation, и Erlang/OTP, и Node.JS, и Rails, и Sinatra, и nginx/Passenger/unicorn/rainbows/Apache/Mongrel, и C++/boost, и Perlbal, и что-то еще… Зоопарк еще тот :)
По делу могу вот что добавить:
сомневаться не стоит, вы выбрали правильный инструмент. Erlang действительно переносим между указанными платформами, очень хорошо задизайнен внутри, очень нересурсоёмкий.
FastCGI я бы порекомендовал под MIT выложить на гитхаб, это инфраструктурная вещь, которую лучше пусть будут отлаживать другие люди.
С остальным успехов, через пару недель вы уже сможете собрать работающий прототип.
сомневаться не стоит, вы выбрали правильный инструмент. Erlang действительно переносим между указанными платформами, очень хорошо задизайнен внутри, очень нересурсоёмкий.
FastCGI я бы порекомендовал под MIT выложить на гитхаб, это инфраструктурная вещь, которую лучше пусть будут отлаживать другие люди.
С остальным успехов, через пару недель вы уже сможете собрать работающий прототип.
Для поддержки коробочного решения (и, соотвественно, решения проблем с кроcсплатформенностю) очень бы подошла технология виртуализации. Тогда коробочное решения представляло бы из себя виртуальный диск, со связкой необходимого и настроенного ПО.
Тоже об этом думал. решение простое и изящное. И требования кроссплатформенности и т.п. сразу отпадают, можно заточить строго под одну конфигурацию.
Мы рассматривали этот вариант.
Тогда нужно завязывать лицензию на hardware-ключ, а такого решения для PHP нет.
Тогда нужно завязывать лицензию на hardware-ключ, а такого решения для PHP нет.
Его можно реализовать в виде встроенного PHP модуля. На мой взгляд это сделать проще, чем найти адекватного Erlang программиста.
А в общем придумывать ничего не нужно, так как готовые решение уже, в принципе, имеются: www.microcosm.com/dongle_php_protection.php
А в общем придумывать ничего не нужно, так как готовые решение уже, в принципе, имеются: www.microcosm.com/dongle_php_protection.php
Даже пожалел на минуту, что к вам работать не пошел, когда звали.
Из того, что может вам пригодиться:
Для связки Erlang с PHP помимо классических cli и FCGI/HTTP можно попробовать воспользоваться erlang ports www.erlang.org/doc/tutorial/overview.html. Не знаю, насколько это разумная идея, но если удастся запустить — будет очень удобно работать. Для ports есть C-биндинг, соответственно можно написать PHP-шное расширение и на порядок упростить процесс взаимодействия Erlang и PHP. Но тут нужно покопать конечно хорошенько предварительно.
Для Comet можно попробовать socket.io-erlang github.com/yrashk/socket.io-erlang. Разрабатывается хабраюзером yrashk. Говорят, очень годная вещица.
Nginx можно повесить разве-что на поддомене или на другом порту, ибо Comet он не умеет проксировать. Хотя для коробочного решения Nginx, пожалуй, это лишнее.
Еще плюс — вы сможете ВСЕ ваши Erlang приложения запускать (и останавливать/перезапускать) в одном Erlang процессе, вместе с RabbitMQ Yaws/Mochiweb и собратьями. Своего рода операционная система в миниатюре.
Для связки Erlang с PHP помимо классических cli и FCGI/HTTP можно попробовать воспользоваться erlang ports www.erlang.org/doc/tutorial/overview.html. Не знаю, насколько это разумная идея, но если удастся запустить — будет очень удобно работать. Для ports есть C-биндинг, соответственно можно написать PHP-шное расширение и на порядок упростить процесс взаимодействия Erlang и PHP. Но тут нужно покопать конечно хорошенько предварительно.
Для Comet можно попробовать socket.io-erlang github.com/yrashk/socket.io-erlang. Разрабатывается хабраюзером yrashk. Говорят, очень годная вещица.
Nginx можно повесить разве-что на поддомене или на другом порту, ибо Comet он не умеет проксировать. Хотя для коробочного решения Nginx, пожалуй, это лишнее.
Еще плюс — вы сможете ВСЕ ваши Erlang приложения запускать (и останавливать/перезапускать) в одном Erlang процессе, вместе с RabbitMQ Yaws/Mochiweb и собратьями. Своего рода операционная система в миниатюре.
Легче вам начать самим писать, эрланг можно за 2-3 недели подучить и на достаточно адекватном уровне уже понимать и писать.
Найти эрлангиста сложно и их могут переманить в какие-то штуки типа эхи, хероку или мочимедии) На прошлой работе часть (достаточно некритичная) была реализована на эрланге специально нанятым человеком, а потом его сманили. Дима, Привет! =)
А те люди которые были достаточно хороши, чтобы разобраться и поддерживать его код были итак нагружены на 100% и в итоге решение застопорилось на той стадии развитии, на которой было оставлено)
Найти эрлангиста сложно и их могут переманить в какие-то штуки типа эхи, хероку или мочимедии) На прошлой работе часть (достаточно некритичная) была реализована на эрланге специально нанятым человеком, а потом его сманили. Дима, Привет! =)
А те люди которые были достаточно хороши, чтобы разобраться и поддерживать его код были итак нагружены на 100% и в итоге решение застопорилось на той стадии развитии, на которой было оставлено)
не верная гипотеза приводит к неверным результатам…
потому что не умеете его использовать? ваш код изобилует ооп ради ооп? приведу пример схожий, pconnect почему не используется повсеместно — да просто потому что нужно делать free постоянно, так вот в php есть unset!
простите а это что vladimirbarbarosh.blogspot.com/2011/05/compile-php-536-pecl-libevent-004.html?
php demon.php & — не работает хотите сказать :)диспетчер нужен только в случае если процесс упал с концами, вообще не понимаю почему вы пытаетесь применить одну и туже логику запуска приложений для коротко и долгоживущих процессов?
логика другая, оба ваших решения не верные потому что вы рассматриваете php как приложения которые выполняются меньше 30 секунд, внесу ясность:
решение через эрланг:
— пхп скрипт отправляет в событие
— ерланг выбирает из очереди событие
— пхп запускает событие
решение через пхп:
— пхп скрипт отправляет в событие
— пхп выбирает из очереди событие
— пхп запускает событие
в чём разница — принципиально не в чём, просто в первом случае постоянно запущен эрланг, во втором php
поддерживать 1000 соединений одновременно для 1 php процесса не проблема (смотрим на select функции), проблема в том как их обрабатывать одновременно
пока из php не удалили ticks — можно писать просто отличные планировшики
к чему я всё это — алгоритмы примерно одинаковые во всех ЯП и реализации тоже примерно одинаковые, просто нужно уметь пользоваться всем богатством ЯП на котором пишешь, в моем случае это php.
ps erlang = awesome, концепция ЯП просто убойная, для себя нашёл просто кучу отличных идей которые перетащил что смог в php, а let it crash — считаю лучшей методологией для программирования
не верная гипотеза приводит к неверным результатам…
Если исходить из того, что гипотеза не верна, то, конечно же, во всём остальном я с вами соглашусь. Но заметьте, что вы первый, кто поставил её под сомнение. Такая у PHP репутация нехорошая, и, поверьте, она не на пустом месте.
Я не доверю интерпретатору PHP длинные задачи, не буду делать так, чтобы от стойкости php-процесса зависела надёжность всей системы. Не предназначен он для этого. Скорее всего, даже разработчики самого PHP вам скажут то же самое.
Но в принципе спасибо за ваше мнение, я его уважаю. Наверное, если хорошо потрудиться, то можно соорудить что-нибудь более-менее сносное и на чистом PHP. Но я верю, что проще это будет сделать на инструменте, который для подобных задач лучше подходит.
простите а это что vladimirbarbarosh.blogspot.com/2011/05/compile-php-536-pecl-libevent-004.html?
Это какой-то кул-хацкер на коленках что-то скомпилировал. От этого ни phpDaemon, ни php-fpm Windows поддерживать не начали. Но спасибо за наводку, libevent под винду есть — значит не всё потеряно :)
>Но заметьте, что вы первый, кто поставил её под сомнение.
По-моему, достаточно мало людей, которые хотя бы пытались писать полноценные демоны на современном PHP и могли бы аргументированно опровергнуть вашу гипотезу. В большой степени это действительно объясняется репутацией, стереотипами и прочим недоверием, основанных на реальных проблемах в ранних релизах. Но вот в последнее время не встречал объективной критики типа «написали демон на PHP 5.3.2, через день работы и обработки 100500 запросов съел 10Гб ОЗУ и свопа, после чего умер/завис. Вот код — ЧЯДНТ?». То есть аргументированного подтверждения вашей гипотезы тоже нет. Или вы проводили такую работу/исследования/поиски и у вас есть факты, что современный PHP всё ещё не подходит для грамотной разработки демонов? Или, всё же, решение искать альтернативу основано на репутации языка (пускай и справедливо заслуженной когда-то), а не фактах?
По-моему, достаточно мало людей, которые хотя бы пытались писать полноценные демоны на современном PHP и могли бы аргументированно опровергнуть вашу гипотезу. В большой степени это действительно объясняется репутацией, стереотипами и прочим недоверием, основанных на реальных проблемах в ранних релизах. Но вот в последнее время не встречал объективной критики типа «написали демон на PHP 5.3.2, через день работы и обработки 100500 запросов съел 10Гб ОЗУ и свопа, после чего умер/завис. Вот код — ЧЯДНТ?». То есть аргументированного подтверждения вашей гипотезы тоже нет. Или вы проводили такую работу/исследования/поиски и у вас есть факты, что современный PHP всё ещё не подходит для грамотной разработки демонов? Или, всё же, решение искать альтернативу основано на репутации языка (пускай и справедливо заслуженной когда-то), а не фактах?
*5.3.3
Возможно немного переведу тему, но…
То что никто не пытается писать демонов на PHP — это не оправдание PHP и не повод попробовать взять и написать.
Ведь под PHP есть и к GTK библиотеки, но PHP-GTK приложения можно по-пальцам пересчитать.
Вот думаешь — на чем написать GUI-приложение. Набиваешь GTK-python. Тебе 100500 статей с HappyStories, туториалов, рецептов. В репозиториях половина десктопного софта на питонах. Ну и естественно будешь новый проект на нем писать.
Хочешь написать отказоустойчивый сервер. Набиваешь Erlang Server. Там тебе «A Million-user Comet Application with Mochiweb», множество историй, рецептов, примеров… Какой вывод?
Есть конечно исключения, но на то они и исключения!
Т.е. инфраструктура есть, есть куча историй с Happy End. А становиться пионерами редко кто хочет.
То что никто не пытается писать демонов на PHP — это не оправдание PHP и не повод попробовать взять и написать.
Ведь под PHP есть и к GTK библиотеки, но PHP-GTK приложения можно по-пальцам пересчитать.
Вот думаешь — на чем написать GUI-приложение. Набиваешь GTK-python. Тебе 100500 статей с HappyStories, туториалов, рецептов. В репозиториях половина десктопного софта на питонах. Ну и естественно будешь новый проект на нем писать.
Хочешь написать отказоустойчивый сервер. Набиваешь Erlang Server. Там тебе «A Million-user Comet Application with Mochiweb», множество историй, рецептов, примеров… Какой вывод?
Есть конечно исключения, но на то они и исключения!
Т.е. инфраструктура есть, есть куча историй с Happy End. А становиться пионерами редко кто хочет.
А откуда взялись инфраструктура и success story? Кто-то рискнул стать пионером и поделился опытом. Я вовсе не призываю писать демонов на PHP, но вот откидывать такой вариант только из-за «репутации» как-то не объективно, по-моему. Мне тоже хочется написать что-то на Erlang и интуитивно чувствую, что результат будет лучше, но утверждать что он лучше только потому у PHP «плохая карма» я не буду, даже в качестве гипотезы. Напишу прототипы, погоняю их в разных условиях и там буду принимать решение, причём не исключаю, что оно окажется ошибочным из-за слишком большой степени упрощения и допущения прототипов, да и просто из-за моей криворукости.
Доводы вида «Для Erlang/Python есть такая-то инфраструктура, поддерживаемая тысячами разработчиков и не только just for fun, а для PHP её нет или есть, но поддержка производится единицами и из любви к искусству» легко проверить и более-менее объективно оценить их влияние на конечный результат. А как оценить влияние на проект «репутации» я не представляю, по крайней мере с технической точки зрения.
Доводы вида «Для Erlang/Python есть такая-то инфраструктура, поддерживаемая тысячами разработчиков и не только just for fun, а для PHP её нет или есть, но поддержка производится единицами и из любви к искусству» легко проверить и более-менее объективно оценить их влияние на конечный результат. А как оценить влияние на проект «репутации» я не представляю, по крайней мере с технической точки зрения.
Нет, специальных исследований с стресс-тестов для PHP 5.3 я не проводил. Есть только опыт того, что даже в fastcgi иногда приходится всё перезапускать, чтобы оно вздохнуло. Правда больше у нас работал 5.2, но и с 5.3 в последнее время возникают инциденты.
Ну как косвенный аргумент можно привести наличие переменной PHP_FCGI_MAX_REQUESTS или настройки pm.max_requests? В эрланге ничего подобного нет.
Наверное, если бы я был снова студентом и у меня была куча времени на различные интересные исследования, я бы рискнул попробовать писать на PHP всё подряд. Но, видимо, я старею, и начинаю тянуться к надёжности :)
Ну как косвенный аргумент можно привести наличие переменной PHP_FCGI_MAX_REQUESTS или настройки pm.max_requests? В эрланге ничего подобного нет.
Наверное, если бы я был снова студентом и у меня была куча времени на различные интересные исследования, я бы рискнул попробовать писать на PHP всё подряд. Но, видимо, я старею, и начинаю тянуться к надёжности :)
Вот если бы хотя бы вкратце описали инциденты с 5.3 — гипотеза выглядела бы куда более убедительной. Пускай даже на уровне «мы решили не разбираться в чём конкретно проблемы и как их можно исправить или обойти, а решили взять за основу язык/платформу в котором отсутствие этих проблем декларировано и случаев нарушения этой декларации за 10 минут гугления выявлено не было» :)
Для частичного решения ваших проблем подойдет Celery. Это система асинхронного выполнения различных задач, в т.ч. периодических (как cron).
Она как раз использует RabbitMQ в качестве бэкенда и замечательно зарекомендовала себя при работе с python и django.
У нас система на Celery + RabbitMQ полностью заменила cron, добавила возможность
наблюдать за всеми, происходящими асинхронно, джобами, а также добавила много
интересного функционала в web-приложения, например, позволяя запускать задачи и не ждать
их выполнения во время генерации ответа на HTTP запрос, а запрашивать ответ позже,
через ajax.
Не так удобно будет ее использовать с PHP, как с Python (так как там есть встроенная
поддержка django и других фреймворков), но все же это вполне нормальный usecase.
В общем, я советую вам взглянуть в сторону Celery, хотя бы чтобы иметь представление о возможности. Будет больше информации для принятия решений.
Она как раз использует RabbitMQ в качестве бэкенда и замечательно зарекомендовала себя при работе с python и django.
У нас система на Celery + RabbitMQ полностью заменила cron, добавила возможность
наблюдать за всеми, происходящими асинхронно, джобами, а также добавила много
интересного функционала в web-приложения, например, позволяя запускать задачи и не ждать
их выполнения во время генерации ответа на HTTP запрос, а запрашивать ответ позже,
через ajax.
Не так удобно будет ее использовать с PHP, как с Python (так как там есть встроенная
поддержка django и других фреймворков), но все же это вполне нормальный usecase.
В общем, я советую вам взглянуть в сторону Celery, хотя бы чтобы иметь представление о возможности. Будет больше информации для принятия решений.
Celery весьма и весьма интересная штука, у нас тоже используется с Pylons. Из плюсов: очень простое API и хорошая интеграция с фреймворками, плюс очень сильный ВАУ-эффект (типа «как я жил без этого раньше?») НО:
1) У меня почему то часто появляются Zomby — процессы. Иногда пул воркеров намертво зависает.
2) Применительно к статье Celery — это необходимость завязки на Python и необходимость держать MQ демона. Для коробки усложняется установка, настройка и поддержка.
3) Все-таки до Erlang ему далеко. Честно. В erlang есть коммуникация между «тасками» (в Celery они довольно-таки изолированные) и можно запускать задачи тысячами (в Celery больше 20-30 воркеров не запускают на одной машине) и еще куча всего интересного.
В минусы Erlang пожалуй сложнее или непривычнее описывать нетривиальную логику, но тут мнения могут не совпадать.
1) У меня почему то часто появляются Zomby — процессы. Иногда пул воркеров намертво зависает.
2) Применительно к статье Celery — это необходимость завязки на Python и необходимость держать MQ демона. Для коробки усложняется установка, настройка и поддержка.
3) Все-таки до Erlang ему далеко. Честно. В erlang есть коммуникация между «тасками» (в Celery они довольно-таки изолированные) и можно запускать задачи тысячами (в Celery больше 20-30 воркеров не запускают на одной машине) и еще куча всего интересного.
В минусы Erlang пожалуй сложнее или непривычнее описывать нетривиальную логику, но тут мнения могут не совпадать.
Спасибо за наводку, посмотрю.
Пробовал эту celery на достаточно ненагруженном проектике (десяток воркеров лопатят круглые сутки примерно по таске в секунду).
Не советую!
То воркеры зависают, то память кончается, то выходит очередная новая версия celery с парой пофикшенных багов, а заодно и с новым (несовместимым) форматом конфига.
В результате оказалось проще выкинуть celery и самолично написать на базе Redis и сотни строк питонячего кода простую систему очередей, коя и работает у меня уже больше полугода без единого зависания.
Не советую!
То воркеры зависают, то память кончается, то выходит очередная новая версия celery с парой пофикшенных багов, а заодно и с новым (несовместимым) форматом конфига.
В результате оказалось проще выкинуть celery и самолично написать на базе Redis и сотни строк питонячего кода простую систему очередей, коя и работает у меня уже больше полугода без единого зависания.
Соглашась с многими отписавшимся, что лучше все-таки переписать код на новый фреймворк, ведь все алгоритмы есть, и реализовать их уже на конкретном языке не проблема.
От себя посоветую node.js который успешно работает с потоками, да и к тому же не надо ничего знать кроме javascript… А в данном случае нужно еще php и erlang. Зачем три языка там где можно использовать один?
От себя посоветую node.js который успешно работает с потоками, да и к тому же не надо ничего знать кроме javascript… А в данном случае нужно еще php и erlang. Зачем три языка там где можно использовать один?
1. Самый главный аргумент, почему это не будет работать: тест скорости параллельной записи и чтения событий с php в RabbitMQ показывает дико медленные числа. Порядка 3000-5000 записей+чтений в секунду на одной мощной тачке. Поэтому все возможности ребита по обработке 200.000-800.000 сообщений в секунду из-за оверхеда в php extension полностью исчезают. Банальная очередь на Redis'е большие числа дает (но, разумеется, в ней нед подписки). Прежде, чем писать статьи и грозные комменты к статье — померьте скорость :)
Если и выбирать для пхп сервер очередей — то не RabbitMQ, а что-нибудь другое. Это слишком глючная, тормозная и не рабочая связка. И конечно ребит ничем не лучше другого софта — при избытке непрочитанных сообщений уходит в своп и жестко сыпится.
2. Я может плохо читал… но на Эрланге есть готовый веб-сервер. Там один процесс (эрланга) держит один коннект. Все велосипеды собственно придуманы и реализованы много лет назад. Используйте его. Нафига городить огород с ПХП, понять не могу?
3. Как-то однобоко описана проблема крон скриптов. У нас имеется большой пул application-серверов и такой же большой пул cron-серверов. Но не в том смысле, что вы подумали! Как устроены крон скрипты:
а) это обычные php скрипты, работающие в среднем по 10 минут
б) по факту, никаких утечек памяти в пхп нет, даже если циклом создавать и уничтожать миллиард объектов (но они могут быть, поэтому скрипты, на всякий случай, дольше 10 минут не работают)
в) все скрипты всегда запущены… например, под задачу «А» всегда запущены 5 копий одного скрипта
г) когда крон-менеджер решает, что текущий скрипт превысил 10 минут, тот завершается, мгновенно запуская свою копию (т.е. никаких ожиданий 1-59 секунд от системного crontabа нет, последний нужен только, если скрипт свалится в корку и при перезагрузке всего сервера)… разумеется, прогнозируя свое скорое завершение, скрипт перестает принимать новые данные и обрабатывает накопленные
д) cron-скрипт ничем не отличается от application-скрипта, только первый принимает события из очереди (memcacheQ / redis), а не от веб-браузера
В итоге выходит полная эмуляция демонов и прочей ненадежной фигни штатными простыми средствами с обычной логикой приложения.
4. В задачах, когда бразуер очень часто должен получать данные (чат, онлайн мессенджер) существуют модули под nginx для доступа к memcacheD и memcacheQ. Пришел AJAX запрос, nginx отправил его в свой модуль (написан на С), тот принял постом данные от браузера и отправил сообщения в очередь, одновременно в JSON виде ответил браузеру, прочитав заранее подготовленный ключ в memcacheD. Все это без пхп! Не нужно никакой мути в виде демонов и комитов. Все запросы на чтение данных («нет в ли чате новых сообщения?») приходят в браузер минуя пхп полностью! Пхп занимается лишь приемом новых текстовых сообщений от человека в чат + разбором очереди от браузера (тот отчитывается, что жив, читает сообщения и т.д. — через очередь). И разумеется фоновые крон-скрипты (по методологии выше) занимаются формированием нужных ключей в мемкеше, которые запрашиваются браузером. Например, пришло новое сообщение в чат — нужно модифицировать десяток-сотню ключей в мемкеше для всех пользователей, которые сидят в этом чате. После этого не важно — будут те ключи читаться браузером или нет. Мы их один раз сформировали и до нового текстового сообщения ничего не делаем.
Ни одного лишнего компонента не используется, кроме традиционных php-fpm, nginx, модуль к nginx, memcache.
Если и выбирать для пхп сервер очередей — то не RabbitMQ, а что-нибудь другое. Это слишком глючная, тормозная и не рабочая связка. И конечно ребит ничем не лучше другого софта — при избытке непрочитанных сообщений уходит в своп и жестко сыпится.
2. Я может плохо читал… но на Эрланге есть готовый веб-сервер. Там один процесс (эрланга) держит один коннект. Все велосипеды собственно придуманы и реализованы много лет назад. Используйте его. Нафига городить огород с ПХП, понять не могу?
3. Как-то однобоко описана проблема крон скриптов. У нас имеется большой пул application-серверов и такой же большой пул cron-серверов. Но не в том смысле, что вы подумали! Как устроены крон скрипты:
а) это обычные php скрипты, работающие в среднем по 10 минут
б) по факту, никаких утечек памяти в пхп нет, даже если циклом создавать и уничтожать миллиард объектов (но они могут быть, поэтому скрипты, на всякий случай, дольше 10 минут не работают)
в) все скрипты всегда запущены… например, под задачу «А» всегда запущены 5 копий одного скрипта
г) когда крон-менеджер решает, что текущий скрипт превысил 10 минут, тот завершается, мгновенно запуская свою копию (т.е. никаких ожиданий 1-59 секунд от системного crontabа нет, последний нужен только, если скрипт свалится в корку и при перезагрузке всего сервера)… разумеется, прогнозируя свое скорое завершение, скрипт перестает принимать новые данные и обрабатывает накопленные
д) cron-скрипт ничем не отличается от application-скрипта, только первый принимает события из очереди (memcacheQ / redis), а не от веб-браузера
В итоге выходит полная эмуляция демонов и прочей ненадежной фигни штатными простыми средствами с обычной логикой приложения.
4. В задачах, когда бразуер очень часто должен получать данные (чат, онлайн мессенджер) существуют модули под nginx для доступа к memcacheD и memcacheQ. Пришел AJAX запрос, nginx отправил его в свой модуль (написан на С), тот принял постом данные от браузера и отправил сообщения в очередь, одновременно в JSON виде ответил браузеру, прочитав заранее подготовленный ключ в memcacheD. Все это без пхп! Не нужно никакой мути в виде демонов и комитов. Все запросы на чтение данных («нет в ли чате новых сообщения?») приходят в браузер минуя пхп полностью! Пхп занимается лишь приемом новых текстовых сообщений от человека в чат + разбором очереди от браузера (тот отчитывается, что жив, читает сообщения и т.д. — через очередь). И разумеется фоновые крон-скрипты (по методологии выше) занимаются формированием нужных ключей в мемкеше, которые запрашиваются браузером. Например, пришло новое сообщение в чат — нужно модифицировать десяток-сотню ключей в мемкеше для всех пользователей, которые сидят в этом чате. После этого не важно — будут те ключи читаться браузером или нет. Мы их один раз сформировали и до нового текстового сообщения ничего не делаем.
Ни одного лишнего компонента не используется, кроме традиционных php-fpm, nginx, модуль к nginx, memcache.
Насчёт 4) можно уточнить? А как гарантируется, что каждое сообщение будет прочитано каждым получателем? Или просто старые сообщения вытесняются в мемкеше, подразумевая, что они никому уже не интересны?
Гарантируется тем, что JS браузера будет каждые пару секунд долбиться в nginx (т.е. в свое персональное memcache поле) и читать от туда пачку последних сообщений. Если он не обратился туда — его проблема. Если браузер подвис и при очередном чтении в поле обнаружил пропуск данных — идет инициализация всего списка сообщений. В общем есть 2 четких стадии: инициализация при первом входе (выполняется пхп), поддержания актуальности при живом окне браузера с JS (nginx+memcache).
Если делать тоже самое на очередях, то будет так: мы кинули важное сообщение в очередь, браузер прочитал его, связь накрылась, данные не пришли (и с сервера очередей оно удалено). При повтором чтении данных уже не будет. Это небольшая проблема. А если же эти данные, но с избытком (т.е. с небольшим списком более старых сообщений) просто положить в поле мемкешу — то будет не важно, сколько раз его прочитает браузер. Они «потеряются», только если появятся более свежии данные (сообщения), вытесняющие старые. В таком подходе все четко делится на не связанные между собой компоненты проекта.
Если делать тоже самое на очередях, то будет так: мы кинули важное сообщение в очередь, браузер прочитал его, связь накрылась, данные не пришли (и с сервера очередей оно удалено). При повтором чтении данных уже не будет. Это небольшая проблема. А если же эти данные, но с избытком (т.е. с небольшим списком более старых сообщений) просто положить в поле мемкешу — то будет не важно, сколько раз его прочитает браузер. Они «потеряются», только если появятся более свежии данные (сообщения), вытесняющие старые. В таком подходе все четко делится на не связанные между собой компоненты проекта.
Похоже, Фабьен прочитал эту статью
twitter.com/fabpot/status/75524423599403008
twitter.com/fabpot/status/75524423599403008
Совсем недавно скрипт на php у нас плодотворно работал 2 недели нон-стоп — конвертил огромную базу. Поначалу валился, упираясь в память, пока не переписали с применением форков для обработки данных пачками.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Моделируем полёт PHP на крыльях Erlang