ivan-lev: У ТС "просто хостинг", какой второй сервер?..
Не исключено, что ТС не в курсе, кто автор системы и как "оно" работает.. Есть ли там вообще кэш.. и "какое там CMS"..
Как минимум, поэтому считаю, что советовать "включить кэш", без понимания "что и где там".. слегка опрометчиво.. Хотя.. может ведь и прокатит ))
---------- Добавлено 21.08.2019 в 00:14 ----------
там хостер письмо прислал про "какой-то лимит CPU".. Вы о чём? )))
ТС, очевидно, не знает об этом ничего и ей надо пойти взять вебмастера чтобы он разобрался. Любые другие советы - вредные.
Я о том что "кеширование создаёт нагрузку на камень" (что дичь и дурь в общем случае) и далее о двух форумных военах CMS и кеша, которые боги и всё знают. Всё остальное - о кешировании, а не о ТС. Имеющий мозг прочитает и запомнит ключевые слова из которых нагуглит.
По теме ТС ничего сказать нельзя, пока не пойдёшь и не посмотришь что там происходит на хостинге.
lonelywoolf: suffix, Генерация. PHP выполняет дополнительные действия, чтобы положить страницу на диск (кэширование выполняется средствами PHP у веб-мастеров, кэш на стороне сервера это DevOps или админ). Потом при запросе страницы нужно проверить, а кэш истёк или нет, и если он истёк (скажем, 5 минут, а посещение раз в полчаса) - удалить старые данные из кэша, сгенерировать новые, отдать клиенту и положить снова в кэш. Если таких страниц на сайте (условно) миллион - то выигрыш от такого кэша нулевой, когда кэш истекает раньше, чем будет повторно отдан. Это заставляет CMS использовать больше ОЗУ, больше делать запросов к БД, генерировать больше обращений к диску, а так же производить дополнительные действия на CPU.
Вызов stat замечательно кешируется уже на уровне операционной системы. TTL кеша на файлах эффективнее делать через stat/touch. Это убирает необходимость читать данные и проверять валидность с т.з. TTL. Это же позволяет эффективно чистить кеши. Если кеш невалиден - можно его всухую перезатирать.
Понятно, что если файловый кеш и 1М файлов в одном каталоге - это приговор почти всегда. Но, в первую очередь, это приговор автору системы кеширования, который не понимает с чем работает.
Расход RAM, кстати, при таком кешировании будет заметный, но не критичный. Расход CPU тоже, в рамках общего потребления будет три копейки. Iowait может всё попортить (особенно когда много файлов в каталоге), но это лечится переставлением рук в плечи.
Добавление второго сервера для обработки запросов делает файловый кеш тем, что использовать нельзя - любая сетевая файлуха вносит весьма заметные задержки, а держать на каждом сервере свой кеш - быстро прогрессирующая боль с инвалидацией.
lonelywoolf:
Ну, это было во-первых. Во-вторых, умные ребята с Redis и прочими кэширующими системами. Чем больше кэш, тем больше занимает выборка из него, и опять же, если закэшированы десятки гигабайт данных, то вполне вероятен сценарий, когда обращение к кэшу будет происходить дольше, чем генерация страницы без кэша. Особенно файловый кэш средствами CMS.
Первая плохая новость в том, что редис - не самое хорошее решение для организации большого кеша в силу неэффективности выделения памяти в типе string. На большом количестве мелких ключей оверхед по памяти может быть в разы.
Однако, в силу того, что доступ данных по ключу что в редисе что в мемкеше по хэш-таблице - алгоритмическая сложность поиска по ней всегда константна ( О(1) ) и время поиска не зависит от количества ключей.
Большую сложность являет собой эластичность серверов кеширования алгоритмов диструбуции ключей, когда добавление/удаление серверов на лету приводит к инвалидации большого количества данных и по-сути приводит к т.н. "холодному старту", что для больших систем весьма болезненно.
Решение - консистентное хэширования области ключей.
Сравнивать это с файловым кэшем средствами CMS - за гранью добра и зла.
lonelywoolf:
Дальше продолжать? Если хотите - почитайте, почему кэширование средствами MySQL не эффективно, когда кэш слишком большой и предлагается использовать кэш на уровне приложения. Не надо сравнивать взрослые вещи с кэшированием в cms.
Если говорить о встроенном в мускул кеше запросов - то это та штука, на которую не надо возлагать больших надежд (ключом выступает особенность инвалидации всей таблицы при изменении строки. Однако, эти данные достаточно старые и, возможно, в мире MySQL все поменялось.
Есть ещё подход с хранением данных кеша в таблице с индексом по ключу. Но это такое... Такие таблицы - обычно write-intensive, что быстро приводит к деградации индексов и росту грязных страниц. Лучше уж в файлы.
lonelywoolf: Bananzz, скажем, учи матчасть. Генерация кэша сама по себе ресурсы кушает, и далеко не всегда уместна. Это не то кэширование, которое ты тут нам усиленно описываешь. И да, в вордпрессе оно реализовано, мягко говоря, плохо в очень многих случаях. Тут тебе говорят про конкретный продукт, а не про баззворды.
Во-первых, автор темы не упоминал вордпресс.
Во-вторых, генерация on-demand кеша как отдельный подпроцесс почти ничего не стоит: всё что должно быть в кеше должно генерироваться и без кеша: осталось сериализовать и записать. Как конкретно реализовано оно wp - мне плевать, у меня этого в продакшне нет (слава богу).
В-третьих, я не услышал как конкретно процесс генерации кеша может вызывать всплески использования "камня".
В-четвертых, любое кеширование по своей сути устроено одинаково. Хоть где и хоть на каком языке. (Пока мы говорим про веб-приложения).
Так что, у меня с матчастью хорошо, как и с практикой.
И, да, я всё ещё жду ответа: как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?
lonelywoolf: Судя по сообщению нихрена не знаешь и не умеешь. Там кэш файловый, если что, обычно.
Ничего не знаю, конечно.
Расскажи мне, о великий гуру, как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?
Любая сериализация на объёмах до нескольких мегабайт стоит пренебрежимо мало в случае однократных вызовов на строку (понятно что бывают рукожопы, которые в цикле в цикле в цикле это делают).
Куда ты положишь свои нагенеренные кеши - неважно. Хоть в /dev/null, хоть в редис, хоть в файлы - неважно совершенно везде будет iowait.
В самом плохом случае ты просто напишешь кеш и никогда им не воспользуешься.
Но стоимость исполнения любого адекватно реализованного механизма кеширования - несоизмерима мала в сравнении со стоимостью получения объекта из нижележащих слоёв.
Вся маковка кеша в инвалидации/актуализации, но это ж думать надо про это, а не плагин кнопочкой включить :)
El Marshal Che: arturios, можете нарезать свои VLAN между серверами, подробнее тут: https://wiki.hetzner.de/index.php/Vswitch/ru Связь лучше не будет, это для организации своей L2-инфраструктуры.
Private networks же для облака, не для дедов. А vSwitch работает уже давно и успешно (ограничения только, что нельзя дозаказать второй аплинк на сервер и MTU надо делать 1400)
А вот про связность vSwitch и private networks пока ничего не увидел :(
У ТС "просто хостинг", какой второй сервер?..
Не исключено, что ТС не в курсе, кто автор системы и как "оно" работает.. Есть ли там вообще кэш.. и "какое там CMS"..
Как минимум, поэтому считаю, что советовать "включить кэш", без понимания "что и где там".. слегка опрометчиво.. Хотя.. может ведь и прокатит ))
---------- Добавлено 21.08.2019 в 00:14 ----------
там хостер письмо прислал про "какой-то лимит CPU".. Вы о чём? )))
ТС, очевидно, не знает об этом ничего и ей надо пойти взять вебмастера чтобы он разобрался. Любые другие советы - вредные.
Я о том что "кеширование создаёт нагрузку на камень" (что дичь и дурь в общем случае) и далее о двух форумных военах CMS и кеша, которые боги и всё знают. Всё остальное - о кешировании, а не о ТС. Имеющий мозг прочитает и запомнит ключевые слова из которых нагуглит.
По теме ТС ничего сказать нельзя, пока не пойдёшь и не посмотришь что там происходит на хостинге.
suffix, Генерация. PHP выполняет дополнительные действия, чтобы положить страницу на диск (кэширование выполняется средствами PHP у веб-мастеров, кэш на стороне сервера это DevOps или админ). Потом при запросе страницы нужно проверить, а кэш истёк или нет, и если он истёк (скажем, 5 минут, а посещение раз в полчаса) - удалить старые данные из кэша, сгенерировать новые, отдать клиенту и положить снова в кэш. Если таких страниц на сайте (условно) миллион - то выигрыш от такого кэша нулевой, когда кэш истекает раньше, чем будет повторно отдан. Это заставляет CMS использовать больше ОЗУ, больше делать запросов к БД, генерировать больше обращений к диску, а так же производить дополнительные действия на CPU.
Вызов stat замечательно кешируется уже на уровне операционной системы. TTL кеша на файлах эффективнее делать через stat/touch. Это убирает необходимость читать данные и проверять валидность с т.з. TTL. Это же позволяет эффективно чистить кеши. Если кеш невалиден - можно его всухую перезатирать.
Понятно, что если файловый кеш и 1М файлов в одном каталоге - это приговор почти всегда. Но, в первую очередь, это приговор автору системы кеширования, который не понимает с чем работает.
Расход RAM, кстати, при таком кешировании будет заметный, но не критичный. Расход CPU тоже, в рамках общего потребления будет три копейки. Iowait может всё попортить (особенно когда много файлов в каталоге), но это лечится переставлением рук в плечи.
Добавление второго сервера для обработки запросов делает файловый кеш тем, что использовать нельзя - любая сетевая файлуха вносит весьма заметные задержки, а держать на каждом сервере свой кеш - быстро прогрессирующая боль с инвалидацией.
Ну, это было во-первых. Во-вторых, умные ребята с Redis и прочими кэширующими системами. Чем больше кэш, тем больше занимает выборка из него, и опять же, если закэшированы десятки гигабайт данных, то вполне вероятен сценарий, когда обращение к кэшу будет происходить дольше, чем генерация страницы без кэша. Особенно файловый кэш средствами CMS.
Первая плохая новость в том, что редис - не самое хорошее решение для организации большого кеша в силу неэффективности выделения памяти в типе string. На большом количестве мелких ключей оверхед по памяти может быть в разы.
Однако, в силу того, что доступ данных по ключу что в редисе что в мемкеше по хэш-таблице - алгоритмическая сложность поиска по ней всегда константна ( О(1) ) и время поиска не зависит от количества ключей.
Большую сложность являет собой эластичность серверов кеширования алгоритмов диструбуции ключей, когда добавление/удаление серверов на лету приводит к инвалидации большого количества данных и по-сути приводит к т.н. "холодному старту", что для больших систем весьма болезненно.
Решение - консистентное хэширования области ключей.
Сравнивать это с файловым кэшем средствами CMS - за гранью добра и зла.
Дальше продолжать? Если хотите - почитайте, почему кэширование средствами MySQL не эффективно, когда кэш слишком большой и предлагается использовать кэш на уровне приложения. Не надо сравнивать взрослые вещи с кэшированием в cms.
Если говорить о встроенном в мускул кеше запросов - то это та штука, на которую не надо возлагать больших надежд (ключом выступает особенность инвалидации всей таблицы при изменении строки. Однако, эти данные достаточно старые и, возможно, в мире MySQL все поменялось.
Есть ещё подход с хранением данных кеша в таблице с индексом по ключу. Но это такое... Такие таблицы - обычно write-intensive, что быстро приводит к деградации индексов и росту грязных страниц. Лучше уж в файлы.
Bananzz, скажем, учи матчасть. Генерация кэша сама по себе ресурсы кушает, и далеко не всегда уместна. Это не то кэширование, которое ты тут нам усиленно описываешь. И да, в вордпрессе оно реализовано, мягко говоря, плохо в очень многих случаях. Тут тебе говорят про конкретный продукт, а не про баззворды.
Во-первых, автор темы не упоминал вордпресс.
Во-вторых, генерация on-demand кеша как отдельный подпроцесс почти ничего не стоит: всё что должно быть в кеше должно генерироваться и без кеша: осталось сериализовать и записать. Как конкретно реализовано оно wp - мне плевать, у меня этого в продакшне нет (слава богу).
В-третьих, я не услышал как конкретно процесс генерации кеша может вызывать всплески использования "камня".
В-четвертых, любое кеширование по своей сути устроено одинаково. Хоть где и хоть на каком языке. (Пока мы говорим про веб-приложения).
Так что, у меня с матчастью хорошо, как и с практикой.
И, да, я всё ещё жду ответа: как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?
Судя по сообщению нихрена не знаешь и не умеешь. Там кэш файловый, если что, обычно.
Ничего не знаю, конечно.
Расскажи мне, о великий гуру, как файловый кеш на хостинге на локальном диске может нагенерить много cpu time?
Любая сериализация на объёмах до нескольких мегабайт стоит пренебрежимо мало в случае однократных вызовов на строку (понятно что бывают рукожопы, которые в цикле в цикле в цикле это делают).
Куда ты положишь свои нагенеренные кеши - неважно. Хоть в /dev/null, хоть в редис, хоть в файлы - неважно совершенно везде будет iowait.
В самом плохом случае ты просто напишешь кеш и никогда им не воспользуешься.
Но стоимость исполнения любого адекватно реализованного механизма кеширования - несоизмерима мала в сравнении со стоимостью получения объекта из нижележащих слоёв.
Вся маковка кеша в инвалидации/актуализации, но это ж думать надо про это, а не плагин кнопочкой включить :)
Та!
С лёгкостью!
И тебе тот же вопрос - какой кеш?
Шта?
Кто кого на что меняет?
Иди учи и что такое кеш вообще и какие ьывают и на каком уровне что посходит.
Да даже не хреново настроенный, но применённый бездумно.
Я типа знаю и умею и обслуживаю несколько тысяч rps, друк)
И работал с кешами от in-process-memory в рамках аппсервера до банального кеширования рендеров на файликах в post-ssi-stage.
(И это мы ещё не касались клиентского кеширования)
Так что иди и учи сам 🤣 🤣 🤣
Самый глупый "совет". Не зная причин такое советовать.
А какой кеш надо включать?
Может это как раз "кеш" создаёт нагрузку на камень
Шта? Как кеш может создавать нагрузку на камень? Кеш - это по определению размен времени (io,net,cpu) на память.
не в тему, конечно, но на MSK-IX сегодня тоже были проблемы))
Поспрашивал по знакомым - говорят оптику порвали им.
arturios, можете нарезать свои VLAN между серверами, подробнее тут: https://wiki.hetzner.de/index.php/Vswitch/ru
Связь лучше не будет, это для организации своей L2-инфраструктуры.
Private networks же для облака, не для дедов. А vSwitch работает уже давно и успешно (ограничения только, что нельзя дозаказать второй аплинк на сервер и MTU надо делать 1400)
А вот про связность vSwitch и private networks пока ничего не увидел :(
показывает, что сервер работает не на мегачипах Realtek, а на боле-менее нормальной железке.
А что с риалтеками не так?
Samsung Evo никто не хочет предлагать, хотя в большинстве народа они и стоят. гг
потому что они - полное Г под серверной нагрузкой)
полторы тыщи иопсов в режиме журнала же, просто выкинуть нахрен; прошные самсунги - сравнимый отстой
(у SM863, например, 32к iops в таком режиме)
но, справедливости ради, видео стримить с них - вполне приемлемо