Кирилл Фирсов

wiki.nginx.org/EmbeddedPerlModule
Как-то так (не тестировал, но должно вроде работать):
nginx.conf:

http {
    perl_require myhandler.pm;
    ...
    server {
        ...
        location ~* /original/\.(gif|jpg|png)$ {
            perl  myhandler::handler;
        }
    }
}

myhandler.pm:

package myhandler;
use nginx;
use Digest::MD5 qw(md5_hex);

sub handler {
  my $r = shift;
  if ($r->filename=~m|/original/(.*?)\.(jpg|gif|png)|) {
      my $id_md5=md5_hex($1);
      my $filename="/original/".substr($id_md5,31,1)."/".substr($id_md5,0,2)."/".substr($id_md5,2,2).".".$2;
      $r->sendfile($filename);
  }
  return OK;
}
 
1;
__END__

[могу ошибаться]imagecopyresized замени на imagecopyresampled[/могу ошибаться]

Для разработки разделить файлы по сущностям, например: один шаблон — один css файл (вы же используете наследование шаблонов, декораторы, слоты, блоки и т. п.? :) ) с максимальным использованием каскадности. Получим, что каждая страница будет запрашивать 1-N css файлов (у меня обычно 6-7 получается, 1 — общий шаблон для всех страниц, 1 — основной контент, 4-5 — меню и прочие блоки в сайдбарах). Можно пойти ещё дальше, разделяя css отдельных сущностей на css позиционирования/размеров, цвета и прочего декора, но имхо, излишне

Для продакшена для каждого реально встретившегося сочетания css генерируем свой один большой css (обычно получается штук 10, незначительно различающихся) и вызываем его для соответствующих страниц (можно ручками, можно средствами движка «на лету» и с кэшированием, можно утилитами) — в общем склейка. Дополнительно его можно обфусцировать и сжать.

Получаем, что для каждой страницы вызывается один css, в котором есть всё, что для неё нужно и нет ничего лишнего.

Плюсы по сравнению с крайностями (единый файл для всех страниц или 6-7 разных файлов для каждой страницы):
— простота разработки (субъективно, кому-то проще в одном файле лазить)
— один вызов css на странице, а значит только одно обращение к серверу (и то, если пользователь не случайный, кэшируется после первого обращения)
— минимальный размер css для каждой отдельно взятой страницы
— минимальное время парсинга файла браузером (а значит и время рендеринга страницы)
Минусы:
— сложность поддержки, если это дело прозрачно не автоматизировано
— для не случайных посетителей совокупный объём трафика будет большим, чем в обоих крайних случаях
— аналогично будет большим и кэш

Плюсы единого файла:
— минимальный совокупный объём трафика и кэша для не случайного посетителя
— один запрос на страницу, кэшируемый для всех страниц сайта
Минусы:
— сложность разработки (субъективно)
— избыточный объём трафика и кэша для случайных посетителей
— большее время парсинга для всех страниц (за редким исключение страниц, которым нужны все css правила проекта)

Плюсы кучи мелких файлов:
— простота разработки (субъективно)
— близкий к минимальному объём трафика и кэша для случайных посетителей, минимальный для не случайных
Минусы:
— много запросов к серверу
— незначительно большее время парсинга по сравнению со «склейкой»

Аналогично можно поступать и с JS

P.S. Предварительная оптимизация зло

P.P.S. Если используете условные «переходы» для IE, то можно или генерировать для него свой большой файл (тогда различий не будет в плюсах/минусах не будет), или вынести все используемые хаки в один файл и подключать его «статически» (тогда у пользователей IE будет два запроса на страницу, один из которых будет иметь плюсы и минусы «динамического» подключения, а второй не будет), или генерировать второй файл аналогично первому (обычно избыточно) — я предпочитаю второй вариант — «динамически» генерируемый общий CSS, и «статический» файл с хаками IE

P.P.S. Предварительная оптимизация зло.

Однозначно, для каждого видео делать запись в мемкэш — кол-во выборок из него особой роли не играет, а при втором варианте рано, или поздно столкнётесь с проблемой инвалидации и масштабирования.

В конфиг сфинкса после sql_query добавляем
sql_attr_uint = postid
в пхп
$sphinx = new SphinxClient();
$sphinx->SetServer('127.0.0.1', 9312);
$sphinx->SetFilter('postid', array(23) );

где 23 требуемое значение postid

irc://##programming@irc.freenode.net