У мене працює система nginx / php-fpm / лак / wordpress та amazon s3.

Зараз я переглянув безліч файлів конфігурації під час налаштування системи, і в усіх них я знайшов щось подібне:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

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

Мені набагато більше сенсу кешувати лише динамічні файли, щоб php-fpm / mysql не потрапив так сильно.

Я прав чи я щось тут пропускаю?

ОНОВЛЕННЯ

Я хочу додати трохи інформації до питання, виходячи з наведеної відповіді.

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

Однак, для мене важливіший статичний конус . Я знайшов посилання з деякими тестами та орієнтирами для різних програм кешу та веб-серверів.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX насправді швидше отримує ваш статичний вміст, тому має сенс просто пропустити його. NginX чудово працює зі статичними файлами.

-

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

У лаку є кілька переваг. Перше, що ви зазначаєте, - це зменшення навантаження на бекенд-сервер. Зазвичай шляхом кешування вмісту, який генерується динамічно, але змінюється рідко (порівняно з частотою доступу до нього). Беручи приклад Wordpress, більшість сторінок, імовірно, не змінюються дуже часто, і існують деякі плагіни, які можуть визнати недійсним кеш лаку при зміні сторінки (тобто нова публікація, редагування, коментар тощо). Тому ви кешуєте нескінченно та визнаєте недійсними зміни, що призводить до мінімального завантаження вашого сервера.

Пов'язана стаття, не витримуючи, більшість людей вважає, що Varnish працює краще, ніж Nginx, якщо налаштування належним чином - хоча, (і я дуже ненавиджу це визнати) - мої власні тести, здається, погоджуються, що nginx може подавати статичний файл швидше, ніж лак ( на щастя, я не використовую для цього лак). Я думаю, що проблема полягає в тому, що якщо ви закінчите використовувати Varnish, ви додали додатковий шар до своєї установки. Передача цього додаткового шару на сервер бекендера завжди буде повільнішою, ніж просто подання безпосередньо з бекенда - і саме тому дозволяти Varnish кешувати може бути швидше - ви економите крок. Інша перевага - на передньому диску-io. Якщо ви налаштовуєте лак для використання malloc, ви взагалі не потрапляєте на диск, що залишає його доступним для інших процесів (і, як правило, прискорює роботу).

Я думаю, що для того, щоб дійсно оцінити ефективність, потрібен кращий орієнтир. Неодноразово вимагаючи одного і того ж одного файлу, запускає кеші файлової системи, які починають зміщувати фокус від самих веб-серверів. Кращим орієнтиром було б використовувати облогу з кількома тисячами випадкових статичних файлів (можливо, навіть із журналів вашого сервера) для імітації реалістичного трафіку. Імовірно, хоча, як ви вже згадували, все частіше стає завантажувати статичний вміст на CDN, а це означає, що Varnish, ймовірно, не буде його обслуговувати для початку (ви згадуєте S3).

У реальному сценарії, ви, ймовірно, надайте пріоритет використанню пам'яті - спочатку динамічного контенту, оскільки це найдорожче для створення; то невеликий статичний вміст (наприклад, js / css), і нарешті зображення - ви, ймовірно, не запам’ятовуватимете інші носії в пам’яті, якщо тільки у вас є справді вагомі причини для цього. У цьому випадку, коли Varnish завантажує файли з пам'яті та nginx завантажує їх з диска, Varnish, ймовірно, буде виконувати nginx (зауважте, що кеші nginx призначені лише для проксі-файлів і fastCGI, а ті, за замовчуванням, засновані на диску - хоча, це можливо використовувати nginx з memcached).

(Мій швидкий - дуже брутальний, не даючи довіри - тест показав, що nginx (direct) був найшвидшим - давайте назвемо це 100%, лак (з malloc) трохи повільніше (близько 150%), а nginx за лаком ( З пропусканням) було найповільнішим (близько 250%). Це говорить саме за себе - все або нічого - додаючи додатковий час (і обробляючи) для спілкування з бекендом, просто підказує, що якщо ви використовуєте Varnish, і запам’ятовує оперативну пам’ять , ви також можете просто кешувати все, що можете, і подавати його з Varnish, а не переходити до nginx.)

Я думаю, ти можеш чогось пропустити.

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

Як простий приклад, скажімо, що у вас є сторінка з ім’ям користувача, який увійшов у верхній частині сторінки. Кожен раз, коли ця сторінка завантажується, запускається запит до бази даних, щоб визначити, яке ім'я користувача належить користувачеві, який увійшов у систему, запитуючи сторінку, що забезпечує відображення власного імені. Якби ви кешували цю сторінку, запит до бази даних не відбудеться, і всі користувачі побачать одне і те ж ім’я користувача у верхній частині сторінки, і, швидше за все, це не буде їх ім'ям користувача. Потрібно, щоб цей запит відбувався на кожному завантаженні сторінки, щоб забезпечити відображення належного імені користувача кожному користувачеві. Тому він не є кешованим.

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

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

У своєму фрагменті коду вище ви бачите дуже типовий фрагмент лаку VCL, який змушує кешувати зображення, css та javascript. За замовчуванням Varnish не буде кешувати жоден запит із файлом cookie. Логіка полягає в тому, що якщо в запиті є файл cookie, то сервер повинен мати певну причину, щоб він потребував цього файлу cookie, щоб він був потрібен на зворотному кінці і повинен бути переданий через кеш. Насправді багато CMS (Drupal, Wordpress тощо) приєднують файли cookie майже до всього, незалежно від того, потрібен він чи ні, тому звичайно писати VCL для видалення файлів cookie з вмісту, який, як відомо, є статичним, що, в свою чергу, призводить до того, що Varnish кешується це.

Мати сенс?

Що стосується динамічного вмісту , то подібні котирування акцій насправді часто змінюються (оновлюються щосекунди SaaS serverз а backend server), але можуть бути запитувані ще частіше (на десятки тисяч subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

У цьому випадку кешування на оновленеSaaS server оновлення за секунду backend serversдає змогу задовольнити запити десятків тисяч subscription users.

Без кешу на сервері SaaS ця модель просто не працювала б.

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

Для статичних файлів: кеш на жорсткий диск. Для всього іншого: кеш-пам'ять в оперативній пам'яті.

Це має дати вам більше уявлення про те, як реалізувати цей сценарій: http://www.getpagespeed.com/server-setup/varnish-static-files-cache