Кешовано, PHP генерує мініатюри, повільно завантажуються

Питання Частина A ▉ (100 нагород, нагороджено)
Основне питання полягало в тому, як зробити цей сайт, завантажуватись швидше. Спочатку нам потрібно було прочитати ці водоспади. Дякуємо всім за ваші пропозиції щодо аналізу читання водоспаду. Наведені тут різні графіки водоспадів є основним вузьким місцем: мініатюри, створені PHP. Без протоколу завантаження jquery з CDN, рекомендоване Девідом, отримало мою винагороду, хоча загалом зробив на моєму сайті лише на 3% швидше, і не відповідав на головне вузьке місце сайту. Час для уточнення мого питання та ще одна щедрість:

Частина питання B (100 бантів, присвоєно)
Новий фокус був вирішений проблемою, що мала 6 зображень у jpg, які викликають більшу частину затримки завантаження. Ці 6 зображень є мініатюрами, створеними PHP, крихітними та лише 3 ~ 5 кб, але завантажуються відносно дуже повільно. Помітьте " час на перший байт " на різних графіках. Проблема залишилася невирішеною, але щедрість дісталася Джеймсу, який виправив помилку заголовка, яку підкреслив RedBot : "Якщо змінився, оскільки умовний запит повернув повний вміст без змін". .

Питання Частина C ▉ (моя остання сума: 250 балів)
На жаль, після виправлення навіть помилки заголовка REdbot.org, затримка, викликана зображеннями, створеними PHP, залишалася недоторканою. Про що думають ці крихітні крихітні ескізи 3 ~ 5 Кб? Вся ця інформація заголовка може відправити ракету на Місяць і назад. Будь-які пропозиції щодо цього вузького місця є дуже вдячними та розглядаються як можлива відповідь, оскільки я затримався на цій вузькій проблемі вже сім місяців. Заздалегідь дякую.

[Довідкова інформація на моєму сайті: CSS знаходиться вгорі. JS внизу (Jquery, інтерфейс JQuery, куплені меню awm / menu.js двигуни, двигун вкладки js, відео swfobject.js) Чорні лінії на другому зображенні показують, що ініціює, що потрібно завантажити. Розлючений робот - мій вихованець "ЗАМ". Він нешкідливий і часто щасливіший.]

Навантаження водоспад: Хронологічний | http://webpagetest.org

Паралельні домени згруповані | http://webpagetest.org

Сайт-Перфський водоспад | http://site-perf.com

Pingdom Tools водоспад | http://tools.pingdom.com

GTmetrix водоспад | http://gtmetrix.com

По-перше, для використання цих кількох доменів потрібно кілька пошукових запитів DNS. Вам буде краще поєднувати багато цих зображень у спрайт, а не розповсюджувати запити.

По-друге, коли я завантажую вашу сторінку, я бачу більшість блокувань (~ 1,25) на all.js. Я бачу, що починається з (старої версії) jQuery. Вам слід посилатись на це з CDN Google, щоб не тільки скоротити час завантаження , але й потенційно повністю уникнути HTTP-запиту .

Зокрема, на найбільш актуальні бібліотеки інтерфейсу jQuery та jQuery можна посилатись за цими URL-адресами (див. Цю публікацію, якщо вас цікавить, чому я пропустив http:):

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

Якщо ви використовуєте одну із тем інтерфейсу інтерфейсу jQuery за замовчуванням, ви також можете витягнути його CSS та зображення з CDN Google .

З JQuery хостинг оптимізований, ви також повинні об'єднати awmlib2.jsі tooltiplib.jsв один файл.

Якщо ви вирішите ці питання, ви можете побачити значне покращення.

У мене була аналогічна проблема , кілька днів тому і я знайшов head.js . Це плагін Javascript, який дозволяє завантажувати всі паралельні файли JS-файлів. Сподіваюся, що це допомагає.

Я далеко не експерт, але ...

Щодо цього: "Якщо змінено-оскільки умовний запит повернув повний вміст без змін". і мої коментарі.

Код, який використовується для створення мініатюр, повинен перевіряти:

