Я обслуживаю весь контент через apache с Content-Encoding: zip, но он сжимается на лету. Большая часть моего контента - это статические файлы на диске. Я хочу заранее сжать файлы, а не сжимать их каждый раз, когда они запрашиваются.
Я считаю, что это то, что mod_gzip сделал в Apache 1.x автоматически, просто имея рядом с ним файл с расширением .gz. С mod_deflate это уже не так.
Я запускаю веб-сервер на виртуальной машине Xen, поэтому я хотел бы сохранить как можно больше ЦП для других виртуальных машин. Также мне удалось удвоить частоту запросов, измеренную с помощью httperf для предварительно сжатого файла размером 55 КБ, по сравнению со сжатием на лету.
См. stackoverflow.com/questions/9076752/…

В любом случае эта функция была неуместна в mod_gzip. В Apache 2.x вы делаете это с помощью переговоров по содержанию. В частности, вам нужно включить MultiViews с помощью Директива Options, и вам нужно указать типы кодирования с помощью Директива AddEncoding.
mod_gzip также сжимает содержимое на лету. Вы можете предварительно сжать файлы, фактически войдя на свой сервер и сделав это из оболочки.
cd /var/www/.../data/
for file in *; do
gzip -c $file > $file.gz;
done;
Это приведет к удалению исходных файлов, а это значит, что клиенты, у которых нет Aceept-Encoding: gzip, не будут обслуживаться.
Пока вы редактируете, почему бы не добавить -9 и получить максимально возможное сжатие. Мои 1500 файлов сжимаются за 38 секунд, поэтому стоит сэкономить каждый возможный байт в полосе пропускания и времени загрузки. :) (Также хотелось бы отредактировать опечатку в предыдущем комментарии. Ух)
Не в соответствии со страницей руководства на моем Mac, там указано -6 по умолчанию.
Чтобы ответить на мой собственный вопрос с помощью действительно простой строки, которую мне не хватало в моей конфигурации:
Options FollowSymLinks MultiViews
Мне не хватало опции MultiViews. Он присутствует в конфигурации веб-сервера Ubuntu по умолчанию, так что не уподобляйтесь мне и бросайте его.
Также я написал быстрое задание Rake для сжатия всех файлов.
namespace :static do
desc "Gzip compress the static content so Apache doesn't need to do it on-the-fly."
task :compress do
puts "Gzipping js, html and css files."
Dir.glob("#{RAILS_ROOT}/public/**/*.{js,html,css}") do |file|
system "gzip -c -9 #{file} > #{file}.gz"
end
end
end
У меня есть Apache 2, созданный из исходного кода, и я обнаружил, что мне нужно изменить следующее в моем файле httpd.conf:
Добавить MultiView в параметры:
Options Indexes FollowSymLinks MultiViews
Раскомментируйте AddEncoding:
AddEncoding x-compress .Z AddEncoding x-gzip .gz .tgz
Комментарий AddType:
#AddType application/x-compress .Z #AddType application/x-gzip .gz .tgz
Я боюсь, что MultiView не будет работать должным образом: в документе говорится, что Multiviews работает, «если сервер получает запрос для / some / dir / foo, если в / some / dir включены MultiViews, а / some / dir / foo не существует. .. ", другими словами: если у вас есть файлы foo.js и foo.js.gz в одном каталоге, простая активация MultiViews не приведет к отправке файла .gz, даже если заголовок AcceptEncoding gzip передается через браузер (вы можете проверить это поведение, временно отключив mod_deflate и отслеживая ответ, например, с помощью HTTPFox).
Я не уверен, есть ли способ обойти это с помощью MultiViews (возможно, вы можете переименовать исходный файл, а затем добавить специальную директиву AddEncoding), но я считаю, что вы можете создать правило mod_rewrite, чтобы справиться с этим.
Я уверен, что в то время это сработало, и я уверен, что не удалял исходные файлы. Вполне вероятно, что каким-то образом был задействован mod_rewrite. У меня, вероятно, было правило «обслуживать это статически, если файл существует». Возможно, я изменил его, включив расширение .gz, но у меня больше нет доступа к этой системе для проверки.
Если в вашем примере вы запрашиваете только foo, а не foo.js, он будет работать. Если клиент принимает gzip, он получит foo.js.gz, иначе он получит foo.js.
см. stackoverflow.com/questions/9076752/…
У меня много больших файлов .json. Большинство читателей находятся в такой ситуации. В ответах на предварительный просмотр не говорилось о возвращаемом «Content-type».
Я хочу, чтобы следующий запрос прозрачно возвращал предварительно сжатый файл с «Content-Type: application / json», используйте Multiview с ForceType
http://www.domain.com/(...)/bigfile.json
-> Content-Encoding:gzip, Content-Type: Content-Encoding:gzip
1) файлы необходимо переименовать: "file.ext.ext"
2) Multiview отлично работает с ForceType
В файловой системе:
// Note there is no bigfile.json
(...)/bigfile.json.gz
(...)/bigfile.json.json
В вашей конфигурации apache:
<Directory (...)>
AddEncoding gzip .gz
Options +Multiviews
<Files *.json.gz>
ForceType application/json
</Files>
</Directory>
Коротко и просто :)
Можно обслуживать предварительно сжатые файлы с помощью mod_negotiation, хотя это немного привередливо. Основная трудность заключается в том, что согласовываются только запросы на файлы, которые не существуют. Таким образом, если существуют и foo.js, и foo.js.gz, ответы для /foo.js всегда будут несжатыми (хотя ответы для /foo будут работать правильно).
Самым простым решением, которое я нашел (от Франсуа Мариера), является переименование несжатых файлов с двойным расширением файла, поэтому foo.js развернут как foo.js.js, поэтому запросы на /foo.js согласовываются между foo.js.js (без кодировки) и foo.js.gz (кодировка gzip).
Я комбинирую этот трюк со следующей конфигурацией:
Options +MultiViews
RemoveType .gz
AddEncoding gzip .gz
# Send .tar.gz without Content-Encoding: gzip
<FilesMatch ".+\.tar\.gz$">
RemoveEncoding .gz
# Note: Can use application/x-gzip for backwards-compatibility
AddType application/gzip .gz
</FilesMatch>
I написал сообщение, в котором подробно обсуждаются причины этой конфигурации и некоторые альтернативы.
Кажется, это больше не работает. С Apache 2.4.25 я всегда получаю несжатые результаты, вероятно, потому, что MultiViews срабатывает только в том случае, если файл не существует с указанным именем. Док говорит об этом. Жалость!
Хороший улов @MvG, ты абсолютно прав! Я обновил ответ с помощью обходного пути, хотя он не идеален, поскольку требует переименования несжатого файла и небольшого обмана конфигурации. Надеюсь, это поможет!
@Kevinoid: Это именно то решение, которое я придумал сам, после того, как проспал на нем. Отлично!
Я не думаю, что вы собираетесь сэкономить много; с современными веб-серверами стоимость сжатия содержимого на лету незначительна.