Тоже apc.stat=0, но мы его не сбрасываем, потому, что у нас каждый деплой идет в другую директорию (весь проект где-то 20MB весит в памяти).
А еще у нас один include_path, переопределенный Zend_Autoloader и ни одного require_once — для того, чтобы использовать только абсолютные пути.
Кстати, если apc.stat=0, при удалении файла, он это замечает. Тоесть, всетаки, смотрит сволочь в файловую систему.
Еще пробовали загнать весь код проекта в ramfs — дало копейки, отказались.
Мы тоже это обнаружили недавно. Сейчас phing-ом генерится php конфиг через var_export, и он отличненько укладывается в APC opcode. Еще кэшируем роуты.
Вообще, блин, руки чешутся закэшировать весь Application вместе с Di к чертям. А вообще, в идеале, вообще не выключать php, чтобы он работал, как демон (он у нас так на бэкграунде работает). Но это мечты.
Кстати, у архитектуры наших Zend приложений общие предки (Гоша) :)
Вопрос монетизации уже подробно обсуждался в нашем проекте. Могу пока только сказать, что он будет весьма не стандартным. Но до этого нужно еще дорости.
В Eventr есть один главный момент — люди. Я лично читаю 50 потоков, из них 40 — люди, и только 10 фидов. И то, из этих 10ти — 5 мои внешние блоги, для копирования в свой ивентр поток.
Вот реальная практика использования Eventr. Это офигенно удобно. Но должно пройти время, пока люди это прочувствуют.
Чиним.
Это связано с тем, что у Вас есть папка, в которой более 50ти потоков внутри. В сестеме стоит ограничение — после следующего деплоя кот уйдет, а Вам прийдет автоматическое письмо.
> Такой цифры, так как потокам выдается динамический приоритет. Только мы используем приоритет не по читаемости, а по обновляемости. Минимум каждый поток обновляем раз в сутки.
У нас некоторые потоки обновляются каждые 5 минут, максимум — раз в час. Тоесть, за час все (уже 21 тысяча) проходят обновление — совсем другие цифры.
Ваши пользователи не жаловались на задержки обновления?
P.S. pubsubhubbub не за горизонтом, уже многие его используют, и мы тоже будем.
> который в пике спокойно справлялся с 40 000 потоков
сколько потоков в секунду вы обновляли?
Да, мест для оптимизации хватает.
Сейчас, одна из важных задач — определять мение читаемые потоки, чтобы снижать их приоритет. По моим подсчетам, можно повысить производительность в 10 раз.
> постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
не совсем так, но это мы будем делать совсем скоро.
Mongodb у нас изначально был master-master, он полноценно не поддерживается, но покрывал наши нужды.
С момента, когда с ним начали происходить неведомые вещи (от нагрузки отставала синхронизация, а поскольку она двусторонняя, ее сложно восстановить), сделали master-slave.
Да, ограничений на шардинг достаточно, но в нашем случае, нужно будет шардить только одну самую большую коллекцию — Entry. Даже с этими ограничениями уже можем.
Возможно, мы будем использовать Riak для других целей. А пока что, mongodb отлично справляется со своей задачей. Даже слишком.
С момента публикации статьи со скрежетом выполнилось 70 импортов общей сложностью в 4,458 фидов. Самое жестокое, что все они добавились практически одновременно.
А еще у нас один include_path, переопределенный Zend_Autoloader и ни одного require_once — для того, чтобы использовать только абсолютные пути.
Кстати, если apc.stat=0, при удалении файла, он это замечает. Тоесть, всетаки, смотрит сволочь в файловую систему.
Еще пробовали загнать весь код проекта в ramfs — дало копейки, отказались.
Вообще, блин, руки чешутся закэшировать весь Application вместе с Di к чертям. А вообще, в идеале, вообще не выключать php, чтобы он работал, как демон (он у нас так на бэкграунде работает). Но это мечты.
Кстати, у архитектуры наших Zend приложений общие предки (Гоша) :)
Все еще будет, у нас планы на два года вперед ;)
Вот реальная практика использования Eventr. Это офигенно удобно. Но должно пройти время, пока люди это прочувствуют.
Это связано с тем, что у Вас есть папка, в которой более 50ти потоков внутри. В сестеме стоит ограничение — после следующего деплоя кот уйдет, а Вам прийдет автоматическое письмо.
Но важность некоторых новостей может исчисляться в минутах, как ни крути.
Уже посчитали, 20% потоков можно обновлять в 5 раз реже, 60% — в 10 раз реже.
Так или иначе, RSS скоро уйдет на второй план в Eventr. А родные потоки обновляются моментально.
У нас некоторые потоки обновляются каждые 5 минут, максимум — раз в час. Тоесть, за час все (уже 21 тысяча) проходят обновление — совсем другие цифры.
Ваши пользователи не жаловались на задержки обновления?
P.S. pubsubhubbub не за горизонтом, уже многие его используют, и мы тоже будем.
ukrindex, ukrtelecom
сколько потоков в секунду вы обновляли?
Да, мест для оптимизации хватает.
Сейчас, одна из важных задач — определять мение читаемые потоки, чтобы снижать их приоритет. По моим подсчетам, можно повысить производительность в 10 раз.
> постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
не совсем так, но это мы будем делать совсем скоро.
С момента, когда с ним начали происходить неведомые вещи (от нагрузки отставала синхронизация, а поскольку она двусторонняя, ее сложно восстановить), сделали master-slave.
Да, ограничений на шардинг достаточно, но в нашем случае, нужно будет шардить только одну самую большую коллекцию — Entry. Даже с этими ограничениями уже можем.
Возможно, мы будем использовать Riak для других целей. А пока что, mongodb отлично справляется со своей задачей. Даже слишком.
переместите, пожалуйста, это обсуждение сюда.