Есть вопросы по скрипту. Основной - есть ли в нем практический смысл?)
>"мусорные" запросы, раздувающие лог и дающие лишнюю нагрузку на хостинге.
в access.log как сыпало, так и продолжит сыпать. Вместо 200 будет 502. Код 429 (rate limiting) подошел бы лучше. 502 выглядит как проблемы на сервере.
Что будет при нагрузке надо проверять. При распределенной атаке эта проверка, вполне возможно, будет работать в "минус".
Если бот подставит User-Agent известного поискового бота - он не будет заблокирован. Это уже сводит все усилия на "нет". Мелочь, но в примере в коде в массиве $options 47й элемент пустая строка '', то есть в любом случае is_bot() вернет true.
Ложные срабатывания, если, например, группа студентов за одним IP. Как-то некрасиво показывать "Вы заблокированы" настоящим пользователям. В худшем случае считаю, надо показывать капчу, при прохождении которой лимиты резко возрастают.
Множество обращений к FS, что плохо влияет на перфоманс, поэтому снова вопрос целесообразности. При каждом реквесте на PHP читать/писать в FS файлики с IPs... "Банить" по стране стОит уровнем выше, как и по IP в целом, чтобы данные тянулись с shared памяти. Nginx rate limiting (не пробовал), CloudFlare умеет - да, это уже не про shared, а на shared не вижу смысла обмазываться такими скриптами, т.к. все еще не понятны плюсы при наличии минусов.
Запускается консольная команда которая ресайзит изображения. На более-менее приличных объемах это занимает часы, просто потому что идет в 1 поток. А могло бы занимать десятки минут загружай оно 6-8 ядер сразу.
Для консольной команды не составит труда создать столько форков, сколько нужно.
Без кэша с режимом production страница может грузится несколько секунд, стоит ли говорить про режим developer бз кэшей и с логами. Без php7 и opcache m2, можно сказать, неюзабельна
Не думаю, что многопоточность смогла бы повлиять на холодный старт magento. А, сложность кода возросла бы однозначно.
С первого взгляда, кажется, что многопоточность была бы уместна для graphQL: собираем комментарии, пользователей, лайки из разных БД не последовательно друг за другом, а параллельно. Но, тут вопрос, сможем ли мы получить лайки не зная id комментариев.
Как мне кажется, в 95% случаев где хочется многопоточности — можно использовать очереди. В остальных 5% — использовать другой язык.
Есть вопросы по скрипту. Основной - есть ли в нем практический смысл?)
>"мусорные" запросы, раздувающие лог и дающие лишнюю нагрузку на хостинге.
в access.log как сыпало, так и продолжит сыпать. Вместо 200 будет 502. Код 429 (rate limiting) подошел бы лучше. 502 выглядит как проблемы на сервере.
Что будет при нагрузке надо проверять. При распределенной атаке эта проверка, вполне возможно, будет работать в "минус".
Если бот подставит User-Agent известного поискового бота - он не будет заблокирован. Это уже сводит все усилия на "нет". Мелочь, но в примере в коде в массиве
$options47й элемент пустая строка'', то есть в любом случаеis_bot()вернет true.Ложные срабатывания, если, например, группа студентов за одним IP. Как-то некрасиво показывать "Вы заблокированы" настоящим пользователям. В худшем случае считаю, надо показывать капчу, при прохождении которой лимиты резко возрастают.
Множество обращений к FS, что плохо влияет на перфоманс, поэтому снова вопрос целесообразности. При каждом реквесте на PHP читать/писать в FS файлики с IPs... "Банить" по стране стОит уровнем выше, как и по IP в целом, чтобы данные тянулись с shared памяти. Nginx rate limiting (не пробовал), CloudFlare умеет - да, это уже не про shared, а на shared не вижу смысла обмазываться такими скриптами, т.к. все еще не понятны плюсы при наличии минусов.
Для консольной команды не составит труда создать столько форков, сколько нужно.
Не думаю, что многопоточность смогла бы повлиять на холодный старт magento. А, сложность кода возросла бы однозначно.
С первого взгляда, кажется, что многопоточность была бы уместна для graphQL: собираем комментарии, пользователей, лайки из разных БД не последовательно друг за другом, а параллельно. Но, тут вопрос, сможем ли мы получить лайки не зная id комментариев.
Как мне кажется, в 95% случаев где хочется многопоточности — можно использовать очереди. В остальных 5% — использовать другой язык.