1. Чи є кешована версія мініатюри.
2. Чи є кешована версія новішою за оригінальне зображення.

Якщо будь-яке з цих даних є помилковим, мініатюру слід генерувати та повертати незалежно від того. Якщо вони обоє правдиві, то слід зробити наступну перевірку:

1. Чи є заголовок HTTP_IF_MODIFIED_SINCE
2. Чи останній змінений час кешованої версії збігається з HTTP_IF_MODIFIED_SINCE

Якщо будь-яке з цих даних є помилковим, кешований мініатюр слід повернути.

Якщо це обоє вірно, слід повернути статус 304 http. Я не впевнений, чи потрібно, але я також особисто повертаю заголовки кеш-контролю, закінчується та остання зміна разом із 304.

Що стосується GZipping, мені повідомили, що GZip-зображення не потрібно, тому ігноруйте цю частину мого коментаря.

Редагувати: я не помітив вашого додавання до вашої публікації.

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

Я також впевнений, що ваш код повинен перевірити наявність заголовка HTTP_IF_MODIFIED_SINCE і реагувати на нього. Просто встановлення цих заголовків та вашого файлу .htaccess не дасть необхідного результату.

Я думаю, що вам потрібно щось подібне:

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

Нічого собі, важко пояснити речі за допомогою цього зображення. Але ось, деякі спроби:

• файли 33-36 завантажуються так пізно, оскільки вони динамічно завантажуються всередині SWF, і SWF (25) завантажується спочатку повністю, перш ніж він завантажує будь-який додатковий вміст
• Файли 20 і 21 можуть бути (я не знаю, тому що я не знаю вашого коду) бібліотеками, які завантажуються all.js (11), але для виконання 11 він чекає всієї сторінки (і активів) для завантаження (ви повинні змінити це на domready)
• файли 22-32 завантажуються цими двома бібліотеками, знову ж таки після повного завантаження

Просто просте здогадування, оскільки такий аналіз вимагає багато тестування A / B: ваш домен .ch здається важкодоступним (довгі зелені смуги до появи першого байти).

Це означатиме, що або веб-сайт .ch погано розміщений, або що у вашого провайдера немає хорошого маршруту до них.

Враховуючи діаграми, це може пояснити великий хіт продуктивності.

Зі сторони, є цей класний інструмент cuzillion, який може допомогти вам розібратися в залежності від замовлення завантаження ресурсів.

Спробуйте запустити тести Y! Slow і Speed ​​Speed ​​на своєму сайті / сторінці та дотримуйтесь вказівок для впорядкування можливих вузьких місць. Як тільки ви наберете більший показник Y! Slow або Скорості сторінки, ви повинні отримувати величезні показники ефективності.

Ці тести підкажуть, що не так і що потрібно змінити.

Отже, ваш скрипт PHP генерує ескізи на кожному завантаженні сторінки? По-перше, якщо зображення, які ескізуються, не змінюються так часто, чи можете ви створити кеш-пам'ять таким чином, щоб їх не потрібно було розбирати щоразу при завантаженні сторінки? По-друге, ваш сценарій PHP використовує щось на зразок imagecopyresampled()створення мініатюр? Це нетривіальний приклад зниження, і PHP-скрипт нічого не поверне, доки його завершення не зменшиться. Використання imagecopymerged()натомість зменшить якість зображення, але прискорить процес. І скільки зменшення ви робите? Ці мініатюри на 5% перевищують розмір вихідного зображення або 50%? Більший розмір оригінального зображення, ймовірно, призводить до уповільнення, оскільки сценарій PHP повинен отримати оригінальне зображення в пам'яті, перш ніж він зможе зменшити його і вивести менший мініатюр.

Я знайшов URL-адресу вашого веб-сайту та перевірив окремий jpg-файл із домашньої сторінки. Хоча час завантаження зараз розумний (161 мс), він чекає 126 мс, що набагато забагато.

Ваші останні змінені заголовки налаштовані на Sat, 01 січня 2011 12:00:00 GMT, що виглядає занадто "круглим", щоб бути реальною датою покоління ;-)

