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

Привет, сейчас изучаю вопрос подойдет ли Typo3 для сайта, где будет большое количество (несколько тысяч) активных FE пользователей. Каждый из пользователей будет иметь личный кабинет и стандартные возможности по публикации новостей, фотографий, видео.
Знаю, что отличные возможности системы для групповой работы, но здесь BE интерфейса пользователем раздаваться не будет. Все работа будет через FE.
Не получится ли каких неприятностей при реализации всего этого на Typo3?

Кто-то из немцев писал о сайте с десятками тысяч юзеров, так что каких-то особых неприятностей тут быть не должно.

Личный кабинет и значительную часть контента нужно будет делать не кешируемым (соответственно надо будет правильно программировать модули используя USER_INT для плагинов)
Насчет целесообразности использования TYPO3 - нужно внимательно смотреть. Может оказаться, что от TYPO3 не нужно ничего, кроме того, что есть в любом веб-фреймворке... Тогда конечно и надо использовать веб-фреймворк.

Благодарю за ответ!
Про этот сайт я тоже слышал, но хотелось узнать подробности.
Сам функционал Тайпы будет вполне востребован, т.к. будет еще несколько разделов "традиционной ориентации" для Typo3 :) Т.е. обычный функционал: новости, голосования, галереи и т.п.
За информацию про не кешируемый контент пользователей - спасибо.
Правда пока детально еще не обдумывались такие моменты.

У нас есть сайт с 60 тыс. зарегистрированных пользователей. И до 150 пользоватлей онлайн. Мысль Валерия на счет целесообразности использования TYPO3 поддержу. Но для нас возможность писать только специализированный код и не заморачиваться на типовые вещи которые все и так хорошо представлены в TYPO3 - это плюс. Минус - тяжеловестность ядра. Если бы цифры по пользователям были на порядок выше, то я бы скорее всего искал альтернативу TYPO3 в фреймворках.

Я делал комъюнити-сайт на TYPO3. Там для юзеров есть профили, внутренняя почта, фотогалереи, блоги, форумы. Юзеры могут создавать группы сами. Для групп существуют свои галереи и форумы. Часть работает как USER_INT, часть кэшируема. Достаточно много всего кэшируется в APC, иначе слишком много запросов получается в базу от некешируемых объектов. Там тоже несколько десятков тысяч и больше сотни групп. Все работает.

Главное, думать, когда делаешь. Сразу учитывать, что писать надо с оглядкой на производительность все этого.

dmartynenko
Ну 60тыс. зарегистрированных человек это уже неплохо.
А что касается 150 онлайн и вашей фразы об увеличении на порядок...
Думаете 1500 онлайн юзеров (при условии того, что все спроектировано достаточно грамотно) это уже будет тяжело для Typo3?
Dmitry Dulepov
Спасибо за участие в теме, можно ссылку на этот сайт увидеть здесь или в личке?
2All
Кстати, эти десятки тысяч пользователей в вашей системе, да и в системе dmartynenko это FE пользователи для Typo3 или же они "сидят" чисто внутри кастомного экста?

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

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

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

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

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

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

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

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

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

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

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

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

http://www.calis.lv/, но там нет ни русской, ни английской версии. Все юзеры – FE.

У меня там самое тяжелое – форумы (http://www.calis.lv/forums/). Форумы написаны с нуля, потому что там нужны вещи, которых нет нигде. Плюс все запиливалось на производительность (сервер – один на все, людей – много, контингент на 70% – женский, пишут страшно много). Даже собственный mvc был запилен, с оптимизацией всего и кешированием записей в APC. Это еще на TYPO3 4.3 работало. Пробовал TYPO3 caching framework, но с ним все легло через 3 минуты после включения. Поднялось только когда отключил caching framework. Т.е. вообще без кэша работало быстрее, чем с caching framework. С другой стороны – понятно почему: caching framework, как обычно, идеологически правильная, но не приспособленная к реальной жизни вещь :) В результате сделал свою реализацию кэша, котторой и пользуюсь. Вот, сейчас имею в APC:

Free: 265.6 MBytes (51.9%) Hits: 38115103 (100.0%)
Used: 246.4 MBytes (48.1%) Misses: 809 (0.0%)

File Cache Information
Cached Files 666 ( 79.1 MBytes)
Hits 38115103
Misses 809
Request Rate (hits, misses) 804.63 cache requests/second
Hit Rate 804.61 cache requests/second
Miss Rate 0.02 cache requests/second
Insert Rate 0.01 cache requests/second
Cache full count 131012

User Cache Information
Cached Variables 112438 (161.5 MBytes)
Hits 11019223
Misses 3544300
Request Rate (hits, misses) 307.44 cache requests/second
Hit Rate 232.62 cache requests/second
Miss Rate 74.82 cache requests/second
Insert Rate 96.96 cache requests/second

Вот так и живем :)

В общем пока что решил делать сайт на Typo3. О результатах сообщу позднее

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

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

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

апач очень даже при чем. если брать apache + modulephp, то для каждого запуска надо поднять весь пхп со всеми модулями. да и сам по себе апач работает медленнее, и ест больше памяти. если пхп работает в режиме php-fpm, то все уже поднято.
мемкеш сравнивать с апц не совсем корректно. так как мемкеш - это просто кейвелью хранилище. апц же, кроме хранения отдельных ключей (в этой роли я его не пробовал) еще и самостоятельно кеширует код (аля eAccelerator), и, судя по ab, дает неплохие результаты )

Уважаемый Lucifer! Вы не внимательны к моим словам.
Но это никак не влияет на время parsetime, который считает сам TYPO3. Поднятие php и прочие вещи происходят до вызова index.php, или вы не согласны с этим?

Необходимость кэша PHP кода для TYPO3 очевидна, без него parsetime вырастет в 5-10 раз. Но тут сравнивается именно задача того же рода - когда APC выступает в роли key-value хранилища (http://www.php.net/manual/ru/ref.apc.php). Причем основные функции практически идентичны таковым в memcached.

Возможно я чего то не понимаю...
А разве нам важен именно parsetime, считаемый в typo3, или же нам все таки интересна реальная производительность?

Для использования мемкеша или апц в качестве key-value хранилища надо все таки допиливать систему внутреннего кешировани typo3, и модулей. А это дополнительное время на разработку. А что бы поставить апц просто для кеширования кода требуется 5 минут. При том прирост производительности он дает существенный.

Оценить parsetime проще всего - цифра есть в коде каждой сгенеренной страницы, и именно к нему относятся 150-200ms. А вы пишете что если заменить apache на скажем nginx то все залетает, не так ли?
И именно поэтому я пишу что Тут 80 (или 100 или 500 или 42) это некая идельная цифра, в реальных условиях сервер с апачаем отдаст меньше страниц в секунду из-за своего оверхеда, а сервер с nginx+php-fpm сработает лучше апача, но тоже отдаст меньше 80.

Я говорил о своих реальных замерах. Все проводилось через ab. Добиться наилучших результатов я смог именно на вышеупомянутой связке (около 50 запросов в секунду с кешом). На отдельном запросе, да, парстайм особо отличаться не будет на апаче и нджинксе (но будет серьезно отличаться на module_php, fastcgi и fpm).

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

Сервер схожей с вашей конфигурации (где-то 2-х летней давности). Но нагруженный - сайтов на 20000+ уников в сутки + openx на 2 млн. показов в сутки.

Если много сайтов + баннерокрутилка, то у вас скорее-всего узкое место в БД.

jettero
А вот это интересно! Можно ссылку на сайт сюда или в личку?