etrafik, ну, во-первых, все это происходит внутри инфраструктуры хостинга и говорить о неправомерном доступе к данным стоит разве что в случае если вы будете потом в макдоналдсе по wifi бекапы скачивать и разворачивать.
Во-вторых, в чем проблема зашифровать архивы с паролем ?
Пусть панель создает файлы локально, а дальнейшее шифрование и закачку сами реализуйте скриптом. 7zip или rar, по собственным предпочтениям.
Ну, допустим, инструкции от современных панелей proxmox почитайте и решите действительно ли оно стоит того.
Ничего революционного или оригинального, эти технологии не ими придуманы, но там хотя бы кнопки и картинки есть. Они обеспечивают поддержку высокой доступности сферических виртуальных машин в вакууме.
И нужно учитывать, что жизнь станет сложнее, а сайты работать медленнее.
И все ради чего ? Так что эта старая песня для обычных сеошников всегда заканчивается одинаково - люди просто выбирают сервер и датацентр понадежней и побольше.
Если интересна их выгода, то ddos ведь им тоже в некотором смысле выгоден : можно узнать и запомнить IP ботов чтобы потом легче блокировать для других платных клиентов.
хотя никто этого не видел, но формально гугл оставляет за собой право блокировать вредоносные сайты через dns в качестве исключения:
https://developers.google.com/speed/public-dns/faq#filtering
Пока не слышал о таких блокировках, но почему бы и нет ?
А зачем ему разлетаться ? Что именно вы делали с DNS недавно ?
и что это вы мне пытаетесь доказать ? Полностью бесполезная информация для меня и читателей форума. У вас вариантов то других нет.
Не может быть так чтобы вообще ничего не изменилось. Отключайте и измеряйте.
Да для vbulletin ресайз - это часть основного кода и написан нормально. Не вижу на форуме так же и водяных знаков.
Например, необходимость в cyb advanced forum statistics мне кажется надуманной. Выкиньте. Там никакой полезной пользователю информации нет, а 3 дополнительных ajax-запроса на главной есть. Вряд ли этот хак так уж сильно грузит, но он тоже вызывает код глобальной инициализации и тут уже другие хаки могут подключаться зазря.
Что OVH может - то и предлагает. Часть запросов будут уходить на другой сервер. Но как вы собираетесь заставить эту информацию на разных серверах быть совместной ? OVH предполагает, что вы это будете делать сами. Никаких чудес.
Все же выгоднее один раз профилировать нормально, отключить/заменить /переписать хаки.
Прежде всего надо понять что это кеш результатов запросов. Он не такой как специально созданные кеши в cms и тд - очищается при любом пуке в базу. И кешировать пытается вообще все запросы, в том числе, которые наверняка не будут нужны в будущем.
Поэтому, например, 26 числа вы увеличивали размер и делали перезапуск, но на третьем графике число попаданий (синенькое) заметно не выросло. И хотя число запросов в кеше росло исправно, толку от них нет, только память занимают.
Можно считать, что и раньше все было нормально.
И эта пометка не просто так. При бОльших размерах кеша вероятны "странные зависания" связанные с очисткой кеша.
Так в этом случае memcached plugin собственно кешированием в памяти не занимается. Вообще непонятно зачем такой совет.
vit_hol, все же, исходя из частых ситуации какие-то предположения можно делать :
если раньше с меньшими ресурсами все было лучше, а число соединений достигает аж 404, то речь должна идти об ограничении лавинообразных процессов. Поставьте nginx, укажите в apache скромный MaxClients - 50-70 вам хватит.
Current query_cache_size = 512 M - уменьшите до 128М.
с одной стороны все показания чтобы увеличить до 1/4 RAM, как там сказал скрипт, но не менее часто люди держат несколько старых копий бд, где эти индексы лежат мертвым грузом. "надо смотреть".
Кроме того, когда вы переезжаете на другие версии mysql или даже просто восстанавливаете из бекапов (и все другие ситуации, которые приводят к перестроению статистики), планы выполнения запросов могут поменяться в худшую сторону. Тем более если у вас самопис. Тут уж точно надо их смотреть.
KRyM, на этом сайте Apple HLS.
