Cайт с большим количеством FE юзеров

[dmartynenko]

У нас все пользователи это fe_users.

Тут конечно сложно оценивать. У нас скорее всего бывает и 1000 онлайн (если оценить по суточной посещаемости). Но это все, а не только те кто логинится. Получается многое зависит от контента. У нас приблизительно так - те кто не логинится видит один и тот же контент, те кто логинится может видеть на страницах какой-то кастомизированный. Соответствено в первом случае кэш отлично работает, во втором может уже не так хорошо помогать.

По моим субъективным оценкам если бы было 1000 онлайн и для всех нужно было на каждой странице выводить кастомизированный контент, то производительности/памяти одного выделенного сервера (скажем за 5000$) уже может не хватать. Надо делать распределенную систему. Это конечно можно, но дороже в разы по деньгам и сложнее потом работать со всем этим. Если бы речь шла о 10000+ онлайн, то ИМХО TYPO3 выдержит только на сайтах где в основном статика.

Ну и от количества контента многое зависит. Одно дело если вам нужно делать выборки по таблице в 100 000 записей, другое когда записей 10 млн. и более. В этом разрезе количество пользователей всего и онлайн само по себе ничего не решает. Вопрос скорее в том сколько операций, выборок нужно делать для каждого онлайн-пользователя на страницу и на сколько эти операции тяжелы и поддаются кэшированию.

[Lucifer]

Сообщение от dmartynenko

По моим субъективным оценкам если бы было 1000 онлайн и для всех нужно было на каждой странице выводить кастомизированный контент, то производительности/памяти одного выделенного сервера (скажем за 5000$) уже может не хватать. Надо делать распределенную систему. Это конечно можно, но дороже в разы по деньгам и сложнее потом работать со всем этим. Если бы речь шла о 10000+ онлайн, то ИМХО TYPO3 выдержит только на сайтах где в основном статика.
Ну и от количества контента многое зависит. Одно дело если вам нужно делать выборки по таблице в 100 000 записей, другое когда записей 10 млн. и более.

По моему, когда речь идет о подобных нагрузках, то в любой CMS все перепиливается, и кастомизируется. ))) Хотя тут, конечно, вопрос в том, что считать "онлайном" пользователя.

[dmartynenko]

Сообщение от Lucifer

в любой CMS все перепиливается

Трудоемкость этого в TYPO3 может быть выше, чем написание только нужных в конкретном проекте вещей "с нуля". TYPO3 хорошо расширяется и дополняется, но "перепиливается" вряд ли.

[Lucifer]

ну почему же?
page = PAGE
page.userFunc = tx_вашплагин
и все... пили, что хочется. и от самого тайпо может остаться какой то минимум.

[dmartynenko]

Это как раз расширение и дополнение стандартных возможностей. А тут скорее проблема в том что даже страница с кодом

page = PAGE
page.10 = TEXT

будет генерится (в том числе из кэша) минимум 150-200ms (выделенный сервер), и это время уходит просто на загрузку кода ядра и основных экстов. Если грубо прикинуть, то на 16 ядрах при самых лучших условиях эта страница загрузит сервер на 100% уже при 16 * 5 = 80 одновременных обращениях от пользователей. А если одновременно обращатся будет 300 или 1000 ?

[Илья]

Сообщение от dmartynenko

будет генерится (в том числе из кэша) минимум 150-200ms (выделенный сервер), и это время уходит просто на загрузку кода ядра и основных экстов. Если грубо прикинуть, то на 16 ядрах при самых лучших условиях эта страница загрузит сервер на 100% уже при 16 * 5 = 80 одновременных обращениях от пользователей. А если одновременно обращатся будет 300 или 1000 ?

Думаю что в ваших расчетах ошибка...
Почему считаете как 16*5?
Реально 16 ядерный сервер потянет на несколько порядков больше пользователей

[dmartynenko]

Расчеты очень грубые, так как не учитывается реальное обращение в БД, ФС, сети и влияние этих факторов. Но примерно так: если 1 страница генерится 200ms (1/5 секунды), то одно ядро за секунду сможет сгенерить только 5 страниц. Значит 16 ядер смогут выдать не более 16 * 5 = 80 страниц в секунду.

Я писал именно про число одновременных запросов. Это не то же самое что число онлайн пользователей. Может быть 1000 пользователей онлайн, но каждый открывает страницу и просматривает ее скажем не менее 30 секунд. В таком случае число одновременных запросов от 1000 пользователей будет в среднем намного меньше 1000, опять же грубо 1000 / 30 = 30 страниц в секунду.

PS: Что-то мы далеко вышли за рамки исходного вопроса.

[Lucifer]

Сообщение от dmartynenko

Это как раз расширение и дополнение стандартных возможностей. А тут скорее проблема в том что даже страница с кодом

page = PAGE
page.10 = TEXT

будет генерится (в том числе из кэша) минимум 150-200ms (выделенный сервер), и это время уходит просто на загрузку кода ядра и основных экстов. Если грубо прикинуть, то на 16 ядрах при самых лучших условиях эта страница загрузит сервер на 100% уже при 16 * 5 = 80 одновременных обращениях от пользователей. А если одновременно обращатся будет 300 или 1000 ?

А напильничком не, ваще никак? 150-200 - это пожалуй typo3 на апаче с дефолтным конфигом. nginx+phpfpm+apc - результаты намного более интересные.
А расчеты типа "одновременно 300-1000" - уж слишком заоблачные. Если считать "одновременно" за "в секудну", даже если это пиковая нагрузка, то подобные проекты не живут на одном сервере и на CMS-CMF. Да и по пальцам посчитать их можно.

[dmartynenko]

А причем здесь Апач ? Это время parsetime, которое считает сам TYPO3 - запускает счетчик при вызове index.php, и выводит в конец кода страницы в конце index.php. Накладные расходы до и после вызова index.php это дополнительное время. Да все это измерение сферического коня в вакууме. На каждом проекте свои уникальные задачи (проблемы) и свои уникальные их решения (см. пример про www.calis.lv).

Я, например, APC не пробовал использовать. Только memcached. Хотя пару лет назад видел пост про сравнение скорости обращения (чтение-запись) APC vs memcached vs MySQL MEMORY TABLE. Так вот последние два были близки по скорости (но в MySQL то нормальный поиск есть), а APC до 10 раз был быстрее из за прямого доступа, минуя TCP.

[jettero]

Сообщение от dmartynenko

Это как раз расширение и дополнение стандартных возможностей. А тут скорее проблема в том что даже страница с кодом

page = PAGE
page.10 = TEXT

будет генерится (в том числе из кэша) минимум 150-200ms (выделенный сервер), и это время уходит просто на загрузку кода ядра и основных экстов. Если грубо прикинуть, то на 16 ядрах при самых лучших условиях эта страница загрузит сервер на 100% уже при 16 * 5 = 80 одновременных обращениях от пользователей. А если одновременно обращатся будет 300 или 1000 ?

Наверно сервер слабенький, у меня на одном сайте-соцсети, страница с 5-6 USER_INT плагинами на ней, генерится за 70-100 мс (если и страница и плагины из кэша, в INT плагинах сделан внутренний кэш).
При этом, на сайте довольно сложные и большие шаблоны - вся генерация контента сделана исключительно на TS шаблонах, с добавлением самописных контент объектов, для работы с формами, сложными структурами в БД итп, общий объем TS кода где-то 10-20к строк.
Так что не все так страшно. Правда сервер не слабый - 2 проца, 8 ядер и дофига RAM, но memcached сейчас отключен из-за разных багов при работе с ним через caching framework, так что пока кэш целиком в mysql лежит.