Оскільки кеш-контроль є "загальнодоступним, максимальний вік = 14515200", довільні останні змінені заголовки можуть спричинити проблеми через 168 днів.

Так чи інакше, це не справжня причина затримок.

Ви повинні перевірити, що робить генератор мініатюр, коли мініатюра вже існує і що може зайняти стільки часу на перевірку та доставку зображення.

Ви можете встановити xdebug для профілю сценарію і побачити, де є вузькі місця.

Можливо, вся справа використовує рамки або підключається до якоїсь бази даних ні за що. Я бачив дуже повільно mysql_connect () на деяких серверах, в основному тому, що вони підключалися за допомогою TCP, а не socket, іноді з деякими проблемами DNS.

Я розумію, ви не можете розмістити свій платний генератор тут, але боюся, що занадто багато можливих проблем ...

Якщо немає справді вагомих причин (зазвичай їх немає), ваші зображення не повинні викликати інтерпретатора PHP.

Створіть правило перезапису для свого веб-сервера, який подає зображення безпосередньо, якщо воно знайдено у файловій системі. Якщо ні, перенаправляйте на свій скрипт PHP, щоб створити зображення. Редагуючи зображення, змініть ім'я файлу зображень, щоб змусити користувачів, які мають кешовану версію, отримати нещодавно відредаговане зображення.

Якщо це не працює принаймні, то тепер ви не матиме нічого спільного з тим, як створюються та перевіряються зображення.

Досліджуйте використання PHP даних сеансу. Можливо (просто можливо) сценарій PHP, що генерує зображення, чекає, щоб отримати блокування даних сеансу, яке блокується головною сторінкою, що все ще рендерується, або іншими сценаріями надання зображень. Це зробило б усі оптимізації JavaScript / браузера майже неактуальними, оскільки браузер чекає сервера.

PHP блокує дані сеансу для кожного запущеного сценарію, з моменту початку обробки сеансу, до моменту закінчення сценарію або після виклику session_write_close (). Це ефективно серіалізує речі. Перегляньте сторінку PHP про сеанси, особливо коментарі, як ця .

Це лише дика здогадка, оскільки я не переглянув ваш код, але я підозрюю, що сеанси тут можуть відігравати певну роль. Наведено нижче в статті Посібник з PHP session_write_close():

Дані сеансу зазвичай зберігаються після завершення сценарію без необхідності виклику session_write_close (), але оскільки дані сеансу заблоковані для запобігання одночасного запису, лише один сценарій може працювати на сеансі в будь-який час. При використанні наборів фреймів разом із сеансами ви відчуєте завантаження кадрів один за одним завдяки цьому блокуванню. Ви можете скоротити час, необхідний для завантаження всіх кадрів, припинивши сеанс, як тільки будуть змінені змінні сеансу.

Як я вже говорив, я не знаю, що робить ваш код, але ці графіки здаються дивно підозрілими. У мене була подібна проблема, коли я кодував багатофункціональну функцію обслуговування файлів, і у мене була та сама проблема. Під час подання великого файлу я не міг змусити функціонувати багатопартійність, а також не міг відкрити іншу сторінку, поки завантаження не було завершено. Виклики session_write_close()виправили обидві мої проблеми.

Ви спробували замінити створені php мініатюри звичайними зображеннями, щоб побачити, чи є різниця? Проблема може бути навколо - помилка у вашому PHP-коді, що призводить до регенерації мініатюр при кожному виклику сервера - затримка вашого коду (сон ()?), Пов’язана з проблемою годинника, - важке питання, що спричиняє дуже поганий стан гонки оскільки всі ескізи завантажуються / генеруються одночасно.

Я думаю, що замість цього скрипта-генератора мініатюр ви повинні спробувати TinySRC спробувати швидку швидку генерацію мініатюр. Він має дуже простий та простий у використанні API, який ви можете використовувати:

http://i.tinysrc.mobi/ [висота] / [ширина] /http://domain.tld/path_to_img.jpg

