- Що таке shared-хостинг і чому він потребував нових рішень
- Що змінили CMS в роботі сайтів
- Ізоляція сусідів на спільному сервері
- Що це дає для оптимізації
Ранній веб був доволі простим: сайти складалися зі статичних HTML-сторінок, які сервер віддавав на запит браузера, та й усе. Згодом вони почали обростати відео, базами даних, великими каталогами товарів і колекціями файлів. З’явилися особисті кабінети, кошики, онлайн-оплата та інші функції, які потребували дедалі більше ресурсів. Разом із сайтами мав розвиватися і хостинг: ставати потужнішим та знаходити нові способи опрацювання запитів. Це була своєрідна гонка — щойно у вебі з’являлося щось нове, сервери мали навчитися з цим працювати.
У 1998 році типовий сайт міг складатися з кількох HTML-файлів. Через 10 років, у 2008-му, одна сторінка WordPress уже могла запускати сотні PHP-функцій і десятки SQL-запитів. У 2018 році до цього додалися складні JavaScript-фреймворки, численні API, сторонні сервіси, відео та персоналізований контент. А до 2028 року сайти, ймовірно, ще активніше використовуватимуть ШІ, генеруватимуть частину контенту в реальному часі та підлаштовуватимуть інтерфейс під конкретного користувача. Це величезна еволюція, і вона триває.
Що таке shared-хостинг і чому він потребував нових рішень
Shared-хостинг — один із найпоширеніших видів хостингу. На ньому хостять багато чого — від особистих блогів до сайтів невеликих магазинів. Як правило, хостинги такого типу одразу дають в пакеті можливість встановити або отримати попередньо встановлену CMS. Напевне, якщо ви шукали хостинг, ви бачили пропозиції на кшталт «WordPress-хостинг», «Інтернет-магазини на конструкторі сайтів» тощо.
На початку історії мережі, щоб розмістити сайт, потрібно було мати власний сервер або орендувати його цілком. Shared-хостинг вирішував проблему дорожнечі таких серверів. Якщо ви хочете торгувати, скажімо, крафтовим папером у невеличкому магазинчику, тисячі доларів на персональний сервер вам просто не по кишені. Але окрім цього — ви ніколи не використаєте всіх його потужностей. Надмірно і дорого. Отже, новий вид хостингу дозволяв розміщувати на одному сервері сотні сайтів замість одного, сильно знижуючи витрати.
Тарифи Erols Internet на хостинг у 1997–1998 роках. Навіть базовий пакет із 25 МБ дискового простору коштував $400 за підключення та ще $480 на рік. Такі ціни здаються драконівськими, але тоді бізнес-хостинг був складною і дорогою послугою, орієнтованою передусім на компанії. Джерело: JeremyPerson.com.
Суть проста: замість того щоб виділяти окремий комп'ютер для кожного клієнта, один сервер ділить свої ресурси між багатьма сайтами. Усі вони використовують той самий процесор, оперативну пам'ять, диск і мережеве з'єднання. Чому це стало можливим? Відповіді дві: особливості навантаження та сама ідея віртуального хостингу.
Більшість сайтів значну частину часу створює невелике навантаження. Відвідувачі приходять нерівномірно, а пікові періоди в різних проєктів зазвичай не збігаються. Тому ресурси одного великого сервера можна розподілити між багатьма сайтами: поки один використовує більше потужностей, іншим вони можуть бути просто не потрібні.
Друге, що зробило таку модель можливою, — механізм віртуального хостингу.
Важливу роль у розвитку shared-хостингу відіграв стандарт HTTP/1.1, опублікований у 1997 році. Він зробив обов’язковим заголовок Host, через який браузер повідомляє серверу, до якого саме домену звертається. Завдяки цьому один сервер і навіть одна IP-адреса могли обслуговувати багато різних сайтів. Це не лише здешевило хостинг, а й допомогло сповільнити вичерпання адрес IPv4.
Вебсервер визначає, до якого домену звернувся користувач, і віддає відповідний сайт. Для власника це виглядає так, ніби він має окремий простір для свого проєкту, хоча процесор, пам'ять і диск насправді розподіляються між десятками або сотнями клієнтів.
Саме ця модель зробила веб по-справжньому доступним. Запустити сайт більше не означало купувати власний сервер — достатньо було орендувати невелику частку вже існуючого.
Окремою сторінкою в історії доступного вебу став GeoCities — один із найвідоміших сервісів безплатного хостингу 1990-х. Користувачі отримували 1 МБ дискового простору й могли створити власну сторінку без купівлі сервера та глибоких технічних знань. Сайти розподілялися за тематичними «районами»: наприклад, сторінки про технології оселялися в SiliconValley, а про кіно та знаменитостей — у Hollywood. У результаті GeoCities перетворився на величезне цифрове місто з яскравими фонами, анімованими GIF, лічильниками відвідувань і написами «Under construction». Більше про цей легендарний сервіс та інтернет 1990-х ми розповіли в нашому відео.
Але така система добре працює лише тоді, коли всі «сусіди» споживають приблизно однакову кількість ресурсів. Та з поширенням динамічних сайтів і CMS підтримувати цю рівновагу ставало дедалі складніше. Один проєкт міг створювати сотні PHP-процесів, постійно звертатися до бази даних або різко збільшувати навантаження під час сплеску відвідуваності.
Що змінили CMS в роботі сайтів
CMS стали одним із найпоширеніших різновидів динамічних сайтів. На відміну від статичних сторінок, вони формують HTML за допомогою програмного коду, даних із бази та встановлених модулів.
Як користувачам, нам все одно, що відбувається всередині сайту. Ми помічаємо проблеми, але ніколи не думаємо про внутрішні процеси, якщо сайт не зависає посеред купівлі квитків на поїзд.
Спочатку більшість сайтів складалися зі звичайних HTML-файлів. Якщо потрібно було змінити текст на сторінці, адміністратор відкривав файл і редагував його вручну.
CMS (Content Management System, система керування контентом) змінили цю модель. Замість набору готових сторінок сайт став програмою. Тексти, структура сторінок і налаштування почали зберігатися в базі даних, а зображення та інші файли — у сховищі сайту. Під час кожного запиту CMS збирала з цих компонентів готову сторінку.
Для власника сайту це означало, що більше не потрібно знати HTML, аби опублікувати новину чи написати статтю. Можна впоратися самому чи призначити контент-менеджера, який не є веб-дизайнером, коштує дешевше, швидко дає ради. Для сервера ж кожен перегляд сторінки раптом став значно складнішою роботою: ми пам’ятаємо, що сервер не просто віддавав сторінку, діставши з бібліотеки, він її перестворював. Отже, потрібно було вдосконалювати ці процеси так, щоб економити ресурси і спрощувати шлях.
OPcache: економія процесорного часу
Коли користувач відкривав сторінку WordPress, щоразу виконував одну й ту саму роботу. Це відбувалося так: PHP читав десятки файлів із диска, перетворював їх на внутрішнє представлення (байткод) і лише потім запускав.
Тобто навіть якщо код сайту взагалі не змінювався, сервер виконував однакову підготовчу роботу при кожному запиті. OPcache почав зберігати вже скомпільований код у пам'яті. Надалі PHP міг одразу виконувати програму, минаючи кілька дорогих етапів.
Фактично сервер перестав щоразу «перечитувати книгу» перед тим, як відповісти користувачу.
Перший opcode cache для PHP створила компанія Zend Technologies ще у 1998 році. Він називався Zend Optimizer (пізніше Zend Optimizer+). У 2013 році співзасновник компанії і один зі співавторів сучасного PHP Зеєв Сураскі запропонував відкрити вихідний код Optimizer+ і включити його до PHP 5.5. Після інтеграції компонент отримав назву OPcache.
До речі, у панелі керування хостингом Cityhost.ua є можливість підключити інструменти кешування в розділі Сайти — Додаткові послуги.
Читайте також: Сервіси кешування для сайтів: Memcached, OPCache, Redis
Page cache: економія на повторному створенні сторінок
Для більшості відвідувачів головна сторінка однакова. Але ми знов згадуємо про те, що CMS може кожного разу заново запитувати базу даних, запитувати плагіни, формувати HTML заново.
Тож наступним питанням було, навіщо створювати з нуля сторінку, яка майже завжди однакова. Її теж треба було кешувати. Після першого запиту сервер зберігав уже готовий HTML, а CMS узагалі не мусила запускатися, щоб показати цю сторінку. Менше навантаження на процесор і бази даних, блискавична відповідь сайту — всі щасливі.
Але що, як сторінка змінилася? Наприклад, у блозі з’явилася нова стаття, яку треба показати в блоці новин на головній сторінці — і це вже не та сама сторінка. І тут оптимізація мусила щоразу знаходити відповідь на запитання, в який момент можна взагалі не запускати CMS, а коли головну сторінку треба ще раз перестворити.
Так виник мем про найважчі речі в програмуванні. Цитата належить Філу Карлтону (працівнику Xerox PARC): «У програмуванні є лише дві справді складні речі: інвалідація кешу та неймінг».
Object cache: економія на запитах до бази даних
Динамічний сайт постійно звертається до бази даних, що б не сталося, від коментаря до зміни категорії товару. І звернення знов-таки дорогі, але часто безсенсовні, бо якась сторінка може бути тою самою місяцями.
Object cache дає можливість запам’ятовувати результати окремих запитів до баз даних. Якщо застосунок уже знає, які категорії існують або яке значення має певне налаштування, немає сенсу щоразу турбувати MySQL.
Тут можна звернутися до ще однієї цікавої історії — Memcached, системи, яку створили не для CMS, але яка вирішувала схожу проблему. Придумали її для Livejournal, сайту з велетенською кількістю особистих щоденників, на якому колись сиділи всі наші знайомі. У них була проблема: база даних переставала справлятися з навантаженням, хоча величезна кількість запитів повертала ті самі результати. Інженер Бред Фіцпатрік із колегами написав невеликий сервіс, який просто запам'ятовував відповіді в оперативній пам'яті. Це рішення швидко виявилося універсальним, і його почали використовувати практично всі великі PHP-проєкти.
Читайте також: Плагіни для WordPress, які варто встановити відразу — чекліст для запуску сайту
PHP-FPM: економія на процесах
Навіть якщо код уже був скомпільований, а частина даних — закешована, залишалася ще одна проблема.
На початку PHP зазвичай працював через CGI (Common Gateway Interface). Для кожного HTTP-запиту вебсервер запускав окремий процес PHP, виконував скрипт і одразу завершував його роботу. Сотні відвідувачів на сайті означали сотні нових процесів, що помітно збільшувало навантаження.
Першим кроком став FastCGI. Його ідея була простою: не запускати PHP заново для кожного запиту. Замість цього сервер підтримував кілька вже готових PHP-процесів і просто передавав їм нові запити.
Згодом у PHP з'явився PHP-FPM (FastCGI Process Manager) — менеджер процесів, який автоматично створював, завершував і масштабував пул PHP-процесів залежно від навантаження.
У результаті сервер перестав витрачати ресурси на постійне створення нових процесів і міг значно ефективніше обслуговувати велику кількість одночасних відвідувачів.
Ізоляція сусідів на спільному сервері
У shared-хостингу сотні сайтів працюють на одному сервері й користуються спільними ресурсами. Якщо один із них раптом отримував великий сплеск трафіку або запускав невдалий скрипт, це могло позначитися на всіх сусідах.
У 2010 році компанія CloudLinux на чолі з Ігорем Селецьким запропонувала рішення. Хоча механізми ізоляції процесів у Linux вже існували, CloudLinux адаптував їх до потреб хостинг-провайдерів. Технологія LVE (Lightweight Virtual Environment) дозволила встановлювати окремі ліміти на процесор, пам'ять, диск і кількість процесів для кожного акаунта.
Після цього проблемний сайт міг уповільнити лише себе, а сервер продовжував працювати нормально. В цьому місці хостер може запропонувати докупити ресурси для акаунта, що систематично відчуває перевантаження.
Що це дає для оптимізації
Зараз буде ілюстративна модель. Я попросила ШІ прикинути, скільки сайт міг би витрачати ресурсів БЕЗ оптимізації, якби працював з сучасною графікою, каталогами та плагінами. Це не точні цифри, тому що все залежить від того, яка CMS стоїть на сайті, які плагіни, скільки людей туди ходить тощо. Але порядок чисел може бути схожим.
Візьмімо умовний популярний новинний сайт із мільйоном переглядів сторінок на добу. Це в середньому близько 12 переглядів за секунду, але під час піків може бути удесятеро більше.
Припустімо, що без будь-яких оптимізацій створення однієї сторінки CMS займає близько 300 мілісекунд. У цей час входить виконання PHP-коду, робота плагінів, звернення до бази даних і формування HTML.
За добу це становитиме:
1 000 000 × 0,3 секунди = 300 000 секунд, або приблизно 83 години сумарного часу обробки запитів.
Тепер уявімо, що сайт використовує сучасний стек оптимізацій.
- 95% сторінок віддаються безпосередньо з page cache і потребують лише 2 мілісекунди на обробку.
- Решта 5% справді генеруються CMS, але завдяки OPcache, object cache та PHP-FPM їхня обробка займає близько 100 мілісекунд.
Середній час обробки одного запиту тоді становитиме:
95% × 2 мс + 5% × 100 мс = 6,9 мс.
За мільйон переглядів це вже:
1 000 000 × 0,0069 секунди = 6 900 секунд, або приблизно 1,9 години сумарного часу обробки запитів.
У цій спрощеній моделі різниця становить понад 40 разів.
У грошах різниця може виглядати не як «сервер за $50 проти сервера за $2», бо до вартості входять пам’ять, база даних, диски, резервування, мережа та здатність витримувати піки. Проте порядок величини показовий: без цих оптимізацій популярному CMS-сайту могла б знадобитися ферма з десятків серверних ядер, тоді як оптимізована версія обходиться кількома.
Читайте також: ТОП-3 CMS для створення інтернет-магазину
Це і дозволяє хостити звичайні сучасні сайти, які насправді весь час виконують купу завдань, на дешевих невеликих хостингах, а користувачам — отримувати відповідь сайту за секунди, а не за години, як було колись, якщо сайт перевантажувався. Захист працює не завжди ідеально. Ми досі можемо покласти сайт у день продажу бажаних квитків, замовлення очікуваної книги чи якщо там з’явилася якась гаряча новина. І все ж здебільшого сервери дають ради навіть з великим напливом відвідувачів, які масово щось замовляють або скролять.
Важко навіть уявити, скільки ресурсів сумарно економлять щодня. Щоправда, тепер з’явився штучний інтелект, який споживає безмір електрики, карт пам’яті і води для охолодження. Але, ймовірно, його розвиток теж буде рухатися в бік оптимізації. Або ні?
