Блог

Внешняя сторона должна использовать динамически сгенерированные изображения, которые используются на нашем сайте. Для этого я создал функцию, которая обслуживает изображение через URL. Например. http://test.com/image /$code/$width/$height. Итак, он находит изображение с кодом $code, изменяет его размер до $width и $height, а затем обслуживает само изображение (не URL). Теперь внешняя сторона может использовать <img src="http://test.com/image/$code/$width/$height" />

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

Я могу сделать это немного более эффективным, проверив, существует ли изображение, а затем вернуть его, не создавая его сначала, конечно. Но я также рассматривал перенаправление.

Итак, по сути, мой вопрос заключается в том, эффективнее ли генерировать / загружать изображение, а затем обслуживать его, или выполнять перенаправление 301 на фактическое изображение. Я знаю, что это также имеет некоторые недостатки, в первую очередь необходимость двух запросов на изображение, но мне интересно, как это сравнивается с передачей всего изображения через php и процессом генерации изображения.

Обновить:

Может быть, мне следует немного прояснить ситуацию.

1. Меня интересует загрузка сервера, а не UX. Скорее всего, последнее хуже из-за перенаправления, поскольку оно выполняет двойное количество запросов к серверу).
2. Разница в двух ситуациях заключается в следующем:

Ситуация с генерацией изображения:

 - Check if image exists. If not, generate.
- Then do this

$path       = BASE_PATH."/".$image->Filename;
$mimetype   = image_type_to_mime_type(exif_imagetype($path));

header("Content-type: ".$mimetype);
echo readfile($path);
die;
  

Ситуация с перенаправлением изображения:

 - Check if image exists. If not, generate.
- Then do this

$location   = BASE_HREF."/".$image->Filename;
$mimetype   = image_type_to_mime_type(exif_imagetype($path));
header('Location: '.$location,true,301); //or maybe a 303 (other)
die;
  

Очевидно, что во второй ситуации php должен делать меньше, а apache больше (обслуживать 2 файла вместо одного). В первой ситуации apache должен делать больше, а php меньше. Итак, вопрос в том, является ли дополнительная работа, которую должен выполнять php, больше или меньше, чем дополнительная работа, которую должен выполнять Apache?

Я не знаю, но я чувствую, что если вы уже используете PHP-скрипт, то дополнительные затраты на написание некоторых заголовков и вызов readfile() будут тривиальными.

Что еще более важно, будет ли файл использоваться более одного раза одним и тем же пользователем? Если это так, вы могли бы значительно выиграть, сделав файл кэшируемым. Если вы перенаправляете на статический файл, веб-сервер автоматически позаботится о кэшировании. Если вы обслуживаете файл через PHP, вам придется кэшировать его самостоятельно.

Для этого вам необходимо:

• Вычислите дату последнего изменения или ETag (уникальный идентификатор).
• Проверьте заголовки запросов If-Modified-Since: If-None-Match: на наличие заголовка or.
• Сравните значения заголовка с вычисленной датой или ETag.
• Если ваш файл более новый или не соответствует ETag (или заголовки запроса не существуют), отправьте 200 ответ, включающий файл.
• В противном случае отправьте 304 ответ без файла.
• В обоих случаях отправьте текущий Last-Modified: ETag заголовок or и, возможно, разумный Expires: заголовок.

Во-первых, очень важно, чтобы вы проверили, существует ли изображение, прежде чем создавать объект. Это не поможет «немного». Создание файла .jpg намного дороже, чем проверка имени файла.

Остальная часть вашего вопроса мне не совсем понятна, но я все равно попытаюсь ответить.

301 перенаправление обычно не используется для того, о чем вы говорите. Они должны сообщать поисковому пауку, что страница переместилась навсегда. Функционально это работает ничем не отличается от обычного перенаправления.

Двигаясь дальше, я еще больше запутался. «и затем обслуживает само изображение (не URL)»

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

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