[ширина] (необов’язково): - Це ширина в пікселях (що переосмислює адаптивне або сімейне розміри). Якщо з префіксом "-" або "x" він буде відніматися від або зменшуватись до відсотка від визначеного розміру.

[висота] (необов’язково): - Це висота в пікселях, якщо ширина також присутня. Він також переосмислює адаптивне або розмір сімейства і може бути префіксом "-" або "x".

Ви можете перевірити резюме API тут

FAQ

Що коштує мені tinySrc?

Нічого.

Коли я можу почати використовувати tinySrc?

Тепер.

Наскільки надійний сервіс?

Ми не надаємо жодних гарантій щодо послуги tinySrc. Однак він працює на великій розподіленій хмарній інфраструктурі , тому забезпечує високу доступність у всьому світі. Він повинен бути достатнім для всіх ваших потреб.

Як швидко це?

tinySrc кешує розміри зображень у пам'яті та в нашій сховищі даних протягом 24 годин , і він не буде отримувати ваше початкове зображення кожного разу. Це робить служби надзвичайно швидкими з точки зору користувача. (І зменшує навантаження вашого сервера як хороший побічний ефект.)

Щасти. Просто пропозиція, оскільки ви не показуєте нам код: p

Оскільки деякі веб-переглядачі завантажують лише 2 паралельних завантаження на домен, ви не можете додати додаткові домени для розподілу запитів на два-три різні імена хоста. наприклад 1.imagecdn.com 2.imagecdn.com

Перш за все, вам потрібно обробляти If-Modified-Sinceзапити і так, як сказав Джеймс. Ця помилка зазначає, що: "Коли я запитую у вашого сервера, чи змінено це зображення з останнього разу, він надсилає все зображення замість простого" так / ні ".

Час між з'єднанням та першим байтом, як правило, займає час запуску сценарію PHP. Очевидно, що щось відбувається, коли цей сценарій починає працювати.

1. Ви розглядали можливість її профілювання? У неї можуть бути деякі проблеми.
2. У поєднанні з вищевказаною проблемою сценарій може працювати набагато більше, ніж потрібно. В ідеалі він повинен генерувати великі пальці, лише якщо оригінальне зображення змінено та надсилає кешовані пальці для кожного іншого запиту. Ви перевірили, що сценарій генерує зображення без необхідності (наприклад, для кожного запиту)?

Створення належних заголовків через додаток трохи складне, плюс вони можуть перезаписатися сервером. І ви піддаєтеся зловживанням, оскільки кожен, хто надсилає заголовки запитів без кешу, призведе до того, що генератор мініатюр буде працювати постійно (і збільшувати навантаження). Тому, якщо можливо, спробуйте зберегти створені великі пальці, зателефонуйте збереженим зображенням безпосередньо зі своїх сторінок і керуйте заголовками .htaccess. У цьому випадку вам навіть не знадобиться нічого у .htaccessвашому сервері, якщо ваш сервер налаштований належним чином.

Окрім них, ви можете застосувати деякі яскраві ідеї оптимізації з частин продуктивності цього загального приємного запитання про те, як правильно робити веб-сайти , як, наприклад, розділити свої ресурси на субдомени без файлів cookie тощо. не повинен зайняти секунди для завантаження, це очевидно, якщо порівнювати з іншими елементами графіків. Спробуйте визначити проблему перед оптимізацією.

Ви намагалися налаштувати декілька субдоменів під веб-сервером NGINX спеціально для подання статичних даних, таких як зображення та таблиці стилів? Щось корисного вже можна знайти в цій темі .

Що стосується затримок мініатюр, спробуйте ввести дзвінок на flush () одразу після останнього дзвінка до header () у вашому сценарії генерації мініатюр. Після закінчення регенеруйте графік водоспадів і подивіться, чи затримка тепер на корпусі замість заголовків. Якщо це так, вам потрібно довго поглянути на логіку, яка генерує та / або видає дані зображення.

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

