При обновление js скрипта в git все меняется на сервере, но на сайт для пользователей отдается через рандомное время. Куда копать?

Question

[Iceforest]

на сайт для пользователей измененный скрипт отдается через рандомное время, бывает обновиться через 5 минут, в бол-ве случаях через часов 5-8.
Кэширование пробовали полностью отключать, сейчас поставили 30 сек, но проблема остается. мы уже не знаем куда копать, и на что грешить.
в браузере:
Cache-Control: max-age=30, public
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/x-javascript
Date: Thu, 27 Feb 2020 07:13:24 GMT
ETag: W/"5e538d92-8105"
Expires: Thu, 27 Feb 2020 07:13:54 GMT
Last-Modified: Mon, 24 Feb 2020 08:47:14 GMT
Server: nginx/1.12.2
Transfer-Encoding: chunked

сейчас nginx конфиг такой:

location ~* \.js$ {
       expires 30;
       add_header Cache-Control public;

проблему судя по всему обнаружили, по крайней мере, понятно как сразу отдать клиенту нужный js. Если мы заходим в папку через winscp и нажимаем обновить, то сразу все происходит. Как это можно автоматизировать?

Answer 1

[nokimaro]

Копать стоит в инвалидацию кеша путём смены url до .js для каждой новой версии файла.
Когда вместо script.js у вас будет некое версионирование
Например script.vXXX.js либо используют хеш от содержимого script.MD5(от содержимого скрипта).js = script.adadadasdadadsd.js и соотв-но при модификации скрипта будет меняться и url

Этот подход лучше всех остальных, так как позволяет реализовать инвалидацию кеша css/js при изменении файла, а так же эффекивно кешировать на клиенте (можно будет сразу на год)

За примером далеко ходить не надо, откройте исходный код этой страницы и увидите как пример использования этого подхода
https://qna.habr.com/frontend.5e15b533-1a38-4c3c-b...
https://qna.habr.com/frontend.5e15b533-1a38-4c3c-b...

Comments

[Iceforest]

а есть какой-нибудь мануал по хэшу от содержимого? наши веб разработчики не хотят версинифицировать, а вот хэш я так понимаю можно в серверном конфиге nginx прописать ?

[nokimaro]

Iceforest, разработчикам ничего и не надо версионировать вручную. Такие вещи автоматизируются.
- либо на этапе сборки проекта и выкатке новой версии
- либо на лету, когда хеш вычисляется скриптом путём считывания того что лежит на сервере. Файл изменился - изменился и хеш и url.

Всё зависит уже от ваших технических процессов.

[Iceforest]

nokimaro, а есть пример такого скрипта с хэшом?

[nokimaro]

Iceforest, есть куча статей в интернете с которой могут ознакомиться ваши разработчики чтобы выбрать наиболее подходящий вариант решения задачи

Например тут расписаны все практики и нюансы https://jakearchibald.com/2016/caching-best-practices/
то что я предложил это "Pattern 1: Immutable content + long max-age"

[nokimaro]

не заметил что речь в том числе про 1С-БИТРИКС
Где нужный функионал есть из коробки

Дайте разработчикам почитать про
https://dev.1c-bitrix.ru/learning/course/index.php...

[Iceforest]

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

[Iceforest]

nokimaro, проблему судя по всему обнаружили, по крайней мере, понятно как сразу отдать клиенту нужный js. Если мы заходим в папку через winscp и нажимаем обновить, то сразу все происходит. Как это можно исправить автоматизированно?

Answer 2

[Михаил]

копайте в изучение битрикса. Если пользуетесь гитом для публичной разработки, значит разработку на битриксе знаете слабовато, могу предположить, что костылей в вашем коде больше чем кастомизации.
включите объединение скрипта в битриксе, он будет выдавать ссылку с хэшем, каждое изменение - это новый скрипт для браузера, который будет кэшироваться по новому в том числе и на стороне сервера(но новый вариант выдается начиная со 2-го запроса, т.к. при первом запросе после изменений, отдается сначала ранее закэшированный вариант, а затем кэшируется новый), к тому же это уменьшит объем передаваемых данных.

Comments

[Iceforest]

объединение говорят пробовали и это ломает сами скрипты.

[Михаил]

это последствия костылей, о которых написано в начале комментария

[Iceforest]

Михаил, там весь сайт из костылей=)

[Михаил]

а это уже последствия разработок на гите. Из опыта могу сказать, что те, кто разрабатывает на битриксе через гит, не используют структуру и функционал битры даже на 10%, что приводит к дальнейшим проблемам.
В вашем случае возможно поможет полная очистка кэша через админку битрикса, каждый раз когда будут какие-то обновления.

[Iceforest]

Михаил, я правильно, понимаю, что нет смысла копать в apache и nginx, проблема именно в битриксе? как бы мы не строили конфиг nginx и его кэш, проблема в кэше битрикса?

[Михаил]

если полная очистка кэша через админку решит вашу проблему, то да, это исходит из битрикса, если же это не решит, то копаем не только в nginx, но и конфиг php-fpm, хотя это мало вероятно

[Iceforest]

Михаил, проблему судя по всему обнаружили, по крайней мере, понятно как сразу отдать клиенту нужный js. Если мы заходим в папку через winscp и нажимаем обновить, то сразу все происходит. Как это можно исправить автоматизированно?

[Михаил]

Iceforest, скорее всего проблема в настройках сжатия и кэширования в nginx конфиге, рекомендую покопаться на форуме битрикса, чтобы найти подходящие конфиги.