статья хорошая, многим начинающим будет полезна.
Одна из причин выбора этого хранилища данных в продакшен — это поддержка и хорошая гибкость храниок.
Редис в этом плане немного отстает. Сам использую тарантул более 2х лет.
Летняя школа Майкрософт по структурам данных тоже требует опубликованные работы или приветствует реферат на эту тему. Без «собственной идеи» соваться не стоит, но рискнуть всегда нужно. Как говориться, кто не рискует — сушит горло. Я рискнул и мне повезло… Повезло, что тема совпала с интересами Института. Все лето занимался исследованиями в Австрии.
Так что высаси из пальца идею и опиши ее. Вдруг повезет. А нужна публикация по теме, всегда можно найти, где её опубликовать. Думаю, это не самая большая проблема
Теоретически, конечно язык не причем. Лучше знаем РНР, значить лучше понимаем алгоритмы именно на этом языке. В этом смысле статья безупречная.
Что я хотел сказать — то именно практическое внедрение на РНР меня не устраивает. Прикладное использование графов требует русурсоемкости, и если это реализовывать на РНР, то это либо должен быть тяжелый и долгий бэкграунд, либо просто будет вылетать по таймауту или памяти.
Я понимаю, что минусуют те, кто с графами и расписаниями не имел дело.
использовать симфони в проектах с высокой нагрузкой — это уже извращение.
>Requests per second: 40.14 [#/sec] у меня почти в два раза меньше показывает и без HipHop
в целом статья хорошая — спасибо за грабли, хотя у каждого они свои, но всё же — постараюсь не наступать…
>mysql_connect() is blocking only
можно его переписать на неблокирующий режим,
можно предварительно открыть не блокируемый сокет и самостоятельно, но к сожалению mysql_connect() — это больше чем просто коннект. Проще не трогать,
да и вообще, всегда и даже в моем маленьком примере первоначально создается пул коннекций, а потом параллельно начинаем выполнять запросики.
>I don’t know if mysql_use_result() can be return EAGAIN easily
состояние EAGAIN можно отлавливать непосредственно в libev,
я эту задачу решал 10 лет назад, путем формированием собственного xml, который весил раз в двадцать пять меньше CommerceML. Время парсинга этого файла у мменя занимало не более минут. Был каталог нескольких тысяч наименований.
Далее, я пытался сохранять предыдущие товарные позиции и слал только дифы в том же xml. Благо, я использовал msxml как инструмент создания xml и транспорт. С Дифами выходило хуже, но что-то уже получалось.
Изменения (дифы) были следующие:
— товар временно отсутствовал
— изменилась цена
— добавилась новая товарная позиция.
в общем — это дела давно минувших дней и многие ньюансы уже позабылись.
что касается формата JSON то в эпоху РНР 3, всеми любимого нами расширения php_json не было, ну не текст же парсить :).
да, согл — но это уже лучше чем ничего.
mysql_use_result для асинхронного выполнения запросов не совсем подходит.
мой коллега пошел по более простому пути,
он переопределил функцию my_init() — т.е. определил свою с этим же именем и написал частично свой код, в которой реализовал неблокируемый mysql_connect() и реализовал асинхронность с помощью коротин (pcl).
во первых, ни какого велосипеда с очередями нет — это устоявшийся паттерн.
во вторых — это виртуальный хостинг, и хостер предоставляет только доступ к БД, без её администрирования. Да, в какой-то степени это большой минус…
если буду писать статью про демоны, то будет про принципы их написание на Си,
а не про конкретные демоны. Если данный вопрос интересен, то могу написать.
интересно сколько Бог убил котят при написании «РНР Котят»
Возможно по этому еще и не открыли код.
Одна из причин выбора этого хранилища данных в продакшен — это поддержка и хорошая гибкость храниок.
Редис в этом плане немного отстает. Сам использую тарантул более 2х лет.
странно, что ты не нашел это на Хабре
Так что высаси из пальца идею и опиши ее. Вдруг повезет. А нужна публикация по теме, всегда можно найти, где её опубликовать. Думаю, это не самая большая проблема
Что я хотел сказать — то именно практическое внедрение на РНР меня не устраивает. Прикладное использование графов требует русурсоемкости, и если это реализовывать на РНР, то это либо должен быть тяжелый и долгий бэкграунд, либо просто будет вылетать по таймауту или памяти.
Я понимаю, что минусуют те, кто с графами и расписаниями не имел дело.
и потом проверял бы на дублирование
>Requests per second: 40.14 [#/sec] у меня почти в два раза меньше показывает и без HipHop
в целом статья хорошая — спасибо за грабли, хотя у каждого они свои, но всё же — постараюсь не наступать…
давно собирался перевести часть проектов на HPHP
можно его переписать на неблокирующий режим,
можно предварительно открыть не блокируемый сокет и самостоятельно, но к сожалению mysql_connect() — это больше чем просто коннект. Проще не трогать,
да и вообще, всегда и даже в моем маленьком примере первоначально создается пул коннекций, а потом параллельно начинаем выполнять запросики.
>I don’t know if mysql_use_result() can be return EAGAIN easily
состояние EAGAIN можно отлавливать непосредственно в libev,
Далее, я пытался сохранять предыдущие товарные позиции и слал только дифы в том же xml. Благо, я использовал msxml как инструмент создания xml и транспорт. С Дифами выходило хуже, но что-то уже получалось.
Изменения (дифы) были следующие:
— товар временно отсутствовал
— изменилась цена
— добавилась новая товарная позиция.
в общем — это дела давно минувших дней и многие ньюансы уже позабылись.
что касается формата JSON то в эпоху РНР 3, всеми любимого нами расширения php_json не было, ну не текст же парсить :).
mysql_use_result для асинхронного выполнения запросов не совсем подходит.
мой коллега пошел по более простому пути,
он переопределил функцию my_init() — т.е. определил свою с этим же именем и написал частично свой код, в которой реализовал неблокируемый mysql_connect() и реализовал асинхронность с помощью коротин (pcl).
во вторых — это виртуальный хостинг, и хостер предоставляет только доступ к БД, без её администрирования. Да, в какой-то степени это большой минус…
а не про конкретные демоны. Если данный вопрос интересен, то могу написать.