Комментарии 93
хотелось бы подробностей по поводу физических серверов, какая конфигурация?
>Zend_Date. Zend_View partial и placeholder
Да-да, веселые проблемы с ними при нагрузках
Да-да, веселые проблемы с ними при нагрузках
Первая ошибка — web инстанс (nginx, php-fpm) на более слабом сервере
то есть это связка не подходит под высокие нагрузки именно на слабом железе? либо вообще не подходит под хайлоад?
у вас ошибка еще в том что у вас вертикальная масштабирование, горизонтальное дает бОльший прирост производительности. ну это если деньги конечно на сервера. так же непонятно почему не было сделано нагрузочное тестирование проекта. вы пишите о том что база пустая — так нужно было закинуть туда данных на 100-200к пользователей, на каждого по 10-20 фидов и потестировать как это все работает.
Web перенесли на более мощный сервер — единственное «вертикальное» действие, сделанное нами.
1. Добавили web2 — горизонтально
2. Разнесли очереди на четыре сервера — горизонтально
3. Mongodb будем масштабировать только горизонтально
4. Redis — горизонтально
Нагрузочное тестирование проводилось, но не дало особых результатов (читайте последний абзац в статье). Зачем тратить время и деньги на фигню, если можно протестировать систему с реальными людьми, и получить реальную статистику?
1. Добавили web2 — горизонтально
2. Разнесли очереди на четыре сервера — горизонтально
3. Mongodb будем масштабировать только горизонтально
4. Redis — горизонтально
Нагрузочное тестирование проводилось, но не дало особых результатов (читайте последний абзац в статье). Зачем тратить время и деньги на фигню, если можно протестировать систему с реальными людьми, и получить реальную статистику?
тестирование нагрузочное, интерграционное, регрессивное, юнит это далеко не фигня… вы заставили пользователей видеть ваши сбои. вы заставили пользователей быть нагрузочным тестированием.
правильное тестирование ВСЕГДА дает результат, а вы его сделали наверное плохо. в итоге вы легли всего на 3к юзеров. это вообще копейки.
я думаю что при более серьезном подходе к тестированию вы бы могли выдержать 100-200к юзеров, либо были бы готовы к контролируемым перегрузкам на таких обьемах.
3к юзеров это не хабраэффект. это детская нагрузочка.
правильное тестирование ВСЕГДА дает результат, а вы его сделали наверное плохо. в итоге вы легли всего на 3к юзеров. это вообще копейки.
я думаю что при более серьезном подходе к тестированию вы бы могли выдержать 100-200к юзеров, либо были бы готовы к контролируемым перегрузкам на таких обьемах.
3к юзеров это не хабраэффект. это детская нагрузочка.
Хабраэффектом были не 3000 юзеров, а скорее сотни фидов, которые эти пользователи стали импортировать из google reader и просто добавлять руками, насколько я понял из статьи.
Вы правы. Тысячи фидов.
и что разработчик по-вашему не понимал что 1 юзер может загрузить больше одного фида ?:) надо было ориентироваться минимум на 10 фидов на одного юзера. итого 30к фидов. тестировать надо было :) но разработчик считает что тестирование это фигня. это его право.
Тут, имхо, дело не в отсутствии тестирования, а в слишком пессимистичном определении оптимистичного количества пользователей (и/или их поведения). Я вот зарегался без особых проблем, и не на один фид не подписался (поскольку разочаровался в «традиционных» ридерах, включая, но не ограничиваясь, гугловским, а за эти несколько дней фидов, достойных подписки, не встречал — хабр и подобные ресурсы считаю нужным читать вживую, через рефреш в постоянно открытых вкладках) — это же не значит, что надо ориентироваться на меня?
В Eventr есть один главный момент — люди. Я лично читаю 50 потоков, из них 40 — люди, и только 10 фидов. И то, из этих 10ти — 5 мои внешние блоги, для копирования в свой ивентр поток.
Вот реальная практика использования Eventr. Это офигенно удобно. Но должно пройти время, пока люди это прочувствуют.
Вот реальная практика использования Eventr. Это офигенно удобно. Но должно пройти время, пока люди это прочувствуют.
да кстати — веб лучше балансировать через днс, поставить 2-3 сервера — им по ипу каждому, и пусть днсы где висят ваши домены через свои round-robin алгоритмы балансируют нагрузку между 3-я серверами. вышло бы лучше и эффективнее
nginx upstream разумней
нет не разумней, вернее не всегда. простой пример
у вас 100к коннектов в секунду и 51 сервер — 1 под нгникс с upstream и 50 бекендов — бекенды успеют обработать такую нагрузку например. а вот сервер нгникс не сможет выдержать такой поток — он будет бутылочным горлышком.
поэтому разумнее использовать балансировку на днс — они раскинут 100к коннектов на 51 машину — и все обработается прекрасно.
у вас 100к коннектов в секунду и 51 сервер — 1 под нгникс с upstream и 50 бекендов — бекенды успеют обработать такую нагрузку например. а вот сервер нгникс не сможет выдержать такой поток — он будет бутылочным горлышком.
поэтому разумнее использовать балансировку на днс — они раскинут 100к коннектов на 51 машину — и все обработается прекрасно.
вы где-нибудь видели балансировку по 50-ти адресам? =)
скорее, при действительно большой нагрузке, схема будет выглядеть как балансировка днс'ом на пару хостов + nginx upstream с бекэндами
а теперь представьте, 1-5 нод «легли», ДНС будет отправлять туда — там глухо, сайт не доступен
nginx умнее, он отправит на другую ноду
скорее, при действительно большой нагрузке, схема будет выглядеть как балансировка днс'ом на пару хостов + nginx upstream с бекэндами
а теперь представьте, 1-5 нод «легли», ДНС будет отправлять туда — там глухо, сайт не доступен
nginx умнее, он отправит на другую ноду
а кто вам сказал что днс не умеет определять мертвые ноды? ставится обычное слежение за нодами раз в минуту — а если 1-5 нод легли — убираем их из днс на время пока не поднимутся.
далее все же зависит от нагрузки на сервера нгинкс — само собой один может обслуживать 5-6 бекендов если силенок хватит. а вот если не хватит — будет плохо.
+ резервирование нод никто не отменял. хотя такие масштабы и мощности применяются в проектах которые стоят очень дорого.
я лишь хотел показать что нгинкс при большой нагрузке и много бекендов к нему может стать бутылочным горлышком и нужно применять другие схемы балансировки
далее все же зависит от нагрузки на сервера нгинкс — само собой один может обслуживать 5-6 бекендов если силенок хватит. а вот если не хватит — будет плохо.
+ резервирование нод никто не отменял. хотя такие масштабы и мощности применяются в проектах которые стоят очень дорого.
я лишь хотел показать что нгинкс при большой нагрузке и много бекендов к нему может стать бутылочным горлышком и нужно применять другие схемы балансировки
Чем не нравится балансировка через DNS — «тупые клиенты», кэширующие ответы DNS, да ещё использующие только первый IP из ответа — нода умерла, юзер жмёт «обновить» (или скрипт повторяет запрос), но ответа не получит, пока нода не поднимется, хотя ещё 50 нод стоят и ждут когда же их кто-нить запросит
почитайте спецификацию wininet — и вы увидите что при попытке достучаться на домен будут перебирать все ипы которые выданы в днс.
например у нас есть 50 нод — мы в резолв домены выдаем 3-5 — итого
1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.1.5
так вот если первая нода недоступна — вининет автоматически будет коннектится на второй ип
вероястность того что все выданные 5 нод неработащие при управляемом днс составляет 1/50 ^5 — т.е вероятность неработы каждой ноды в степени 5.
согласитесь — вероятность очень мала
например у нас есть 50 нод — мы в резолв домены выдаем 3-5 — итого
1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.1.5
так вот если первая нода недоступна — вининет автоматически будет коннектится на второй ип
вероястность того что все выданные 5 нод неработащие при управляемом днс составляет 1/50 ^5 — т.е вероятность неработы каждой ноды в степени 5.
согласитесь — вероятность очень мала
Осталось только, всего то, заиметь 50 нод. Эдак, на $20,000.
В случае, если разработчик клиента следовал спецификации :) В популярных браузерах наверняка так, но встречалось, что на старый IP ещё неделями приходили запросы от, наверное, всяких грабберов и автосабмиттеров (хотя два IP выдавалось перед этим с месяц)
его и используем сейчас
Capistrano, конечно, хорош.
Но я бы советовал вам использовать Chef. Для горизонтального развёртывания очень удобно.
jztalk.com/blogger/2010/03/05/automated-deployment-systems-push-vs-pull/
Но я бы советовал вам использовать Chef. Для горизонтального развёртывания очень удобно.
jztalk.com/blogger/2010/03/05/automated-deployment-systems-push-vs-pull/
Eventr находится сейчас в закрытом бэта-тестировании. Это не релиз. Просим пользователей отнестись с пониманием, если что-то не работает. Мы знаем и исправляем.
Спасибо, очень интересно :) Такой вопрос — если бы знали заранее, как оно будет работать, переписали бы веб-инстанс целиком на node?
Нет, бизнес-логику на node писать не удобно — мое мнение.
попробуйте связку haxe-node.js
groups.google.com/group/haxe-nodejs/web/haxe-node-getting-started
очень хороша.
groups.google.com/group/haxe-nodejs/web/haxe-node-getting-started
очень хороша.
НЛО прилетело и опубликовало эту надпись здесь
это мне вопрос или товарищу выше? ))
NodeJS еще очень сырой для реализации приложений со сложной бизнес-логикой. Его асинхронные преимущества не могут не радовать, но их, при этом, сложнее тестировать, т.е. любой кусок кода становится неоднозначным. Во время разработки нужно анализировать больше зависимостей, чем в том же линейном php.
В вашем случае, преимущество nodejs как раз не в риалтайме, а в ресурсах и персистентности. Вы ведь можете легко масштабировать ваши приложения по мере возрастания нагрузки. Например, все 20 приложений могут работать на одном nodejs инстансе (один другому не мешая), в последствии, количество nodejs процессов можно увеличивать, раскидывать по физическим серверам, повышая при этом производительность. И даже порты разные не нужны, ведь для этого есть хосты.
Однозначно — если ваши приложения имеют нетривиальную модель, с nodejs вам будет сложновато организовать удобную инфраструктуру… имхо, JS код вообще сложно организовать :) Но тут уже все зависит от ваших архитектурных талантов.
В вашем случае, преимущество nodejs как раз не в риалтайме, а в ресурсах и персистентности. Вы ведь можете легко масштабировать ваши приложения по мере возрастания нагрузки. Например, все 20 приложений могут работать на одном nodejs инстансе (один другому не мешая), в последствии, количество nodejs процессов можно увеличивать, раскидывать по физическим серверам, повышая при этом производительность. И даже порты разные не нужны, ведь для этого есть хосты.
Однозначно — если ваши приложения имеют нетривиальную модель, с nodejs вам будет сложновато организовать удобную инфраструктуру… имхо, JS код вообще сложно организовать :) Но тут уже все зависит от ваших архитектурных талантов.
Кое-что забыл:
Не знаю, как с MySQL, но с mongodb из nodejs работать не очень удобно. Даже суперский mongoose, и тот сделан вообще не очевидно, хотя вроде бы и был создан для того, чтобы облегчить работу с mongo.
Вот с redis, например, работать легко и приятно.
Не знаю, как с MySQL, но с mongodb из nodejs работать не очень удобно. Даже суперский mongoose, и тот сделан вообще не очевидно, хотя вроде бы и был создан для того, чтобы облегчить работу с mongo.
Вот с redis, например, работать легко и приятно.
НЛО прилетело и опубликовало эту надпись здесь
> какое-то небольшое приложение на Node.js, которое в асинхронном режиме запускает 1 из 20 приложений для обработку запроса, а вот оно уже в своей физической папке с всеми зависимостями лежит %)
Именно так. А вот сами приложения — это по сути модули, которым передается дальнейшее упревление запросом.
Но это в случае, если ваши приложения хоть в чем-то однотипные, конечно же.
Именно так. А вот сами приложения — это по сути модули, которым передается дальнейшее упревление запросом.
Но это в случае, если ваши приложения хоть в чем-то однотипные, конечно же.
Апач как я полагаю вы вообще не используете?
мне до сих пор не понятно почему eventr.com/username
пишет «В этом потоке пока нет записей. Теперь, вы можете сохранять сюда записи с источников, которые читаете»
А при этом записи в stream есть.
пишет «В этом потоке пока нет записей. Теперь, вы можете сохранять сюда записи с источников, которые читаете»
А при этом записи в stream есть.
И вдогонку. Как все папки/потоки перенести в мой основной поток eventr.com/username? Можно ли сейчас такое?
Не совсем понятно, что Вы имеете ввиду, говоря «stream»…
Господа,
переместите, пожалуйста, это обсуждение сюда.
переместите, пожалуйста, это обсуждение сюда.
кто-то загрузил импорт на 832 фида О_о
С момента публикации статьи со скрежетом выполнилось 70 импортов общей сложностью в 4,458 фидов. Самое жестокое, что все они добавились практически одновременно.
а чем он принципиально отличается от того же гугл-ридера? как вы собираетесь с ними конкурировать и как монетизировать проект?
Достаточно широкий ответ тут: habrahabr.ru/blogs/startup/98797/
Для меня отличие от гугл-ридера в первую очередь — это русскоязычная команда разработчиков и продукт в бета-тестировании. Разве это не отличный шанс повлиять на создание удобного сервиса? :) А ребятам спасибо! Очень надеюсь что проект будет развиваться и приносить радость своим создателям :)
НЛО прилетело и опубликовало эту надпись здесь
Ради таких статей еще стоит захаживать на хабр :) Спасибо.
я так понимаю mongodb у вас в master-slave репликации. как будете дальше масштабировать? нормального механизма шардинга вроде у монго еще нет, планируется в версии 1.6. а вручную все данные неудобно переносить.
я пока смотрю в сторону Riak, там горизонтальное масштабирование очень прозрачно. добавляется новый нод и все. данные растекаются по нодам. единственный минус Riak по сравнению с MongoDB — не так удобно доставать данные :)
я пока смотрю в сторону Riak, там горизонтальное масштабирование очень прозрачно. добавляется новый нод и все. данные растекаются по нодам. единственный минус Riak по сравнению с MongoDB — не так удобно доставать данные :)
Mongodb у нас изначально был master-master, он полноценно не поддерживается, но покрывал наши нужды.
С момента, когда с ним начали происходить неведомые вещи (от нагрузки отставала синхронизация, а поскольку она двусторонняя, ее сложно восстановить), сделали master-slave.
Да, ограничений на шардинг достаточно, но в нашем случае, нужно будет шардить только одну самую большую коллекцию — Entry. Даже с этими ограничениями уже можем.
Возможно, мы будем использовать Riak для других целей. А пока что, mongodb отлично справляется со своей задачей. Даже слишком.
С момента, когда с ним начали происходить неведомые вещи (от нагрузки отставала синхронизация, а поскольку она двусторонняя, ее сложно восстановить), сделали master-slave.
Да, ограничений на шардинг достаточно, но в нашем случае, нужно будет шардить только одну самую большую коллекцию — Entry. Даже с этими ограничениями уже можем.
Возможно, мы будем использовать Riak для других целей. А пока что, mongodb отлично справляется со своей задачей. Даже слишком.
Мне сложно сказать, почему вас столько завязано инфраструктуры на поддержку такого проекта. Я делал пять лет назад rss.i.ua, который в пике спокойно справлялся с 40 000 потоков, 100 пользователями онлайн. Технологии простейшие — LAMP.
Сложно высчитать долю из общего железа, которую использует наш сервис, но ориентировочно это кусочек около 2% DB-сервера с MySQL, кусочек 3-5% Apache сервера для обновления потоков по частому крону, кусочек Apache-сервера для обслуживания клиентских запросов.
Единственное что, если у вас более интерактивная среда благодаря Node.js (постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?) — то это, конечно, большая нагрузка и более интересные технологии.
В любом случае, думаю, вы еще найдете много мест для оптимизации алгоритмов. Удачи с проектом :)
Сложно высчитать долю из общего железа, которую использует наш сервис, но ориентировочно это кусочек около 2% DB-сервера с MySQL, кусочек 3-5% Apache сервера для обновления потоков по частому крону, кусочек Apache-сервера для обслуживания клиентских запросов.
Единственное что, если у вас более интерактивная среда благодаря Node.js (постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?) — то это, конечно, большая нагрузка и более интересные технологии.
В любом случае, думаю, вы еще найдете много мест для оптимизации алгоритмов. Удачи с проектом :)
> который в пике спокойно справлялся с 40 000 потоков
сколько потоков в секунду вы обновляли?
Да, мест для оптимизации хватает.
Сейчас, одна из важных задач — определять мение читаемые потоки, чтобы снижать их приоритет. По моим подсчетам, можно повысить производительность в 10 раз.
> постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
не совсем так, но это мы будем делать совсем скоро.
сколько потоков в секунду вы обновляли?
Да, мест для оптимизации хватает.
Сейчас, одна из важных задач — определять мение читаемые потоки, чтобы снижать их приоритет. По моим подсчетам, можно повысить производительность в 10 раз.
> постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
не совсем так, но это мы будем делать совсем скоро.
> > который в пике спокойно справлялся с 40 000 потоков
> сколько потоков в секунду вы обновляли?
Такой цифры, так как потокам выдается динамический приоритет. Только мы используем приоритет не по читаемости, а по обновляемости. Минимум каждый поток обновляем раз в сутки. Да, это одна из хороших явно видных возможностей для оптимизации.
> > постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
>не совсем так, но это мы будем делать совсем скоро.
Хм, если это не полный интерактив, то по идее вам после оптимизаций должно хватить раза в 2 меньшего количества оборудования, чем сейчас.
> сколько потоков в секунду вы обновляли?
Такой цифры, так как потокам выдается динамический приоритет. Только мы используем приоритет не по читаемости, а по обновляемости. Минимум каждый поток обновляем раз в сутки. Да, это одна из хороших явно видных возможностей для оптимизации.
> > постоянное получение новых статей и моментальная отправка их фоновом режиме клиенту?
>не совсем так, но это мы будем делать совсем скоро.
Хм, если это не полный интерактив, то по идее вам после оптимизаций должно хватить раза в 2 меньшего количества оборудования, чем сейчас.
> Такой цифры, так как потокам выдается динамический приоритет. Только мы используем приоритет не по читаемости, а по обновляемости. Минимум каждый поток обновляем раз в сутки.
У нас некоторые потоки обновляются каждые 5 минут, максимум — раз в час. Тоесть, за час все (уже 21 тысяча) проходят обновление — совсем другие цифры.
Ваши пользователи не жаловались на задержки обновления?
P.S. pubsubhubbub не за горизонтом, уже многие его используют, и мы тоже будем.
У нас некоторые потоки обновляются каждые 5 минут, максимум — раз в час. Тоесть, за час все (уже 21 тысяча) проходят обновление — совсем другие цифры.
Ваши пользователи не жаловались на задержки обновления?
P.S. pubsubhubbub не за горизонтом, уже многие его используют, и мы тоже будем.
Не жаловались на задержки. Я думаю тут несколько причин, наиболее важные:
1) Кто пользуется ридером, тот подписан на несколько источников. И ему и так приходит при каждом просмотре много информации, ему еще несколько более новых статей ничего не меняют.
2) Пользователи не знают о задержках — они же ходят в рсс-ридер, а не на сайт.
1) Кто пользуется ридером, тот подписан на несколько источников. И ему и так приходит при каждом просмотре много информации, ему еще несколько более новых статей ничего не меняют.
2) Пользователи не знают о задержках — они же ходят в рсс-ридер, а не на сайт.
Логично.
Но важность некоторых новостей может исчисляться в минутах, как ни крути.
Уже посчитали, 20% потоков можно обновлять в 5 раз реже, 60% — в 10 раз реже.
Так или иначе, RSS скоро уйдет на второй план в Eventr. А родные потоки обновляются моментально.
Но важность некоторых новостей может исчисляться в минутах, как ни крути.
Уже посчитали, 20% потоков можно обновлять в 5 раз реже, 60% — в 10 раз реже.
Так или иначе, RSS скоро уйдет на второй план в Eventr. А родные потоки обновляются моментально.
Согдасен насчёт минут и потому для пары фидов пользовался самопальным клиентом, ходящим через список прокси (эти фиды серьезно относятся к слишком частым, чаще чем в соответствующих полях указано, обновлениям) выводящим только, что фид обновился (смотрю через браузер, набирая url в адресной строке).
P.S. Кстати, а счётчики читателей различные вы корректно обновляете или все мы «под одним прокси ходим»?
P.S. Кстати, а счётчики читателей различные вы корректно обновляете или все мы «под одним прокси ходим»?
pubsubhubbub никогда не заменит поллинг
Во-первых, паблишерам для этого надо делать более сложные телодвижения, чем просто rss-ленты формировать — а это ограниченное время программистов + деньги им, что могут себе позволить только крупные контент-проекты. Выгоду же получают вовсе не паблишеры, а подписчики. Большинство проектов не будет ради этого заморачиваться, разве что с готовыми CMS это будет идти «из коробки».
Во-вторых, паблишерам часто сложно делать трекинг того, что что-то новое опубликовалось (особенно, если рсс-лента формируется по временному интервалу статично)
В-третьих, система сложнее — pub/sub/hub — а это и немного больше сторон-участников, и протоколов-транспортов между ними
В-четвертых, при нарушении внутренней системы уведомления паблишером о новых заметках, подписчики рискуют остаться без обновлений. Разве что хаб возьмет на себя поллинг — но тогда вы уже зависите от того, как часто его делает хаб.
Ну а тем более пока этой системой мало кто пользуется, нам остается в основном оптимизировать поллинг :)
Во-первых, паблишерам для этого надо делать более сложные телодвижения, чем просто rss-ленты формировать — а это ограниченное время программистов + деньги им, что могут себе позволить только крупные контент-проекты. Выгоду же получают вовсе не паблишеры, а подписчики. Большинство проектов не будет ради этого заморачиваться, разве что с готовыми CMS это будет идти «из коробки».
Во-вторых, паблишерам часто сложно делать трекинг того, что что-то новое опубликовалось (особенно, если рсс-лента формируется по временному интервалу статично)
В-третьих, система сложнее — pub/sub/hub — а это и немного больше сторон-участников, и протоколов-транспортов между ними
В-четвертых, при нарушении внутренней системы уведомления паблишером о новых заметках, подписчики рискуют остаться без обновлений. Разве что хаб возьмет на себя поллинг — но тогда вы уже зависите от того, как часто его делает хаб.
Ну а тем более пока этой системой мало кто пользуется, нам остается в основном оптимизировать поллинг :)
Согласен на все 100.
> pubsubhubbub никогда не заменит поллинг
может быть уже скоро заменит, трудно сказать — но вот вам такая статистика
feedburner (google) поддерживает pubsubhubbub
из 800ооо RSS фидов на нашем проекте (viigo.com) 25% были с feedburner
т.е. как минимум 25% уже покрыты.
Там кроме feedburner есть и другие крупные компании — так что я думаю что доля ещё больше и бужет расти
может быть уже скоро заменит, трудно сказать — но вот вам такая статистика
feedburner (google) поддерживает pubsubhubbub
из 800ооо RSS фидов на нашем проекте (viigo.com) 25% были с feedburner
т.е. как минимум 25% уже покрыты.
Там кроме feedburner есть и другие крупные компании — так что я думаю что доля ещё больше и бужет расти
Пропустил слово в комментарии
*Такой цифры нет
*Такой цифры нет
> Eventr работает в режиме Бэта-тестирования.
Бета. Б-е-т-а. Вторая буква греческого алфавита.
Бета. Б-е-т-а. Вторая буква греческого алфавита.
Зачем, если есть twitter?
У меня на сервере скрипт всего лишь раз в час получал rss с news.google.com по одному запросу, в итоге через некоторое время забанили (выдавал ошибку 503, а если подменять user-agent, то просит вводить капчу).
Просто информация на случай, если будут жалобы на необновляющиеся rss новостей.
Просто информация на случай, если будут жалобы на необновляющиеся rss новостей.
Проимпортировал, пробую зайти — показывает кота. Полдня уже. Кому жаловаться? Имя такое же.
Уже писал вам, но повторюсь: очень нужны инструменты соц. рекомендаций для более эффективной фильтрации контента. А именно избранное и показ у каждой записи кол-во голосов, ну или кол-во репостов или и то и то.
«Zend_Date. Zend_View partial и placeholder»
бугага, а у нас на pushme.to основной затык был в ini-читалке Zend'овской. Она занимала что-то типа 400ms на каждый запрос, ну т.е. запредельно много.
бугага, а у нас на pushme.to основной затык был в ini-читалке Zend'овской. Она занимала что-то типа 400ms на каждый запрос, ну т.е. запредельно много.
Мы тоже это обнаружили недавно. Сейчас phing-ом генерится php конфиг через var_export, и он отличненько укладывается в APC opcode. Еще кэшируем роуты.
Вообще, блин, руки чешутся закэшировать весь Application вместе с Di к чертям. А вообще, в идеале, вообще не выключать php, чтобы он работал, как демон (он у нас так на бэкграунде работает). Но это мечты.
Кстати, у архитектуры наших Zend приложений общие предки (Гоша) :)
Вообще, блин, руки чешутся закэшировать весь Application вместе с Di к чертям. А вообще, в идеале, вообще не выключать php, чтобы он работал, как демон (он у нас так на бэкграунде работает). Но это мечты.
Кстати, у архитектуры наших Zend приложений общие предки (Гоша) :)
Вот мы примерно так и сделали — весь zend*ini в APC. Правда, не через генерацию, а просто заполняем кеш, если там уже нет конфига. Один раз в 30 секунд я переживу 400ms парсинга конфигов. :)
Еще у нас apc.stat=0. Когда деплоимся, то вызываем секретный URL, сбрасывающий все содержимое APC.
Еще у нас apc.stat=0. Когда деплоимся, то вызываем секретный URL, сбрасывающий все содержимое APC.
Тоже apc.stat=0, но мы его не сбрасываем, потому, что у нас каждый деплой идет в другую директорию (весь проект где-то 20MB весит в памяти).
А еще у нас один include_path, переопределенный Zend_Autoloader и ни одного require_once — для того, чтобы использовать только абсолютные пути.
Кстати, если apc.stat=0, при удалении файла, он это замечает. Тоесть, всетаки, смотрит сволочь в файловую систему.
Еще пробовали загнать весь код проекта в ramfs — дало копейки, отказались.
А еще у нас один include_path, переопределенный Zend_Autoloader и ни одного require_once — для того, чтобы использовать только абсолютные пути.
Кстати, если apc.stat=0, при удалении файла, он это замечает. Тоесть, всетаки, смотрит сволочь в файловую систему.
Еще пробовали загнать весь код проекта в ramfs — дало копейки, отказались.
Если вы начали думать об этом, то пора уже выбрать другой стек.
Я всё же попробовал бы переписать на Node.JS/Express или на Ruby/Sinatra.
Я всё же попробовал бы переписать на Node.JS/Express или на Ruby/Sinatra.
Ну, может быть, конечно, социализация — это и здорово, но особых отличий от шаринга в гуглочиталке.
И несколько странный интерфейс, почему нельзя было сделать хоть минимум настроек? При попытке увеличить шрифт интерфейс расползается просто в ничто, печально :(
И несколько странный интерфейс, почему нельзя было сделать хоть минимум настроек? При попытке увеличить шрифт интерфейс расползается просто в ничто, печально :(
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Технический отчет запуска Eventr.com, цифры