[Nekstati]

anon писал(а):форумный контент хоть и динамический, но процентное отношение статики к динамике все равно огромно, и оно тем больше, чем больше становится форум. ведь нигде не обновляются все топики одновременно))

Тем не менее любое сообщение в любом топике может быть в любой момент изменено, и изменение должно немедленно стать видимым, и анонимам в том числе. Так что я не думаю, что контент реально кэшировать. Хотя, если на данном конкретном форуме не практикуется редактирование и удаление постов, то, наверное, можно… Есть ещё вариант — кэшировать контент на несколько секунд (5…10). При огромной посещаемости этого может быть достаточно для снижения нагрузки в разы. — Впрочем, это теоретически; подобных модов, насколько мне известно, нет.

[Mr. Anderson]

Кеширование контента форума - это из области ненаучной фантастики. Осуществимо, но бессмысленно. Да и производительность диска - вещь не бесконечная.
RAM-кеш и его вариации гораздо проще и эффективнее.

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

[anon]

crash писал(а):что же они у вас грузят, что вам сотки мало будет. У вас там хранилище фильмов?

ну если Вы возьмете в руки калькулятор, да помножите скажем 20К на 1.5К (пусть даже 10К с учетом gzip), то вы поймете что я имел ввиду

crash писал(а):здесь

следует интерпретировать это в контексте вопроса ТС, а не в "жадности форума до трафика"...

Nekstati писал(а):Есть ещё вариант — кэшировать контент на несколько секунд (5…10). При огромной посещаемости этого может быть достаточно для снижения нагрузки в разы. — Впрочем, это теоретически; подобных модов, насколько мне известно, нет.

это решается довольно просто кешированием в nginx... где-то были изыскания на эту тему (на вскидку не найду) но с другим движком, кажется с воблой, и таки да - прирост очень и очень ощутим.
но гораздо интереснее было бы иметь мод, который вы позволял отслеживать любое изменение на форуме (уверен это не очень сложно) и вызывал бы некую функцию и передавал ей url (заглушку, а там уже что угодно). я не зря про сквид написал, он умеет выборочно дропать кеш по url.

Mr. Anderson писал(а):Хотя любой совет по разрешению ситуации с хайлоадом требует предварительного анализа причины и места "затыка".

совершенно согласен. добавлю лишь что обычно это БД (и тут помогает встроенное кеширование), с ростом нагрузки сюда выходит уже весь пхп как таковой..
RAM-кеширование еще лучше, да... тот же memcached дергать прямо из nginx-а наверное было бы вообще великолепно. но тут уже малой кровью не обойтись..

[rxu]

anon
Не знаю, как в вашем случае, но глядя на репорт, я вижу Time spent on mysqli queries: 0.00511s | Time spent on PHP: 0.12534s, что говорит о в 20 раз меньших затратах на получение данных из БД, чем на обработку скриптов. Что может тогда дать файловое кэширование контента?

[anon]

rxu, ну как же..
вот тест на file.php, на загрузку авки. первый без кеширования, а второй с кешированием в nginx

Код: Выделить всё

Document Path:          /download/file.php?avatar=1011.jpg
Document Length:        9895 bytes

Concurrency Level:      100
Time taken for tests:   50.015 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      101980000 bytes
HTML transferred:       98950000 bytes
Requests per second:    199.94 [#/sec] (mean)
Time per request:       500.146 [ms] (mean)
Time per request:       5.001 [ms] (mean, across all concurrent requests)
Transfer rate:          1991.22 [Kbytes/sec] received

------------
Document Path:          /download/file.php?avatar=1011.jpg
Document Length:        9895 bytes

Concurrency Level:      100
Time taken for tests:   0.984 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      101800000 bytes
HTML transferred:       98950000 bytes
Requests per second:    10166.41 [#/sec] (mean)
Time per request:       9.836 [ms] (mean)
Time per request:       0.098 [ms] (mean, across all concurrent requests)
Transfer rate:          101068.45 [Kbytes/sec] received

вот и вся арифметика.
понятно что тест сильно синтетический. его бы неплохо "размазать" тем же siege, но тем не менее...

[nissin]

anon
В принципе думаю можно попробовать сделать кэширование контента только для гостей и поисковых ботов.

[Mr. Anderson]

anon
Вообще любопытно, а какие вы вообще оптимизации проделали?
Ну там из банальностей...
по nginx все текстовое жать хотя бы на 1 (или как вариант выдавать .gz-версии соотв. файлов), всей статике выдавать экспайр через 2-3 месяца, кешировать статику в RAM.
по php - избавление от лишних прослоек при запуске php, использование прекешеров типа eaccelerator или APC.
по MySQL правильный кеш запросов, хранение наиболее нагруженных таблиц (а то и всей базы) в RAM (с репликацией на диск каждые 1-5 минут).
ну и тп

[anon]

Mr. Anderson, да ничего особенного. ну БД в tmpfs (я писал выше), но это особо прироста не дало на выборках (что-то процентов на 20 макс). на апдейты как-то не мерил. ну а статики же нет как таковой, за исключением авок, изображений, вложений, да стилей - эти в nginx кешируется.
а так nginx (comp_level 3), 150 воркеров php-fpm постоянно, eAccelerator... вроде бы и все, но хотелось бы большего. держит где-то ~150 одновременных запросов особо не проседая (siege по сайтмапу). реально это будет пару тысяч, даже больше, пользователей я думаю, но я такой посещаемостью похвастаться не могу...
может быть когда-то соберусь изучить движок и прикручу таки сквид, хотя и не горит совсем и интересно чисто с теоретической стороны.