это графики "с передовой" на фронтэнде два nginx'а - один по-легче для http и второй по-тяжелей для https собран.
т.е. рисуются суммарно запросы на весь сервер, а не на конктерный аккаунт или сайт.
глубже вести такую статистику смысла особо нет. опять же чтоб сервер меньше занимался ерундой, а больше тем чем надо - обслуживал сайты клиентов.
и да, это статика + не_статика все вместе.
в первом сообщении ведь говорится про http-запросы. я так понял 75 - это тоже без различия статика или скрипты.
дальше от nginx'ов часть запросов идут к клиентским апачам или php-fpm'ам (у каждого собственный). конечно "скриптовых" запросов получается сильно меньше. и потому нагрузка на сервер от сайта сильно зависит от самого сайта. если там в основном статика/фотки, то nginx легко и 1000/сек отдаст без намека на повышенную нагрузку.
но понятно что совсем другое дело когда например боты долбят wp-login.php подбирая пароли. (на этот случай тоже есть защита).
потому и не сильно понятен смысл вообще в каком-либо лимите http-запросов. для статики 75 вообще ни о чем, но по тяжелым скриптам такие удары могут нагрузить процессор прилично. толку с этого лимита никакого, только клиентам лишняя потенциальная проблема.
и дальше, еще глубже, от скриптов запросы к mysql (тоже у каждого своя тут). на один запрос может быть целая пачка запросов к mysql. т.е. и 1 запрос может нормально так нагрузку создать через mysql.
хотя у многих хостеров тут тоже есть лимиты свои - столько-то запросов к базе в час например.
it charts "from the front" on the front-end two nginx - one is easier for http and the second is harder to https assembled.
those. drawn in total requests for the entire server, not on konkterny account or website.
deeper sense to conduct such statistics especially not. again, that the server is less engaged in crap, but more so than necessary - to serve the customer sites.
and yes, it is static + ne_statika together.
in the first message they say about the http-queries. I understand 75 - is also without distinction static or scripts.
further from nginx'ov of the requests go to the client Apache or php-fpm'am (each his own). Of course, "scripting" of requests get much less. and because the load on the server from the site is heavily dependent on the site. if there basically static / photos, then nginx easily and 1000 / s give no hint of an increased load.
but it is clear that a different matter when such bots hammering wp-login.php choosing passwords. (In this case, too, there is a protection).
and therefore not very clear sense at all in any limit of http-requests. statics 75 about anything, but on heavy scripts such attacks can load the processor properly. confused with any of the limit, only the customers extra potential problem.
and further, even deeper, from the queries to the script mysql (also at everyone here). one query may be an entire query packet to mysql. those. and 1 request can properly so the burden to establish by mysql.
although many hosts here too there are limits their - so many database queries per hour for example.
нет. это реальный траффик был.
просто сайт не маленького магазина с тучей клиентов. и в дни каких-то акций бывают наплывы посетителей в несколько миллионов запросов в сутки (сколько это в посетителях не знаю). точно не атаки никакие.
и да, это на shared хостинге :)
люди не ведутся на эти байки про то что если у вас больше 1000чел/сутки, то обязательно нужен vps, выделенный сервер... свой датацентр и т.д.
просто действительно существует много shared'ов из прошлого десятилетия с огромной кучей всевозможных лимитов. и люди мучаются, страдают... уходят на vps, а там еще хуже, медленней, сложней и за больше денег 🙅
no. it was a real traffic.
the site is not just a small shop with a cloud customers. and in the days of some shares are the influx of visitors in a few million requests per day (as it is in the visitors do not know). definitely not attack any.
and yes, it is on shared hosting :)
people are not kept in these stories about the fact that if you have more 1000chel / day, make sure you need a vps, dedicated server ... your data center, etc.
just really, there are many shared'ov of the last decade with a huge bunch of various limits. and people suffer, suffer ... go to vps, but there is even worse, slower, more difficult and more money 🙅
у каждого свое "много" и "мало".
но вот для примера допустим:
1) 300+ сайтов, самых обычных без особого траффика. (в среднем 10мбит/сек суточный)
2) пара десятков сайтов с более-менее траффиком. (около 100мбит/с среднее за сутки)
это все "average" статистика. можно выставить "max" и тогда со всеми всплесками будут в 2-3 раза выше значения скорей всего.
и этот же сервер за год график:
т.е. бывали у клиентов всплески под 1000 запросов в секунду... и никто никого не ограничивал ни в чем.
для небольшого сайта тех 75 запросов/сек должно быть вполне достаточно. но сильно зависит от самого сайта.
однако в целом, если у хостера на каждый ваш чих есть какой-то лимит, если сервер вместо того чтоб делать основную свою задачу, постоянно все считает и подсчитывает чтоб если вдруг что сразу обломать в чем-то, то стоит задуматься...
кто знает когда и на каком лимите может споткнуться ваш сайт.
everyone has his "many" and "few".
but let's say for example:
1) 300+ sites, the most common without much traffic. (An average of 10 Mbit / s per diem)
2) a couple dozen sites with more or less traffic. (About 100 Mbit / s average per day)
it's all "average" statistics. you can set the "max" and then with all the spikes are 2-3 times higher than the most likely.
and the same server for the year schedule:
those. there were bursts of clients under the 1000 requests per second ... and no one is restricted in any way.
for a small site of the 75 requests / sec should be enough. but much depends on the site.
but in general, if you host your every sneeze there is some limit, if the server instead of doing its main task, constantly all counts and counts so if suddenly break off at once in something, you should think ...
who knows when and at what limit could trip over your site.
и будут дальше продолжать из сша и европ всяких. это частично поможет конечно, но не решение.
конечно надо смотреть конкретный случай, но по своему опыту, количество адресов с которых это делают обычно относительно небольшое.
смотрим логи, находим закономерности. например какой-то пик был в такое-то время и там много разных ip, но у всех один в один user agent - скриптом собираем все адреса до кучи и баним.
дальше мониторим...
или общей может быть asn - тоже, по всем логам скрипт пусть пройдется, посмотрит asn всех ip, которые только заходили и адреса из провинившейся asn в баню.
вот одна из забаненых у меня на одном из проблемных сайтов:
https://bgp.he.net/AS26484#_prefixes
где тут китай с бразилиями.
куча запросов шло с сша какраз.
и естественно это все не ддос, а так, баловство :)
часто просто очень тупые боты-парсеры-сканеры с десятками-сотнями запросов в секунду в сочетании с далеко не хорошо сделанным сайтом (вместо статики или хотяб кэша, каждый раз туча запросов к базе, куча скриптов выполняется и т.п.).
правильно сделанные сайты вообще подобный "ддос" не замечают, и тысячу запросов в секунду принять не проблема.
and will continue to keep the US and Europe all. This partly helps of course, but not a solution.
Of course it is necessary to watch a specific case, but in my experience, the number of addresses that do are usually relatively small.
We watch logs, find regularities. for example some peak was at a certain time and there are many different ip, but all one in a user agent - script gather all the addresses to the heap and banim.
Monitors ... more
or total can be asn - too, for all logs script let pass, look asn all the ip, which only goes and addresses of the offending asn in the bath.
here is one of my banned in one of the most problematic sites:
where is China and Brazil.
Requests came with a bunch of US kakraz.
and of course it's not DDoS, and so self-indulgence :)
often just a very stupid boats parsers scanners with tens to hundreds of requests per second, coupled with less than a well-made website (instead of static or cache At least, every time a cloud database queries, scripts bunch of runs, etc.).
the right to make the site even such a "DDoS" do not notice, and a thousand requests per second take is not an issue.
главное папки хранить в другой стране, не в той же где и файлы.
не только же в циклах записи дело.
не подходят т.к. скорей всего указанные 550мб/сек будут гораздо более "До", чем в серверных.
например скорость работы мелкими блоками - одно дело читать с них крупные видеоролики например и совсем другое раздавать сайты из тысяч мелких файлов.
или например поведение диска после исчерпания чистых ячеек. допустим забьете диск под крышку и будете пытаться перезаписать что-то на нем - тогда и поймете, что до 550мб/сек там как до луны... а в то же время у действительно серверных физически доступно ячеек раза в 2 больше, чем объявляется. и когда места свободного уже вроде как нет, а запросы на запись все идут, обычный диск будет сперва очищать, потом записывать и пусть весь мир подождет... а у правильного всегда будет приличный запас уже очищенных.
графически выглядит это примерно так:
т.е. после полной перезаписи всего объема диска спад есть у всех флэш-дисков, но то на сколько сильный этот спад и определяет серверный он или домашний. дома ведь это терпимо, а сервер работает без остановки круглосуточно и там расчет именно на минимальное падение скорости в долгосрочной работе.
но кто в такие мелочи вникает? :)
в тестах (которые проходят обычно в начальной части графика) налюбуются на скоростя и ставят потом домашние диски в сервера, мол зачем платить больше если результат не хуже.
конечно сильно зависит от конкретного использования. в большинстве случаев будут работать нормально любые диски.
просто никто ж не будет знать как оно может быть иначе. главное вера, что я поставил ssd и теперь порядок. если что-то и подтормаживает, то лучше уже просто быть не может :)
