Форум больше не используется. Присоединяйтесь к каналу #community-ru в Slack for TYPO3 community |
|
05.02.2012, 11:17 | #1 | |
Senior Member
Регистрация: 01.07.2008
Сообщений: 392
|
Цитата:
А расчеты типа "одновременно 300-1000" - уж слишком заоблачные. Если считать "одновременно" за "в секудну", даже если это пиковая нагрузка, то подобные проекты не живут на одном сервере и на CMS-CMF. Да и по пальцам посчитать их можно. |
|
05.02.2012, 22:56 | #2 |
Senior Member
|
А причем здесь Апач ? Это время parsetime, которое считает сам TYPO3 - запускает счетчик при вызове index.php, и выводит в конец кода страницы в конце index.php. Накладные расходы до и после вызова index.php это дополнительное время. Да все это измерение сферического коня в вакууме. На каждом проекте свои уникальные задачи (проблемы) и свои уникальные их решения (см. пример про www.calis.lv).
Я, например, APC не пробовал использовать. Только memcached. Хотя пару лет назад видел пост про сравнение скорости обращения (чтение-запись) APC vs memcached vs MySQL MEMORY TABLE. Так вот последние два были близки по скорости (но в MySQL то нормальный поиск есть), а APC до 10 раз был быстрее из за прямого доступа, минуя TCP. |
05.02.2012, 23:14 | #3 |
Senior Member
Регистрация: 01.07.2008
Сообщений: 392
|
апач очень даже при чем. если брать apache + modulephp, то для каждого запуска надо поднять весь пхп со всеми модулями. да и сам по себе апач работает медленнее, и ест больше памяти. если пхп работает в режиме php-fpm, то все уже поднято.
мемкеш сравнивать с апц не совсем корректно. так как мемкеш - это просто кейвелью хранилище. апц же, кроме хранения отдельных ключей (в этой роли я его не пробовал) еще и самостоятельно кеширует код (аля eAccelerator), и, судя по ab, дает неплохие результаты ) |
06.02.2012, 12:14 | #4 |
Senior Member
|
Уважаемый Lucifer! Вы не внимательны к моим словам.
Но это никак не влияет на время parsetime, который считает сам TYPO3. Поднятие php и прочие вещи происходят до вызова index.php, или вы не согласны с этим? Необходимость кэша PHP кода для TYPO3 очевидна, без него parsetime вырастет в 5-10 раз. Но тут сравнивается именно задача того же рода - когда APC выступает в роли key-value хранилища (http://www.php.net/manual/ru/ref.apc.php). Причем основные функции практически идентичны таковым в memcached. |
06.02.2012, 12:27 | #5 |
Senior Member
Регистрация: 01.07.2008
Сообщений: 392
|
Возможно я чего то не понимаю...
А разве нам важен именно parsetime, считаемый в typo3, или же нам все таки интересна реальная производительность? Для использования мемкеша или апц в качестве key-value хранилища надо все таки допиливать систему внутреннего кешировани typo3, и модулей. А это дополнительное время на разработку. А что бы поставить апц просто для кеширования кода требуется 5 минут. При том прирост производительности он дает существенный. |
06.02.2012, 12:48 | #6 | ||
Senior Member
|
Оценить parsetime проще всего - цифра есть в коде каждой сгенеренной страницы, и именно к нему относятся 150-200ms. А вы пишете что если заменить apache на скажем nginx то все залетает, не так ли?
Цитата:
Цитата:
|
||
06.02.2012, 13:20 | #7 |
Senior Member
Регистрация: 01.07.2008
Сообщений: 392
|
Я говорил о своих реальных замерах. Все проводилось через ab. Добиться наилучших результатов я смог именно на вышеупомянутой связке (около 50 запросов в секунду с кешом). На отдельном запросе, да, парстайм особо отличаться не будет на апаче и нджинксе (но будет серьезно отличаться на module_php, fastcgi и fpm).
|
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Каталог с большим количеством товара | hotsnake | Вопросы выбора CMS | 1 | 09.01.2009 16:27 |