Аудиофайлы кэш-памяти Amazon S3

Question

Я создал новое музыкальное приложение, и я сохраняю все mp3-файлы на Amazon S3. Перед переходом на S3 я использовал их для хранения в самой файловой системе сервера. Он использовался для кэширования файлов, а последовательная перезагрузка файлов страниц не была загружена с сервера. Но после перехода на S3 каждый раз, когда я загружаю страницу, он загружает файлы с S3. Это не только замедляет работу приложения, но и каждый запрос на S3 - это деньги. Я нашел документацию по управлению кешем, и я пробовал их все, но не имел успеха. Возможно, я что-то пропустил. Любая помощь приветствуется. Благодарю.

Вот мой код для загрузки mp3-файлов на S3. Я использую CarrierWave с Rails.

CarrierWave.configure do |config| 
    config.fog_credentials = { 
     :provider    => 'AWS', 
     :aws_access_key_id  => MyAppConfig.config['aws']['aws_access_key'], 
     :aws_secret_access_key => MyAppConfig.config['aws']['aws_secret_key'], 
    } 
    config.fog_directory = MyAppConfig.config['aws']['aws_bucket_name'] 
    config.fog_public  = false 
    config.storage = :fog 
    config.fog_attributes = {'Cache-Control'=>'max-age=315576000'} 
end 

Answer 1

Если вы используете подписанные URL-адреса, которые, как вы говорите, находитесь в комментариях, и не повторно используете подписанные URL-адреса, тогда невозможно кэшировать эти запросы.

Веб-службы Amazon не могут переопределить внутреннюю систему кэширования вашего веб-браузера. Когда два URI уникальны, так как они имеют подписанные URL-адреса, ваш веб-браузер рассматривает их как два разных ресурса в Интернете.

Например, давайте возьмем:

http://www.example.com/song1.mp3 
http://www.example.com/song2.mp3 

Эти два дискретных URIs. Даже если song1.mp3 и song2.mp3 имели одинаковые заголовки HTTP-ответа Etag и 3, они все еще два разных ресурса.

То же самое справедливо, если мы просто изменить свои строки запроса:

http://www.example.com/song1.mp3?a=1&b=2&c=3 
http://www.example.com/song1.mp3?a=1&b=2&c=4 

Это еще два дискретных URIs. Они не будут ссылаться друг на друга для целей кэширования.Это принцип использования query strings to override caching.

Никаких проблем с HTTP-заголовками никогда не будет найдено поведение кэша, которое вы ищете.

Answer 2

Посмотрите на http://www.bucketexplorer.com/documentation/amazon-s3--how-to-set-cache-control-header-for-s3-object.html

Set Cache-Control для уже загруженного файла на S3 с помощью обновления метаданных:

1) Run Bucket Explorer, и войти в систему с учетными данными.

2) После перечисления всех ковшей выберите любой ковш S3.

3) Он перечислит все объекты выбранного ведра S3.

4) Выберите любой файл и щелкните правой кнопкой мыши по объектам и выберите «Обновить метаданные».

5) Добавить ключ и значение в атрибуты метаданных. Введите ключ: «Cache-Control» со ​​значением: «max-age = (время, за которое вы хотите получить доступ к объекту из кеша в секундах)»

6) Нажмите кнопку «Сохранить». Он обновит метаданные как Cache-Control для всех выбранных объектов S3.

Example to set max-age: For time limit of 15 days = 3600 * 24 * 15 = 1296000 sec. Set Key = “Cache-Control” value = “max-age=1296000” 

Примечание: Если объект является HTML-файл, установить ключ: «Cache-Control» и значение: макс возраста = (время, для которого вы хотите, чтобы ваш объект доступен из кэша в секундах), должен -ревалидат ", т.е. Ключ: значение «Cache-Control»: max-age = «2592000, необходимо повторно проверить» в течение 30 дней. «Must re-validate» строка должна быть добавлена ​​после времени в секунде как значение.

Answer 3

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

Если вы не установили заголовки управления кешем или хотите изменить их на основании того, кто делает запрос, вы можете установить их перед подписанием вашего URL-адреса с помощью: &response-cache-control=value или &response-expires=value.