Більшість повільних питань полягає в тому, що ваш TTFB (Час до першого байту) занадто високий. Це важко вирішити, не наближаючись до файлів конфігурації вашого сервера, коду та базового обладнання, але я можу бачити, що це розгул у кожному запиті. У вас занадто багато зелених смуг (погано) і дуже мало блакитних смужок (добре). Можливо, ви хочете трохи зупинити оптимізацію інтерфейсу, оскільки я вважаю, що ви багато зробили в цій галузі. Незважаючи на приказку про те, що " 80% -90% часу відповіді кінцевого користувача витрачаються на передній план ", я вважаю, що ваше трапляється на початку.

TTFB - це резервні матеріали, серверні матеріали, попередня обробка до виводу даних та рукостискання.

Час виконання коду на пошук повільних речей, таких як повільні запити до бази даних, час введення та виходу функцій / методів для пошуку повільних функцій. Якщо ви використовуєте php, спробуйте Firephp . Іноді це один або два повільних запити, які виконуються під час запуску чи ініціалізації, наприклад, витягування інформації про сеанс чи перевірка автентичності, а що ні. Оптимізація запитів може призвести до хороших прибутків персоналу. Іноді код виконується за допомогою автозавантаження php prepend або spl, щоб вони працювали на всьому. В іншому випадку це може бути неправильно налаштовано apache conf та налаштування, що економить день.

Шукайте неефективні петлі. Шукайте повільні виклики кешів або повільні операції вводу / виводу, спричинені несправними дисковими накопичувачами або великим використанням дискового простору. Шукайте звичаї пам’яті та те, що використовується і де. Запустіть повторний тест на веб-сторінці з 10 запусками на одне зображення або файл, використовуючи лише перший погляд з різних місць світу, а не одне і те ж місце. І читайте ваші журнали доступу та помилок, занадто багато розробників ігнорують їх і покладаються лише на виведені на екрані помилки. Якщо ваш веб-хостинг має підтримку, попросіть їх допомогти, якщо вони, можливо, ввічливо попросять їх про допомогу, це не зашкодить.

Ви можете спробувати попереднє завантаження DNS для боротьби з багатьма доменами та ресурсами, http://html5boilerplate.com/docs/DNS-Prefetching/

Ваш сервер хороший / гідний сервер? Іноді кращий сервер може вирішити багато проблем. Я прихильник " апаратного забезпечення дешеве, програмістів дорого " менталітет, якщо у вас є шанс і гроші оновити сервер. І / або використовувати CDN, наприклад maxcdn або cloudflare або подібне.

Щасти!

(ps я не працюю ні в одній з цих компаній. Також посилання на cloudflare вище стверджуватиме, що TTFB - це не так важливо, я кинув його туди, щоб ви могли отримати ще одне.)

Вибачте, що ви надаєте мало даних. І ви вже мали кілька хороших пропозицій.

Як ви подаєте ці зображення? Якщо ви передаєте їх через PHP, ви робите дуже погану справу, навіть якщо вони вже створені.

НІКОЛИ НЕЗАЛЕЖНІ ЗОБРАЖЕННЯ З PHP. Це сповільнить ваш сервер, незалежно від способу його використання.

Помістіть їх у доступну папку із значущим URI. Потім зателефонуйте їм безпосередньо зі своїм справжнім URI. Якщо вам потрібно в режимі покоління, ви повинні помістити .htaccess у каталог зображень, який перенаправляє на генератор php-скрипт, лише якщо зображення запиту відсутнє. (це називається стратегією кешування на запит).

Це дозволить виправити сеанс php, браузер-проксі, кешування, ETAGS, і все, що відразу.

WP-Supercache використовує цю стратегію, якщо правильно налаштовано.

Я писав це деякий час тому ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), остання версія перервана, але я думаю, 8 чи менше повинні працювати, і ви можете візьміть .htaccess як приклад просто для перевірки речей (хоча є кращі способи налаштування .htaccess, ніж я раніше).

Я описав цю стратегію в цій публікації в блозі ( http://www.stefanoforenza.com/need-for-cache/ ). Це, мабуть, погано написано, але це може допомогти з’ясувати речі.

Подальше читання: http://meta.wikimedia.org/wiki/404_handler_caching