Что понимается под "Webmoney"? wmz, wme, wmr? Но ведь нет уже wmu.
Возникает вопрос, как себе это представляете "с webmoeny сразу за ЖКХ платить"? Я там конечно давненько не был, но сомневаюсь, что в Украине за свет уже в евро принимают оплату.
Сделать любую официальную оплату по Украине можно исключительно в гривнах. Также как по России в рублях. Не в баксах, не в [что_угодно]коинах, а только в валюте страны.
А если нет wmu, то и никаких оплат за ЖКХ быть не может. И я смутно понимаю как это работало раньше, скорей всего те самые "сайты" работали как обычные обменники: вы им wm, а они нормальными банковскими способами оплачивали хоть ЖКХ, хоть что угодно.
Т.е. просто любым способом меняете webmoney на тот же приват24 и уже с него оплачиваете.
Вот первый попавшийся обменник: https://smartwm.ru/
Пока я вижу лишь эмоции... и неизвестные:
1) Что конкретно измеряется? Полная загрузка сайта или TTFB
2) Одинаково быстро на глаз или чем-то измерено? Чем, Pagespeed'ом чтоли?
3) Речь вообще про какой-то реальный законченный сайт или голый WP?
4) Никто не знает что там у вас было ранее. Может сервер был в США или европах каких-нибудь, а сейчас взяли рядом с собой по Украине - вот и есть ощущение что сильно шустрей стало.
Но вообще да, относительно голый wp под php 7.4 вполне шустр и без кэш плагинов. Но только на глаз. Если всеж взглянуть на циферки, то нет - с кэшем еще шустрей. Приблизительно если пинг 50мс, то с кэшем около 50мс и будет, а без него - около 100мс. Практически незаметно на глаз, но разница есть.
Если особо без траффика, то конечно можно не заморачиваться, а если десятки-сотни К посетителей, то каждый десяток ms задержки на счету.
Да все эти "nvme ssd" - практически последнее что влияет на скорость сайта. В порядке убывания я бы расставил: Сам сайт (скрипты, запросы к базам и т.д.), процессор (частота, а не ядер число), память и только потом уже диск.
Да мне-то оно не надо :) Вот так по симптомам лечить считаю бесполезным делом. Можно бесконечно выдвигать предположения, но это все равно будут лишь догадки, случаи и ситуации бывают очень разные.
Я вам предложил бесплатно разместить сайт (раз уж все равно в поисках куда переехать), там бы уже вживую посмотрел и наверняка решили проблему.
Не хотите - как хотите конечно. Попробуйте найти кого-то (не бесплатно видимо) с опытом и репутацией, кого сможете пустить на свой нынешний хостинг взглянуть что там как.
cy-pr.com/forum/f80/t109623/
Там вам почти сразу правильно ответили что делать - "Начать с анализа логов".
Неизвестных вредных ботов конечно же надо банить. Но даже для этого надо изучать логи, чтоб понимать по какому критерию банить.
Но как бы то ни было, если сайт ложится от ботов - это плохо. Позже вместо них придут (как планируете) люди и тоже будет ложиться?
В любом случае, первоочередная проблема - сам ваш сайт. Надо стремиться делать его максимально шустрым чтобы хоть люди, хоть боты не ложили его.
Ваш сайт был ограничен в течение последних 24 часов
Т.е. всеж висят одновременно 40 php скриптов каких-то и следом еще приходят запросы, 41 обрубает. Так видится.
Ок. Говорите сайт-новостник. А как он работает, откуда-то из вне ведь берет данные? Может какраз тот случай как я выше рассказывал - скрипты запрашивают что-то с других сайтов, те тормозят и у вас накапливаются процессы зависшие.
Но у них в таблице разве есть лимит на количество обращений?
Значит либо таки есть у них такой скрытый лимит, либо под "большое количество обращений" всеж подразумевается повышенное потребление процессора.
Если не хватает знаний оценить по логам примерную картину присходящего (может там у вас большое количество обращений от всяких ботов-брутфорсеров, а вовсе не от нормальных посетителей на сайте), если нет инструментов (например ssh доступа) для наблюдения что происходит в момент ошибок. То один из вариантов - пригласить кого-то с хорошим опытом именно в wordpress'е взглянуть что можно сделать, либо вслепую бегать с одного хостинга на другой, не понимая чего вам не хватает пока на одном из них вам не объяснят более конкретно, мол грузит процессор конкретно вот этот тип запросов, вот эти скрипты или типа такого.
Так берите максиму :)
Все равно не понятно что входит в понятие "не справляется".
Надо не смотреть на 508 ошибку, а общаться с поддержкой. Они бы направили в какую сторону смотреть, которых именно resources limit is reached.
Могут быть же разные варианты даже по вашей табличке.
1) Самый частый - ваш сайт потребляет процессора больше, чем выделено тарифом.
Не понятно что там подразумевается под цифрами, но предположим 100% - это разрешено на 100% грузить 1 ядро круглые сутки. В вашем случае выходит сайт 2 ядра грузит полностью (просто предполагаю).
В этом случае вместо наращивания мощности хостинга (и цены соответственно) обычно правильней и дешевле поковыряться еще в самом сайте, и постараться облегчить те самые "тяжелые" запросы.
А может также быть что на основной части сайта тяжелые не такие уж и тяжелые, но есть какие-то части сайта, которые ну ооочень тяжелые и именно они влияют на общую картину нагрузки на процессор.
Реальный пример из прошлого - сайт вроде работает более-менее шустро и легко, но стоял модуль, который генерирует файлы sitemap каждый раз на лету. И боты периодически их запрашивают - процессор на несколько секунд подскакивает на 100% одним ядром. Чаще запрашивают - соответственно уже реально мешает весь этот сайт и весь этот аккаунт всем остальным на сервере.
Ну или просто могут у вас страницы генерироваться в real-time. И может каждая отдельная не так уж и тяжело/долго это делает, но умножив на количество запросов получается суммарно прилично.
В любом случае вывод - смотреть где есть "тяжелые" места на сайте и стараться по возможности облегчить эти запросы.
2) Может вы упираетесь в количество запущенных процессов. Но тут не понятно, 40 это не так уж и мало, но что это такое, количество процессов на backend'е, т.е. скриптовое что-то или может быть такое что на сервере стоит только один апач и он сам отдает статику и динамику. В этом случае (учитывая не маленький траффик) 40 может уже оказаться вовсе не так и много. И возможно в пики посещений апач там разрывается отдавая и статики кучу и скрипты.
Либо еще такая ситуация бывает: Сайт сам по себе процессор не грузит, ничего тяжелого не делает, но скрипты скачивают каждый раз что-то со сторонних ресурсов. Т.е. запрос главной страницы - скрипты полезли куда-то в инет скачивать с другого сайта, ждут так секудну-другую и в это время процессор ничего не делает, но один процесс уже по-сути заблокирован в ожидании ответа. Следом другой запрос и тоже встал на паузу... и вот так накапливаются, не грузя процессор, но лимит 40 процессов исчерпывается в пиках.
А может память, может что угодно другое. Самое верное - спросить у хостера что происходит в моменты 508 ошибок, чего именно не хватает.
И либо искать где именно этого ресурса вам больше предложить смогут по подходящей цене, либо пытаться уменьшить потребление этого ресурса.
Это вполне нормальный ответ. Надо действительно видеть о чем речь, сайты очень сильно отличаться могут в плане создаваемой нагрузки.
То что он на wordpress и 50-100к - это какраз ни о чем.
100к в день это примерно 1 запрос в секунду. Ну пусть 10-20 днем в пике. Если речь вообще про именно запросы страниц самих. Что вовсе не так уж много на самом деле.
С точки зрения хостинга нет понятия "посетителей в сутки", есть запросы. Запросы различаются на легкие (статика), и на тяжелые (любая динамика, скрипты, базы и т.д.).
Один ваш посетитель может зайти и сделать 1 "тяжелый" запрос главной страницы и 50 запросов легких (фоток, стилей и т.д.).
А может каждый из этих 100к посетителей сделать штук 10 переходов по страницам, соотв. в запросах это уже не 100, а 500к.
Сколько там при этом будет "легких" запросов статики неизвестно, но скорей всего на порядок больше.
По-сути легкие можно особо не учитывать, они нагрузки не создают. В основном проблемы возникают когда сами страницы сайта не уже готовы (тот же кэш плагин в wp например), а генерируются при каждом запросе. И смотря на сколько много при этом действий происходит (php скрипты, mysql запросы) эти запросы могут стать действительно тяжелыми.
Все упирается в сам ваш сайт - все верно говорят, надо видеть создаваемую им нагрузку.
Может быть и 100к будут почти не заметны по нагрузке, а может сервер встать со 100% загруженными всеми ядрами уже при мизерном траффике на сайте.
Может вы просто не совсем разобрались или не включили opcache в 7ке тогда.
Или что там такого может xcache в php5, чего не может opcache в php7 или даже php5?
Лично с xcache не доводилось сталкиваться. Бегло погуглил...
https://serverfault.com/questions/768935/php-7-opcache-v-php-5-6-xcache
Opcache was already better than xcache since php 5.5
Возможно в каждой уже есть какие-то беты, поддерживающие. Изучать вопрос надо, но проще дождаться нормальных версий.
