Хотя фиг знает. Обращения с этого IP на SW JProjects

А get это что за страница?

Это с того IP, + 845 строчек заблокированных IP за сутки из-за превышения нагрузки по тарифу - 7%

Это пункт меню sw jprojects для скачивания расширений

Это с того IP, + 845 строчек заблокированных IP за сутки из-за превышения нагрузки по тарифу - 7%

Но это же локальный адрес

Вот он 10.0.12.15

Ты сказал у тебя адрес рефер 10.0.12.15

Ты же сказал вот 10.0.12.15

это локальный адрес. 10.0.0.0/8 зарезервировано для локального использования

это локальный адрес. 10.0.0.0/8 зарезервировано для локального использования

И-и-и?..

Меня грузит мой же хостер?

У них есть такая тонкость - хоп и сервер недоступен

жесть.... хорошо, когда свой сервер и риш

Кто-то сканит xml

Кто-то сканит xml

xml у меня вида https://web-tolk.ru/component/swjprojects/jupdate.html?element=pkg_lib_wt_amocrm

Но там все ссылки на get

сканят весь сайт, получается?

Теперь я знаю что мой тариф рассчитан на 30к+ посещений в сутки )

Нашёл проблему свою с нагрузкой. Это мой собственный косяк с sw jprojects. Я добавлял в xml-манифест сервера обновлений контрольные суммы sha128, 256 и 512. И в функцию я подставлял download url, который является не локальным путём от корня, а именно урлом. Получается для построения xml-манифеста - запрашивается даннные по проекту - запрашивается список версий (для создания download url) - на каждую версию происходит 3 запроса для создания хеша. Если в расширении - 1 версия - 3 запроса - 2 версии - 6 запросов и т.д. Чем больше версий тем больше нагрузка. Подсунул в функции локальный путь и стало всё нормально.

Там есть еще одна проблема - когда становится слишком много версий - расчет контрольных сумм становится очень затратным. Ответ сервера замедляется очень сильно. Мы на совмарт с этим столкнулись до такой степени что ответ был очень долгий. Нужно переделывать либо на кеш либо другим методом. И еще - из всех расчетов контрольных сумм там нужна только одна

Там есть еще одна проблема - когда становится слишком много версий - расчет контрольных сумм становится очень затратным. Ответ сервера замедляется очень сильно. Мы на совмарт с этим столкнулись до такой степени что ответ был очень долгий. Нужно переделывать либо на кеш либо другим методом. И еще - из всех расчетов контрольных сумм там нужна только одна

Кэш я включил. По ходу нужно делать плагин на крон, который раз в сутки/период из настроек будет обновлять кэш обновлений

То есть не важно какая?

Кэш я включил. По ходу нужно делать плагин на крон, который раз в сутки/период из настроек будет обновлять кэш обновлений

Я предложил такое решение - контрольную сумму вписывать прямо в имя файла.

У тебя есть кеш? В таком случае не должно было быть столько обращений Обращение должно было быть одно толко

Инсталлер джумлы так понимает?

Столько обращений - мой косяк. Я в функцию хеша отдавал url вида https://web-tolk.ru/get.html?element=wt_jshopping_b24_pro И поэтому при расчете хеша были как-будто внешние обращения.

Нет не понимает. Это для формирования xml чтобы обойтись без кеша и так далее

При создании версии именовать файл? Там же в алгоритм включено само имя файла?

Я не про то. Ты хочешь в имя файла включать сам хэш, что приведет к изменению хэша

Я не помню, имя файла влияет ли на хэш

Нашёл проблему свою с нагрузкой. Это мой собственный косяк с sw jprojects. Я добавлял в xml-манифест сервера обновлений контрольные суммы sha128, 256 и 512. И в функцию я подставлял download url, который является не локальным путём от корня, а именно урлом. Получается для построения xml-манифеста - запрашивается даннные по проекту - запрашивается список версий (для создания download url) - на каждую версию происходит 3 запроса для создания хеша. Если в расширении - 1 версия - 3 запроса - 2 версии - 6 запросов и т.д. Чем больше версий тем больше нагрузка. Подсунул в функции локальный путь и стало всё нормально.

Там есть еще одна проблема - когда становится слишком много версий - расчет контрольных сумм становится очень затратным. Ответ сервера замедляется очень сильно. Мы на совмарт с этим столкнулись до такой степени что ответ был очень долгий. Нужно переделывать либо на кеш либо другим методом. И еще - из всех расчетов контрольных сумм там нужна только одна

там кеш рассчитывался по ключу, у нас ключа так такого в get параметрах нет уже