Ilya74#: Вы должны понимать, что любая панель как раз и создана для того, чтобы автоматизировать управление конфигами. То есть использование панели не предполагает параллельную работу методов ручной настройки и настройки панелью. Во многих панелях есть функционал внесения изменений в конфиги сайтов через саму панель, лучше пользоваться данным функционалом.
Это я понимаю, поэтому и не хочу ничего менять, т.к. пока все работает нормально, как говорят работает не трогай.
Так в том-то и вопрос, я знаю, что даже через панель управления под root’ом можно кликнуть на веб-сайт и там изменить конфигурационный файлы веб-серверов, как apache, так и nginx, хотя я это могу сделать и через консоль, но не важно, важно, что произойдет, когда я опять через панель управления поменяю какие-либо настройки у веб-сервера, перезапишет ли конфигурационный файл, удалятся ли мои изменения и т.п.
Всем спасибо, я наконец то перешел на современный сервер, переход был не без проблем, но в целом как я себе и представлял, в общем относительно гладенько прошел, получил новое программное обеспечение, новые технологии в виде статов VPSсервера, такие как DDR5, NVMe, CPU очень быстрый, быстрее по частоте не видел ни у кого, ну и естественно сайтик стал чутка побыстрей работать.
webinfo#: Плохо то, что такие деятели, так ничего и не понявшие, потом разносят "свой опыт", и кто-то из новичков может повестись и поверить, что так оно и есть. А так-то чёрт с ним, хочешь так думать - думай сколько угодно. Только никому об этом не рассказывай.
Да, я и не спорю, просто при обновлении(загрузке) страницы веб-сайта, что до, что после, одна и та же скорость по DOMContentLoaded, так что по сути ничего не изменилось. [ А как оно могло измениться, если по сути уже подготовленная и готовая страница в кэше от <!DOCTYPEhtml> до </html> отдается посетителю сайта, там уже никакие процессы с базой данных, phpи т.п. не идут, там вообще страница в статья.htmlформате, хз, в общем пусть будет эта странная загадка для меня ]. Естественно это все как говорится ИМХО. И это не для новичков, это для себя, а им я бы советовал самим протестировать и посмотреть, там в три клика это делается.
Попробовал я этот постоянный объектный кэш, все по классике – memcachedна сервере, memcacheкак расширение в PHPи связующее звено в виде плагина Memcached Object Cache в wp-content.
И знаете, что, правильно, ничего не изменилось, а собственно, что могло измениться если что раньше готовые страницы из кэша отдавались, что и сейчас, в плане скорости ничего не поменялось, единственное плашка с предупреждением что нужно использовать объектный кэш в Здоровье сайта в админке WordPress, пропала.
Ну, собственно как обычно, пока сам не попробуешь не узнаешь. Можно было и не заморачиваться.
Все понятно, все ОК, нету в этом смысла никакого, с этим не стоит и заморачиваться, это не прибавит ничего к скорости загрузки страницы, это бесполезная трата времени, ты прав.
Встал Димка за прилавок изюм продавать. За обедом поинтересовался товаром у коллег. .. После общения у него в голове ещё больший сумбур: причем тут виноградари и цеха для сушки и упаковки, если покупатель получает изюм в пакетике.
Да, не, я все понял, этот объектный кеш прибавит чутка в создании обычного кеша страниц на стороне сервера, а для обычных посетителей ничего не изменится, они как получали готовую страницу, так и буду, короче вы правы с этого смысла нет заморачиваться, а на сервере у меня и так быстро создаются эти страницы, так что да ты прав, нет вкуснее изюма в пакетиках.
Тяжелый случай. Ещё раз вчитайтесь и вдумайтесь в тот пост: как именно готовые для юзера html страницы помещаются в кэш, какие процессы происходят. Человек Вам совершенно точно и подробно ответил на Ваш вопрос.
С тяжелым случаем соглашусь :), но так самый главный вопрос в том, что это не влияет на конечную производительность для посетителей сайта, ну то есть быстрей не будет загружаться страница, так и смысл в этом, чтобы файлы быстрей на сервере создавались в кэш, так это фигня.
divv#: Объектный кэш поможет быстрее создавать эти файлы и меньше ресурсов сервера понадобится. В основном нужно когда есть много медленных однотипных запросов на разных страницах.
То есть речь идет о создании файлов кеша, а не об отдаче уже готовых страниц, тогда для посетителей это ничего не изменит в плане скорости загрузки страницы у них в браузере.
Объяснить это очень просто: нужно написать, кто их кеширует и по чьей команде или в какой момент времени.
Их кеширует плагин, не знаю что он там использует наверное CronWordpress’овсикй, да это и не важно, создается htmlстраница, которая хранится в определенной директории и уже эта страница готовая, отдается веб-сервером посетителю сайта.
Посетители сайта не ждут создание кеша, и не знают об его существовании, они видят и получают уже созданный htmlдокумент в микросекунду, отданный им NGINX’ом.
Вы должны понимать, что любая панель как раз и создана для того, чтобы автоматизировать управление конфигами. То есть использование панели не предполагает параллельную работу методов ручной настройки и настройки панелью. Во многих панелях есть функционал внесения изменений в конфиги сайтов через саму панель, лучше пользоваться данным функционалом.
Это я понимаю, поэтому и не хочу ничего менять, т.к. пока все работает нормально, как говорят работает не трогай.
Так в том-то и вопрос, я знаю, что даже через панель управления под root’ом можно кликнуть на веб-сайт и там изменить конфигурационный файлы веб-серверов, как apache, так и nginx, хотя я это могу сделать и через консоль, но не важно, важно, что произойдет, когда я опять через панель управления поменяю какие-либо настройки у веб-сервера, перезапишет ли конфигурационный файл, удалятся ли мои изменения и т.п.Плохо то, что такие деятели, так ничего и не понявшие, потом разносят "свой опыт", и кто-то из новичков может повестись и поверить, что так оно и есть. А так-то чёрт с ним, хочешь так думать - думай сколько угодно. Только никому об этом не рассказывай.
Попробовал я этот постоянный объектный кэш, все по классике – memcached на сервере, memcache как расширение в PHP и связующее звено в виде плагина Memcached Object Cache в wp-content.
И знаете, что, правильно, ничего не изменилось, а собственно, что могло измениться если что раньше готовые страницы из кэша отдавались, что и сейчас, в плане скорости ничего не поменялось, единственное плашка с предупреждением что нужно использовать объектный кэш в Здоровье сайта в админке WordPress, пропала.
Ну, собственно как обычно, пока сам не попробуешь не узнаешь. Можно было и не заморачиваться.Нихрена ты не понял.
Кратко о топике.
Встал Димка за прилавок изюм продавать. За обедом поинтересовался товаром у коллег. .. После общения у него в голове ещё больший сумбур: причем тут виноградари и цеха для сушки и упаковки, если покупатель получает изюм в пакетике.
Тяжелый случай. Ещё раз вчитайтесь и вдумайтесь в тот пост: как именно готовые для юзера html страницы помещаются в кэш, какие процессы происходят. Человек Вам совершенно точно и подробно ответил на Ваш вопрос.
Объектный кэш поможет быстрее создавать эти файлы и меньше ресурсов сервера понадобится. В основном нужно когда есть много медленных однотипных запросов на разных страницах.
Объяснить это очень просто: нужно написать, кто их кеширует и по чьей команде или в какой момент времени.
Их кеширует плагин, не знаю что он там использует наверное Cron Wordpress’овсикй, да это и не важно, создается html страница, которая хранится в определенной директории и уже эта страница готовая, отдается веб-сервером посетителю сайта.
Посетители сайта не ждут создание кеша, и не знают об его существовании, они видят и получают уже созданный html документ в микросекунду, отданный им NGINX’ом.