Супер быстрый getimagesize в php

 function ranger($url){ $headers = array( "Range: bytes=0-32768" ); $curl = curl_init($url); curl_setopt($curl, CURLOPT_HTTPHEADER, $headers); curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1); $data = curl_exec($curl); curl_close($curl); return $data; } $start = microtime(true); $url = "http://img.ruphp.com/http/Debian-Turns-15-2.jpg"; $raw = ranger($url); $im = imagecreatefromstring($raw); $width = imagesx($im); $height = imagesy($im); $stop = round(microtime(true) - $start, 5); echo $width." x ".$height." ({$stop}s)"; 

контрольная работа…

640 x 480 (0,20859s)

Загрузка 32kb данных работала для меня.

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

Он доступен на GitHub здесь: https://github.com/tommoor/fastimage

Пример использования:

 $image = new FastImage($uri); list($width, $height) = $image->getSize(); echo "dimensions: " . $width . "x" . $height; 

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

В целом, когда это сработало, самым быстрым, как правило, была функция getjpegsize которую Джеймс Релиа опубликовал на странице PHP для getimagesize , избивая функцию ranger предоставленную Dejan выше. http://php.net/manual/en/function.getimagesize.php#88793

 Image #1 (787KB JPG on external older server) getimagesize: 0.47042 to 0.47627 - 1700x2340 [SLOWEST] getjpegsize: 0.11988 to 0.14854 - 1700x2340 [FASTEST] ranger: 0.1917 to 0.22869 - 1700x2340 Image #2 (3MB PNG) getimagesize: 0.01436 to 0.01451 - 1508x1780 [FASTEST] getjpegsize: - failed ranger: - failed Image #3 (2.7MB JPG) getimagesize: 0.00855 to 0.04806 - 3264x2448 [FASTEST] getjpegsize: - failed ranger: 0.06222 to 0.06297 - 3264x2448 * [SLOWEST] Image #4 (1MB JPG) getimagesize: 0.00245 to 0.00261 - 2031x1434 getjpegsize: 0.00135 to 0.00142 - 2031x1434 [FASTEST] ranger: 0.0168 to 0.01702 - 2031x1434 [SLOWEST] Image #5 (316KB JPG) getimagesize: 0.00152 to 0.00162 - 1280x720 getjpegsize: 0.00092 to 0.00106 - 1280x720 [FASTEST] ranger: 0.00651 to 0.00674 - 1280x720 [SLOWEST] 

• ranger не удалось захватить 32768 байт на Image # 3, поэтому я увеличил его до 65536, и он работал, чтобы захватить размер успешно.

Однако есть проблемы, поскольку как ranger и getjpegsize ограничены способами, которые делают его недостаточно стабильным для использования. Оба отказались при работе с большим JPG-изображением вокруг 3 МБ, но ranger будет работать после изменения количества байтов, которое он захватывает. Кроме того, эти альтернативы имеют дело только с изображениями JPG, а это означает, что условное значение должно использоваться только для их использования в JPG и getimagesize для других форматов изображений.

Также обратите внимание, что первое изображение было на более старом сервере, на котором установлена ​​старая версия PHP 5.3.2, где 4 других изображения поступают с современного сервера (облачная cPanel с MultiPHP набрана на 5.4.45 для совместимости).

Стоит отметить, что сервер, основанный на облаках, намного лучше getimagesize с getimagesize который избил ranger , ведь для всех 4 тестов на сервере облаков ranger был самым медленным. Эти 4 также тянули изображения с того же сервера, что и код, но разные учетные записи.

Это заставляет меня задаться вопросом, улучшилось ли ядро ​​PHP в 5.4 или если в нем есть факторы версии Apache. Кроме того, возможно, это зависит от доступности с сервера и загрузки сервера. Давайте не будем забывать, как сети становятся все быстрее и быстрее с каждым годом, поэтому, возможно, проблема скорости становится менее опасной.

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

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