aleksandrbol: Redis и Memcached на хостинге есть по умолчанию. И всё это на шареде.
То что он есть, это хорошо. Вопрос в том, решает ли этот инструмент возложенные на него задачи, т.е. помогает ли он в борьбе с нагрузкой, улучшает ли скорость ответа сервера? Если да, то ок. Но боюсь что в случае с нагрузкой, Redis на шареде ничем не поможет. Вас просто выпрут, может чуть позже, чем если бы у вас не было этого редиса. Можете сами попробовать долбануть по своему сайту каким-то siege, с редисом и без. Ну или давайте я долбану, ради эксперимента.
Aisamiery: Кэш вреден только там, где как раз у него быстрое протухание, очень быстрое.
Неправда, у кеширования может быть срок в миллисекундах, борьба с всплесками, микрокеширование, троттлинг и т.д.
Aisamiery: У кеширования только 2 проблемы - размер (вам надо хранить данные как есть, а так же закешировать одни и те жи данные по неколько раз в зависимости от того что кешируете) и инвалидация (сносить весь кеш не вариант, если нагрузка большая то сдохнет сразу все от этого действия). Точнее проблемы три, третья возникает только на хайлоадах и представляет из себя собственно генерацию этого самого кэша. Многие нагруженные проекты под генерацию кеша держат целые отдельные кластера.
Из всего этого, основной проблемой является только инвалидация. Простые и средней сложности кейсы решаются через всякие декораторы и проксирование.
Размер кеша, теоретически, неограничен, практически ограничен только бюджетом на кластер или сервер. Я бы скорее сказал, что это проблема не кеша, а монетизации ресурса. Редко бывают случаи, когда кеш избыточен и можно не писать часть данных.
Aisamiery: самое главное видеть статистику HIT и MISS, если у вас много промахов, значит кэш настроен неправильно и он вам во вред.
Это такая, поверхностная метрика, которая указывает только на то, что вы попадаете в ключи (нету ошибок в логике приложения, когда одни и те же данные сохраняются и запрашиваются по разным ключам), и что у вашего кеша выставлен достаточный (а может и избыточный) срок. Мерить эффективность кеша нужно реальным стресс-тестом: либо смотреть % прироста tps, либо смотреть % сэкономленного процессорного времени при той же нагрузке, остальные метрики за уши притянуты.
В целом, если сравнивать хостинг и VPS, я бы провел аналогии с маршруткой и личным авто:
Маршрутка (хостинг):
- едете все в одной коробке, можно попасть в наглухо забитую маршрутку (забитая нода)
- нельзя включить свою музыку (ограниченный выбор софта), только наушники (минимальный набор настроек php)
- дешево, не нужно ремонтировать и следить за состоянием
Свое авто (VPS):
- едешь один (не берем в расчет оверселл)
- можно включить музыку и климат (нету ограничений по софту)
- дорого, нужно обслуживать, заправлять, ремонтировать (обновления, секьюрити патчи)
Если хостинг не падает, и при этом сайт не уперся в лимит по ресурсам, смысла переезжать на VPS не вижу. Я держу свои проекты на VPS, но из-за того зоопарка что мне приходится использовать: nginx, Postgres, Redis, RabbitMQ, на хостинге с этим не пустят. А так я бы с удовольствием ушел куда-то на шаред, если бы там это все было.
'[umka: ;15493828']Но вообще, апгрейды нужны не для увеличения производительности, а для увеличения стабильности и расширения функционала. Для увеличения производительности нужно апгрейдить железо и кэш :)
Я бы так не сказал, новые фичи не всегда обкатаны, те-же HASH индексы на Postgres внедрить-внедрили, но WAL не поддерживают (не поддерживали, сейчас вроде все ок). С другой стороны, уже существующие функции оптимизируют, меняют алгоритмы, ускоряют.
Второй причиной, по которой я не согласен, является тот факт, что внедрив новые фичи, ты больше не можешь откатиться назад, если нету обратной совместимости. Заюзал новый класс/функцию в новой версии ПО, поймал какой-то редкий баг, назад откатываешься через GIT и кучу геморроя.
Так что я ставлю обновления по вот таким критериям:
silicoid: то это без сурового джи эса не обойтись.
Там не очень то и сурово.
silicoid: апд2 la belle с точки зрения итальянского языка является ошибкой la - это неопределенный артикль для женского рода в единственном числе belle -означает красивые (множественное число женского рода -- оканчивается на е ) то-есть налицо несогласование артикля и прилагательного правильно было бы le belle
Sly32: Мда... На шареде число одновременных соединений обычно в районе 20, даже на одноядерном ВПС можно до 1000 ставить безболезненно
Скорость однозначно увеличится в разы даже при базовой настройке!
Во-первых, количество открытых соединений на хостинге в разы больше, чем ты сказал. Во-вторых, на клиенте (в браузере) максимальное количество открытых соединений около 8 (при HTTP/1) или 1 (при HTTP/2) с поддержкой мультиплексирования. Как это повлияет на скорость загрузки?
Четверьг: Хостинг hts.ru. Так то вроде нет у меня к ним негатива. Несколько раз были косяки, но так терпимо вообщем.
Думаю, что ускорение будет. Хостинг может быть и надежный, но точно не на последнем железе.
Четверьг: ЦМС- шопскрипт (древняя 3.0. Сейчас перехожу на ШС7, посмотрю сначала как она будет работать)
У меня был опыт ускорения этой CMS, могу показать результат на VPS за 10 баксов. Не прям огонь, но пару дней поигравшись, удалось улучшить результат. Если интересно - пишите в личку, поделюсь ссылками.
VPS иногда медленнее шаредов. На шареде обычно доступны все ресурсы сервера, там оптимизирована база, куча ядер и все такое, поэтому сам запрос шаред обрабатывать может быстрее, если конечно он не забит сайтами в усмерть. На VPS можно поставить экзотический софт, и сконфигурировать его как вам угодно. Но в целом, если взять VPS и пошаманить, то можно улучшить скорость.
На VPS обычно делаю такой чеклист:
SSL + HTTP/2 (для статики +, для нагрузки и скорости до TLS соединения однозначно минус)
Увеличиваю буфферы у access_logs и fastcgi_buffers
Отключаю логи на всякие иконки и статику (стили, JS)
Ставлю Redis, пробрасываю туда сессии PHP
Ставлю адаптер Redis под CMS (если есть)
Если сайт может существовать в статическом виде (блоги и т.п., магазины редко) - делаю fastcgi_cache.
Меняю opcache конфиг (точно не скажу что именно, давно не заглядывал туда)
Долго гоняю сайт бенчмарками, настраиваю базу (уменьшаю количество максимальных соединений чтобы не жрала много оперативки, уменьшаю некоторые буфферы)
Если все равно тупит, настраиваю лог запросов без индексов и slow_query_log, смотрю что за запросы тормозят работу. По возможности переписываю, оптимизирую, но если это CMS, то тут сложно что-то поделать, так как переписать запрос значит запретить обновления.
Дает прирост где-то 20% если перезжать с хорошего хостинга на хорошую VPSку. Если с говнохостинга съезжать, то тут можно и все 200% заиметь. Если fastcgi_cache - то прирост может быть очень большой (около 1400%), но там придется помучиться с настройкой.
А вообще, уже давно не пользуюсь CMS. Если что-то нужно, то пишу свое.
Только вы немного напутали. Горизонтальное масштабирование - это когда в кластер серверов добавляют. А наращивание мощности в рамках одной машины - вертикальное масштабирование. Вертикальное масштабирование и быстрее, и дешевле. Но не бесконечное.
edogs: А учитывая интересную манеру ВП кэшировать в пхп файлы, которые потом кэшируются опкэшем - это еще вопрос вообще умный ход там включать этот кэш или нет, т.к. в ряде случаев сей бред приводит к тому, что при каждом чихе сервак занимается запихиванием всего в кэш, вместо отдачи юзеру страницы - что как раз и создает тормоза.
Не особо разбираюсь в ВП, так кликал пару раз, но откуда вы взяли эту инфу? И что именно он кеширует в PHP файлы? Или вы имеете ввиду работу плагинов по ускорению?
Сколько не смотрел, что метрика, что Google Analytics, показывают какой-то рандом. Бывает скорость загрузки падает чуть ли не в пол, и держится там неделю, потом растет обратно.
Забыл как называется штука, когда картинки с вашего сайта вставляют на других сайтах. Аналитика такое не палит (кроме серверной), возможно у вас тот же случай. Но тут нужно смотреть, чтобы количество входящего трафика тоже чуть выросло. Если количество входящего трафика не менялось, тогда возможен взлом.
Redis и Memcached на хостинге есть по умолчанию. И всё это на шареде.
То что он есть, это хорошо. Вопрос в том, решает ли этот инструмент возложенные на него задачи, т.е. помогает ли он в борьбе с нагрузкой, улучшает ли скорость ответа сервера? Если да, то ок. Но боюсь что в случае с нагрузкой, Redis на шареде ничем не поможет. Вас просто выпрут, может чуть позже, чем если бы у вас не было этого редиса. Можете сами попробовать долбануть по своему сайту каким-то siege, с редисом и без. Ну или давайте я долбану, ради эксперимента.
Кэш вреден только там, где как раз у него быстрое протухание, очень быстрое.
Неправда, у кеширования может быть срок в миллисекундах, борьба с всплесками, микрокеширование, троттлинг и т.д.
У кеширования только 2 проблемы - размер (вам надо хранить данные как есть, а так же закешировать одни и те жи данные по неколько раз в зависимости от того что кешируете) и инвалидация (сносить весь кеш не вариант, если нагрузка большая то сдохнет сразу все от этого действия). Точнее проблемы три, третья возникает только на хайлоадах и представляет из себя собственно генерацию этого самого кэша. Многие нагруженные проекты под генерацию кеша держат целые отдельные кластера.
Из всего этого, основной проблемой является только инвалидация. Простые и средней сложности кейсы решаются через всякие декораторы и проксирование.
Размер кеша, теоретически, неограничен, практически ограничен только бюджетом на кластер или сервер. Я бы скорее сказал, что это проблема не кеша, а монетизации ресурса. Редко бывают случаи, когда кеш избыточен и можно не писать часть данных.
самое главное видеть статистику HIT и MISS, если у вас много промахов, значит кэш настроен неправильно и он вам во вред.
Это такая, поверхностная метрика, которая указывает только на то, что вы попадаете в ключи (нету ошибок в логике приложения, когда одни и те же данные сохраняются и запрашиваются по разным ключам), и что у вашего кеша выставлен достаточный (а может и избыточный) срок. Мерить эффективность кеша нужно реальным стресс-тестом: либо смотреть % прироста tps, либо смотреть % сэкономленного процессорного времени при той же нагрузке, остальные метрики за уши притянуты.
В целом, если сравнивать хостинг и VPS, я бы провел аналогии с маршруткой и личным авто:
Маршрутка (хостинг):
- едете все в одной коробке, можно попасть в наглухо забитую маршрутку (забитая нода)
- нельзя включить свою музыку (ограниченный выбор софта), только наушники (минимальный набор настроек php)
- дешево, не нужно ремонтировать и следить за состоянием
Свое авто (VPS):
- едешь один (не берем в расчет оверселл)
- можно включить музыку и климат (нету ограничений по софту)
- дорого, нужно обслуживать, заправлять, ремонтировать (обновления, секьюрити патчи)
Если хостинг не падает, и при этом сайт не уперся в лимит по ресурсам, смысла переезжать на VPS не вижу. Я держу свои проекты на VPS, но из-за того зоопарка что мне приходится использовать: nginx, Postgres, Redis, RabbitMQ, на хостинге с этим не пустят. А так я бы с удовольствием ушел куда-то на шаред, если бы там это все было.
;15493828']Но вообще, апгрейды нужны не для увеличения производительности, а для увеличения стабильности и расширения функционала.
Для увеличения производительности нужно апгрейдить железо и кэш :)
Я бы так не сказал, новые фичи не всегда обкатаны, те-же HASH индексы на Postgres внедрить-внедрили, но WAL не поддерживают (не поддерживали, сейчас вроде все ок). С другой стороны, уже существующие функции оптимизируют, меняют алгоритмы, ускоряют.
Второй причиной, по которой я не согласен, является тот факт, что внедрив новые фичи, ты больше не можешь откатиться назад, если нету обратной совместимости. Заюзал новый класс/функцию в новой версии ПО, поймал какой-то редкий баг, назад откатываешься через GIT и кучу геморроя.
Так что я ставлю обновления по вот таким критериям:
- security fixes
- оптимизации и улучшения
- новые фичи
то это без сурового джи эса не обойтись.
Там не очень то и сурово.
апд2
la belle с точки зрения итальянского языка является ошибкой
la - это неопределенный артикль для женского рода в единственном числе
belle -означает красивые (множественное число женского рода -- оканчивается на е )
то-есть налицо несогласование артикля и прилагательного
правильно было бы le belle
извините, только с лекции по итальянскому приехал
Нужно ещё на лекции по французскому сходить :)
Мда... На шареде число одновременных соединений обычно в районе 20, даже на одноядерном ВПС можно до 1000 ставить безболезненно
Скорость однозначно увеличится в разы даже при базовой настройке!
Во-первых, количество открытых соединений на хостинге в разы больше, чем ты сказал. Во-вторых, на клиенте (в браузере) максимальное количество открытых соединений около 8 (при HTTP/1) или 1 (при HTTP/2) с поддержкой мультиплексирования. Как это повлияет на скорость загрузки?
Хостинг hts.ru. Так то вроде нет у меня к ним негатива. Несколько раз были косяки, но так терпимо вообщем.
Думаю, что ускорение будет. Хостинг может быть и надежный, но точно не на последнем железе.
ЦМС- шопскрипт (древняя 3.0. Сейчас перехожу на ШС7, посмотрю сначала как она будет работать)
У меня был опыт ускорения этой CMS, могу показать результат на VPS за 10 баксов. Не прям огонь, но пару дней поигравшись, удалось улучшить результат. Если интересно - пишите в личку, поделюсь ссылками.
VPS иногда медленнее шаредов. На шареде обычно доступны все ресурсы сервера, там оптимизирована база, куча ядер и все такое, поэтому сам запрос шаред обрабатывать может быстрее, если конечно он не забит сайтами в усмерть. На VPS можно поставить экзотический софт, и сконфигурировать его как вам угодно. Но в целом, если взять VPS и пошаманить, то можно улучшить скорость.
На VPS обычно делаю такой чеклист:
Дает прирост где-то 20% если перезжать с хорошего хостинга на хорошую VPSку. Если с говнохостинга съезжать, то тут можно и все 200% заиметь. Если fastcgi_cache - то прирост может быть очень большой (около 1400%), но там придется помучиться с настройкой.
А вообще, уже давно не пользуюсь CMS. Если что-то нужно, то пишу свое.
При условии, что crayon- у вас не изменяемая часть. Если изменяемая часть, тогда нужно видеть сайт, чтобы по nth-child выбрать.
Вы случаем не в чужой iframe залезть пытаетесь? Если да, то у вас ничего не выйдет.
горизонтальное масштабирование
Только вы немного напутали. Горизонтальное масштабирование - это когда в кластер серверов добавляют. А наращивание мощности в рамках одной машины - вертикальное масштабирование. Вертикальное масштабирование и быстрее, и дешевле. Но не бесконечное.
А учитывая интересную манеру ВП кэшировать в пхп файлы, которые потом кэшируются опкэшем - это еще вопрос вообще умный ход там включать этот кэш или нет, т.к. в ряде случаев сей бред приводит к тому, что при каждом чихе сервак занимается запихиванием всего в кэш, вместо отдачи юзеру страницы - что как раз и создает тормоза.
Не особо разбираюсь в ВП, так кликал пару раз, но откуда вы взяли эту инфу? И что именно он кеширует в PHP файлы? Или вы имеете ввиду работу плагинов по ускорению?
Сколько не смотрел, что метрика, что Google Analytics, показывают какой-то рандом. Бывает скорость загрузки падает чуть ли не в пол, и держится там неделю, потом растет обратно.
Забыл как называется штука, когда картинки с вашего сайта вставляют на других сайтах. Аналитика такое не палит (кроме серверной), возможно у вас тот же случай. Но тут нужно смотреть, чтобы количество входящего трафика тоже чуть выросло. Если количество входящего трафика не менялось, тогда возможен взлом.