Оптимизация HTTP-сервера через версионность ресурсов. Особенности реализации

Ну, посыл правильный. Кеширование это хорошо. Правда я позволю себе некоторую критику.
1. Для статики есть nginx => реализовывать отправку файлов скриптом занятие в общем случае неблагодарное (особенно учитывая то что python-фреймворки нормально поддерживают работу со статикой) => статья про GAE и лучше её перенести в профильный блог чтобы не смущать людей.
2. Google App Engine предоставляет средства работы со статикой «искаробки»
handlers:
- url: /favicon.ico
static_files: engine/static/favicon.ico
upload: engine/static/favicon.ico
expiration: "31d"

- url: /static
static_dir: engine/static
expiration: "7d"
2.1 Насколько мне помнится есть две версии формирования адреса:
localhost/static/style.v200.css
и
localhost/static/style.css?v200
3. Ну и если пошла такая пьянка, то лучше использовать ETag. Он позволяет следить за версией файла.
4. Если добавить подсветку и убрать
time.sleep(1) # todo: just making resource loading process noticeable
будет совсем замечательно (наблюдения за firebag'ом вполне достаточно чтобы прочувствовать)
PS кстати код будет ругаться на .svn. мелочь, а неприятно

2. Действительно, GAE предоставляет средства. Но остаётся ещё задача автоматического формирования урлов. Плюс, при изменении ресурсов придётся постоянно и очень строго придерживаться правил и переименовывать файлы — всё это вручную. Если первая проблема может решаться запуском скриптов до и после деплоя, то как быть со вторым не представляю совсем. Полноценная работа без всего этого невозможна, а полагаться только на идеальную самодисциплину в этом вопросе я бы никому не пожелал.

3. ETag не лучше — или ETag, или Last-Modified. Можно разговаривать на языке «версий», а можно на языке «изменилось-не-изменилось». Последнее, вместе с Expires и Cache-Control, даже концептуальнее выглядит.

>В качестве версии файла можно использовать как версию из VCS,

в GAE есть понятие версии приложения (в environ).

>App Engine обрабатывает файлы означенные как static сама (не очень эффективно)

чем неоптимально? "/static/css/styles.css?v=12333" и указание времени жизни в конфиге приложения дает тот же эффект.

В django я использую django-mediagenerator. Кроме того, что он обеспечивает версионность ресурсов, есть возможность сшивать js/css-статику в один( ну или сколько нужно) файлов и сжимать этот файл, что также уменьшает количество запросов и нагрузку на сервер. А для деплоя используется fabric, потому забыть «запустить скриптик после деплоя» становится проблематично.

Оптимизация статики в App Engine это 5 строк в app.yaml:

default_expiration: "365d"
handlers:
- url: /(.*)/(.*)/(.*\.(css|js|gif|jpg|png|zip))
static_files: files/\2/\3
upload: files/(.*/.*\.(css|js|gif|jpg|png|zip))
Обрабатывает ссылки вида /v12345-anything/static/style.css

Преимущества:

• Система статики App Engine более распределённая.
• Ресурсы отдаются с адекватными заголовками и нормально кэшируются прокси-серверами: серверу не придётся даже отвечать на все запросы.
• Не стартуют лишние инстансы, не потребляются лишние ресурсы приложения.

Совет по реализации: если Вы загружаете файлы вместе с приложением, то нет смысла класть их ещё и в memcache, и, тем более, в datastore. Скорость чтения из memcache и из локальных файлов почти одинаковая, я когда-то писал об этом.

Совет по применению: если Ваше приложение вынуждено генерировать и отсылать пользователям файлы, то стоит внимательно присмотреться к Files API. При отдаче файлов через свой скрипт необходимо укладываться в 30 сек, что может быть проблематично при узком канале у пользователя. А при отдаче через бэкенды их может понадобиться очень много при приличной посещаемости.