Russian TYPO3 community

Russian TYPO3 community (http://forum.typo3.ru/index.php)
-   Вопросы выбора CMS (http://forum.typo3.ru/forumdisplay.php?f=36)
-   -   Cайт с большим количеством FE юзеров (http://forum.typo3.ru/showthread.php?t=9907)

Lucifer 06.02.2012 12:27

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

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

dmartynenko 06.02.2012 12:48

Оценить parsetime проще всего - цифра есть в коде каждой сгенеренной страницы, и именно к нему относятся 150-200ms. А вы пишете что если заменить apache на скажем nginx то все залетает, не так ли?
Цитата:

150-200 - это пожалуй typo3 на апаче с дефолтным конфигом. nginx+phpfpm+apc - результаты намного более интересные
И именно поэтому я пишу что
Цитата:

Если грубо прикинуть, то на 16 ядрах при самых лучших условиях эта страница загрузит сервер на 100% уже при 16 * 5 = 80 одновременных обращениях от пользователей
Тут 80 (или 100 или 500 или 42) это некая идельная цифра, в реальных условиях сервер с апачаем отдаст меньше страниц в секунду из-за своего оверхеда, а сервер с nginx+php-fpm сработает лучше апача, но тоже отдаст меньше 80.

Lucifer 06.02.2012 13:20

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

jettero 22.03.2012 13:57

Цитата:

Сообщение от dmartynenko (Сообщение 33001)
Это как раз расширение и дополнение стандартных возможностей. А тут скорее проблема в том что даже страница с кодом
Код:

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 лежит.

dmartynenko 22.03.2012 14:21

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

jettero 22.03.2012 14:28

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

Илья 22.03.2012 23:36

jettero
Цитата:

Наверно сервер слабенький, у меня на одном сайте-соцсети, страница с 5-6 USER_INT плагинами на ней, генерится за 70-100 мс (если и страница и плагины из кэша, в INT плагинах сделан внутренний кэш).
А вот это интересно! Можно ссылку на сайт сюда или в личку?


Часовой пояс GMT +4, время: 07:34.

Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Перевод: zCarot