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

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

Бази даних

На даний момент я планую використовувати функції MySQLi в PHP5. Однак як я повинен налаштувати бази даних стосовно користувачів та вмісту? Мені насправді потрібні кілька баз даних? На даний момент все переплуталося в одну базу даних, хоча я розглядав можливість поширювати дані користувачів на один, фактичний вміст в інший і, нарешті, основний вміст сайту (майстри шаблонів тощо) в інший. Моє міркування полягає в тому, що надсилання запитів до різних баз даних полегшить навантаження на них як одна база даних = 3 джерела навантаження. Також це все ще було б ефективним, якби вони були на одному сервері?

Кешування

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

Моє питання з цього приводу:

Скажіть, у мене є коментарі до різних статей. Що є кращим рішенням: зберігайте простий шаблон коментаря та надайте коментарі (з виклику DB) щоразу, коли сторінка завантажується, або зберігайте кешовану копію сторінки коментарів у вигляді HTML-сторінки - щоразу, коли коментар додається / редагується / видаляється сторінка перероблена.

Нарешті

Хто-небудь має поради / вказівки щодо запуску сайту з високим навантаженням на PHP. Я впевнений, що це працездатна мова - Facebook та Yahoo! надайте йому великого переваги - але чи є досвід, на який я повинен стежити?

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

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

І не забувайте, що ви ніколи не зробили масштабування. Сайт, який обробляє 10req / s, потребує змін для підтримки 1000req / s. І якщо вам вистачає удачі для підтримки 10 000рек / с, ваша архітектура, мабуть, буде виглядати зовсім інакше.

Бази даних

• Не використовуйте MySQLi - PDO - це «сучасний» рівень доступу до баз даних OO. Найважливіша функція, яку потрібно використовувати, - це заповнювачі у ваших запитах. Це досить розумно, щоб використовувати підготовку на сервері та інші оптимізації також.
• Напевно, ви не хочете зламати свою базу даних в цей момент. Якщо ви виявите, що одна база даних не ріже, існує декілька методів масштабування, залежно від вашої програми. Реплікація на додаткові сервери, як правило, працює добре, якщо у вас є більше читань, ніж записів. Шардінг - це техніка поділу даних на багато машин.

Кешування

• Напевно, ви не хочете кешувати вашу базу даних. База даних, як правило, є вашим вузьким місцем, тому додати в неї більше IO, як правило, це погано. Є кілька кешів PHP, які виконують подібні речі, як APC та Zend.
• Виміряйте систему за допомогою кешування і вимикання. Надіваюсь, ваш кеш важче, ніж обслуговування сторінок прямо.
• Якщо потрібно тривати тривалий час для створення ваших коментарів та даних про статтю з db, інтегруйте memcache у свою систему. Ви можете кешувати результати запитів і зберігати їх у запам’ятовуваному екземплярі. Важливо пам’ятати, що витяг даних з пам’яті повинен бути швидшим, ніж збирання їх із бази даних, щоб побачити будь-яку користь.
• Якщо ваші статті не динамічні, або у вас є прості динамічні зміни після їх створення, подумайте про те, щоб записати html або php на диск. Ви можете мати сторінку index.php, яка шукає на диску статтю, якщо вона є, вона передає її клієнту. Якщо це не так, він генерує статтю, записує її на диск і відправляє клієнту. Видалення файлів з диска призведе до перезапису сторінок. Якщо до статті буде доданий коментар, видаліть кешовану копію - вона буде відтворена.

Я провідний розробник сайту з більш ніж 15 мільйонами користувачів. У нас було дуже мало проблем зі масштабуванням, тому що ми планували це РІЧНО і продумано масштабували. Ось деякі стратегії, які я можу запропонувати зі свого досвіду.

СХЕМА Спочатку денормалізуйте свої схеми. Це означає, що замість того, щоб мати декілька реляційних таблиць, слід замість цього вибрати одну велику таблицю. Взагалі, приєднання - це марна дорогоцінні ресурси БД, оскільки виконання декількох підготовлень та порівняння спалює дискові введення-виведення. Уникайте їх, коли можете.

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

ІНДЕКСІНГ Переконайтеся, що ваші запити використовують принаймні один індекс. Однак остерігайтеся, що індекси обійдуться вам, якщо ви пишете або оновлюєте часто. Є кілька експериментальних хитрощів, щоб цього уникнути.

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

Уникайте обчислених запитів, як чума. Якщо потрібно обчислити запит, спробуйте це зробити один раз під час запису.

КАШИНГ Я дуже рекомендую Memcached. Це було доведено найбільшими гравцями на стеку PHP (Facebook) і є дуже гнучким. Для цього є два способи: один - кешування у вашому шарі БД, інший - кешування у вашому шарі бізнес-логіки.

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

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

ОБМЕЖЕННЯ ДАНИХ Реплікація досягає лише вас. Швидше, ніж ви очікуєте, ваші записи стануть вузьким місцем. Щоб отримати компенсацію, переконайтеся, що раніше потрібно підтримувати загострення даних. Ви, швидше за все, захочете застрелити себе пізніше, якщо цього не зробите.

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

Мінусом цього є те, що може складно зібрати дані з декількох фрагментів. Але, ви також можете спроектувати це.

ОФЛАЙНОВА ОБРАБОТКА Не змушуйте користувача чекати вашого бекенда, якщо цього не потрібно. Створіть чергу завдань і перемістіть будь-яку обробку, яку ви можете в автономному режимі, виконуючи її окремо від запиту користувача.

Я працював на кількох сайтах, які отримують мільйони / хіти / місяць, підтримувані PHP та MySQL. Ось декілька основ:

1. Кеш, кеш, кеш. Кешування - це один із найпростіших та найефективніших способів зменшити навантаження на веб-сервер та базу даних. Вміст сторінки кешу, запити, дорогі обчислення, все, що пов'язано з введенням / виводу. Memcache мертвий простий і ефективний.
2. Використовуйте декілька серверів, як тільки ви виведете з них. Ви можете мати кілька веб-серверів і декілька серверів баз даних (з тиражуванням).
3. Зменшіть загальну кількість запитів до веб-серверів. Це тягне за собою кешування JS, CSS та зображень із використанням заголовків, що закінчуються. Ви також можете перемістити статичний вміст у CDN, що прискорить роботу вашого користувача.
4. Вимірювання та орієнтир. Запустіть Nagios на своїх виробничих машинах і завантажте тест на свій сервер dev / qa. Вам потрібно знати, коли ваш сервер загориться, щоб ви могли його запобігти.

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

Ознайомтесь і з моєю публікацією в блозі про масштабованість, вона містить багато посилань на презентації щодо масштабування на кількох мовах та платформах: http://www.ryandoherty.net/2008/07/13/unicorns-and-scalability/

Re: PDO / MySQLi / MySQLND

@ gary

Ви не можете просто сказати "не використовувати MySQLi", оскільки вони мають різні цілі. PDO майже схожий на шар абстракції (хоча насправді це не так) і призначений для полегшення використання декількох продуктів бази даних, тоді як MySQLi характерний для MySQL підключень. Неправильно сказати, що PDO - це сучасний рівень доступу в контексті порівняння його з MySQLi, оскільки ваше твердження передбачає, що прогресія була mysql -> mysqli -> PDO, що не так.

Вибір між MySQLi та PDO простий - якщо вам потрібно підтримувати кілька продуктів бази даних, тоді ви використовуєте PDO. Якщо ви просто використовуєте MySQL, ви можете вибрати між PDO та MySQLi.

То чому б ви вибрали MySQLi через PDO? Дивись нижче...

@ross

Ви вірно ставитесь до MySQLnd, який є новітньою бібліотекою базового рівня мови MySQL, однак це не є заміною MySQLi. MySQLi (як і PDO) залишається таким, яким ви взаємоділи з MySQL через ваш PHP-код. Обидва вони використовують libmysql як клієнт C, що стоїть за кодом PHP. Проблема полягає в тому, що libmysql знаходиться за межами основного двигуна PHP, і саме там з'являється mysqlnd, тобто він є Native Driver, який використовує основні внутрішні PHP для максимальної ефективності, зокрема, коли йдеться про використання пам'яті.

MySQLnd розробляється самими MySQL і нещодавно приземлився у відділення PHP 5.3, яке знаходиться в тестуванні RC, готове до виходу пізніше цього року. Тоді ви зможете використовувати MySQLnd з MySQLi ... але не з PDO. Це дасть MySQLi підвищення продуктивності в багатьох областях (не у всіх) і зробить його найкращим вибором для взаємодії MySQL, якщо вам не потрібна абстракція, як можливості PDO.

З огляду на це , MySQLnd тепер доступний в PHP 5.3 для PDO, тому ви можете отримати переваги підвищення продуктивності від ND до PDO, однак PDO все ще є загальним рівнем бази даних, тому навряд чи зможете отримати користь від удосконалення в ND як MySQLi можуть .

Деякі корисні орієнтири можна знайти тут, хоча вони є з 2006 року. Ви також повинні знати про такі параметри .

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

Не просте питання, яке найкраще, тому що кожен має свої переваги та недоліки. Вам потрібно прочитати надані мною посилання та придумати власне рішення, а потім протестувати його та дізнатися. Я використовував PDO в минулих проектах, і це гарне розширення, але моїм вибором для чистої продуктивності буде MySQLi з новим параметром MySQLND, зібраним (коли виходить PHP 5.3).

Загальні

• Не намагайтеся оптимізувати, перш ніж ви почнете бачити реальне навантаження на світ. Ви можете здогадатися правильно, але якщо цього не зробите, ви витратили свій час.
• Використовуйте jmeter , xdebug або інший інструмент для орієнтування сайту.
• Якщо завантаження починає бути проблемою, кешування об'єкта чи даних, ймовірно, буде задіяно, тому загалом читайте про параметри кешування (memcached, параметри кешування MySQL)

Код

• Профілюйте свій код, щоб ви знали, де знаходиться вузьке місце та чи є він у коді чи базі даних

Бази даних

• Використовуйте MYSQLi, якщо портативність до інших баз даних не є життєво важливою, PDO в іншому випадку
• Якщо еталони виявляють базу даних, це проблема, перевірте запити, перш ніж почати кешування. Використовуйте EXPLAIN, щоб побачити, де ваші запити сповільнюються.
• Після оптимізації запитів та кешування бази даних певним чином, можливо, вам доведеться використовувати кілька баз даних. Будь-яка реплікація на декілька серверів або посилення (розбиття даних на кілька баз даних / серверів) може бути доречною, залежно від даних, запитів та типу читання / запису.

Кешування

• Багато записів було зроблено для кешування коду, об'єктів та даних. Подивіться статті на APC , Zend Optimizer , Memcached , QuickCache , JPCache . Зробіть щось із цього, перш ніж вам дійсно потрібно, і ви будете менше стурбовані тим, як почати неоптимізовано.
• APC і Zend Optimizer - це кешові коди, вони прискорюють PHP-код, уникаючи повторної повторної копіювання та перекомпіляції коду. Взагалі простий в монтажі, варто це зробити рано.
• Memcached - це загальний кеш, який можна використовувати для кешування запитів, PHP-функцій або об'єктів або цілих сторінок. Код повинен бути спеціально написаний для його використання, що може бути залученим процесом, якщо немає центральних точок для обробки, оновлення та видалення кешованих об'єктів.
• QuickCache та JPCache - це кеші файлів, інакше схожі на Memcached. Основна концепція проста, але також вимагає коду та простіша з центральними точками створення, оновлення та видалення.

Різне

• Розгляньте альтернативні веб-сервери для високого навантаження. Такі сервери, як lighthttp та nginx, можуть обробляти велику кількість трафіку в набагато меншій пам'яті, ніж Apache , якщо ви можете принести в жертву потужність і гнучкість Apache (або якщо вам просто не потрібні ті речі, які часто вам не потрібні).
• Пам'ятайте, що апаратне забезпечення сьогодні надзвичайно дешеве, тому не забудьте витратити зусилля на оптимізацію великого блоку коду порівняно з "давайте купуємо сервер монстра".
• Подумайте про те, щоб до цього питання додати теги "MySQL" та "масштабування"

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

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

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

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

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

Розбиття баз даних між серверами та використання якоїсь техніки збалансування навантаження (наприклад, генерування випадкового числа між 1 і # надмірними базами даних з необхідними даними - і використовувати це число для визначення, до якого сервера баз даних можна підключитися) також може бути відмінним способом збільшення ефективність.

Усі вони працювали досить добре в минулому для деяких сайтів з досить високим завантаженням. Сподіваюся, це допоможе вам почати :-)

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

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

Будь-який тип кешу опкоду для PHP (наприклад, APC або один із багатьох інших) також дуже допоможе.

Я запускаю веб-сайт із 7-8 мільйонами переглядів сторінок на місяць. Не страшно багато, але достатньо, щоб наш сервер відчув навантаження. Ми вибрали рішення просте: Memcache на рівні бази даних. Це рішення добре працює, якщо завантаження бази даних є вашою основною проблемою.

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

Тож ми змінили свій підхід. Ми побудували обгортку бази даних (з тими самими методами, що і в нашій старій базі даних, тому її було легко переключити), а потім підкласифікували її, щоб надати запам’ятовані методи доступу до бази даних.

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

Для чого це важливо, кешування DIRT SIMPLE у PHP навіть без розширення / пакета помічників, як запам'ятоване.

Все, що вам потрібно зробити, це створити вихідний буфер за допомогою ob_start().

Створіть функцію глобального кешу. Дзвінокob_start , передайте функцію як зворотний дзвінок. У функції знайдіть кешовану версію сторінки. Якщо існує, подавайте його і закінчуйте.

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

Додайте в термін придатності / збір сміття.

І багато людей не здогадуються про те, що ти можеш гніздо ob_start()/ ob_end()дзвонити. Отже, якщо ви вже використовуєте вихідний буфер для, скажімо, розбору в рекламі або виділення синтаксису чи будь-чого іншого, ви можете просто вкласти ще один ob_start/ob_endдзвінок.

Дякуємо за пораду щодо розширення кешування PHP - чи могли б ви пояснити причини використання один одного? Я чув чудові речі про приховані через IRC, але ніколи не чув про APC - що ви думаєте про них? Я вважаю, що використання декількох систем кешування є досить протидіючим ефектом.

Насправді, багато хто використовує APC та запам'ятовується разом ...

Схоже, я помилявся . MySQLi все ще розробляється. Але згідно статті, PDO_MySQL зараз сприяє команда MySQL. Зі статті:

Вдосконалене розширення MySQL - mysqli - є флагманом. Він підтримує всі функції MySQL Server, включаючи діаграми, підготовлені заяви та збережені процедури. Драйвер пропонує гібридний API: ви можете використовувати процедурний або об’єктно-орієнтований стиль програмування, виходячи з ваших уподобань. mysqli поставляється з PHP 5 і вище. Зауважте, що кінець життя для PHP 4 - 2008-08-08.

Об'єкти даних PHP (PDO) - це рівень абстракції доступу до бази даних. PDO дозволяє використовувати ті самі виклики API для різних баз даних. PDO не пропонує жодної ступеня абстрагування SQL. PDO_MYSQL є драйвером MySQL для PDO. PDO_MYSQL поставляється з PHP 5. Станом на PHP 5.3 розробники MySQL активно сприяють цьому. Перевага PDO від уніфікованого API полягає в тій ціні, що специфічні функції MySQL, наприклад, кілька операторів, не підтримуються повністю через уніфікований API.

Будь ласка, перестаньте використовувати перший драйвер MySQL для опублікованого PHP: ext / mysql. З моменту введення вдосконаленого розширення MySQL - mysqli - у 2004 році з PHP 5, немає ніяких причин все-таки використовувати найстаріший драйвер навколо. ext / mysql не підтримує графіки, підготовлені заяви та збережені процедури. Він обмежений набором функцій MySQL 4.0. Зауважте, що розширена підтримка MySQL 4.0 закінчується в 2008-12-31. Не обмежуйтеся набором функцій такого старого програмного забезпечення! Оновлення до mysqli, див. Також Converting_to_MySQLi. mysql знаходиться в режимі обслуговування лише з нашої точки зору.

Мені здається, стаття є упередженою щодо MySQLi. Я припускаю, що я упереджений щодо PDO. Мені дуже подобається PDO над MySQLi. Мені це прямо вперед. API набагато ближче до інших мов, на яких я запрограмований. Інтерфейси бази даних OO, здається, працюють краще.

Я не натрапив на якісь особливості MySQL, які були недоступні через PDO. Я був би здивований, якби це колись зробив.

PDO також дуже повільний і його API досить складний. Ніхто з їх розумного розуму не повинен використовувати його, якщо портативність не викликає побоювань. І давайте зізнаємося, у 99% всіх веб-сайтів це не так. Ви просто дотримуєтесь MySQL або PostrgreSQL, або будь-чого, з чим ви працюєте.

Що стосується питання PHP та що враховувати. Я думаю, що передчасна оптимізація - корінь усього зла. ;) Почніть спочатку свою програму, постарайтеся зберегти її в чистоті, коли мова йде про програмування, зробіть невелику документацію та напишіть одиничні тести. З усього вищесказаного у вас не виникне проблем із кодом рефакторингу, коли настане час. Але спочатку ви хочете зробити це і виштовхнути його, щоб побачити, як люди на це реагують.

Звичайно PDO це добре, але там уже був якийсь - то суперечка про те, що це продуктивності по порівнянні з MySQL і MySQLi, хоча це , здається , тепер виправлена.

Ви повинні використовувати pdo, якщо передбачаєте портативність, але якщо ні, то mysqli має бути таким способом. Він має інтерфейс ОО, підготовлені заяви і більшість того, що пропонує pdo (крім, ну, портативність).

Плюс, якщо продуктивність дійсно потрібна, підготуйтеся до (рідного mysql) драйвера MysqLnd в PHP 5.3, який буде набагато більш тісно інтегрований з php, з кращою продуктивністю та покращеним використанням пам'яті (та статистикою для настройки продуктивності).

Memcache приємно, якщо у вас є кластеризовані сервери (і YouTube схожі на завантаження), але я спробував би також спробувати APC спочатку.

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

Крім того, якщо вам може знадобитися збалансування завантаження сервера вашої бази даних у майбутньому, MySQL Proxy цілком може допомогти вам досягти цього.

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

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

Продуктивність не має значення, якщо сайт недоступний. А для наявності потрібне горизонтальне масштабування. Мінімум, від якого ви можете розібратися - це 2 сервери, як запущені apache, php і mysql. Налаштуйте одну СУБД як підлеглий інший. Виконайте всі записи на майстрі та всі прочитані в локальній базі даних (що б там не було) - якщо тільки з якихось причин вам не потрібно перечитати дані, які ви тільки що прочитали (використовуйте master). Переконайтеся, що у вас є техніка для автоматичного просування рабовласників і забору господаря. Використовуйте DNS з круглим доступом для адрес веб-сервера, щоб надати більше спорідненості з веденим вузлом.

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

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

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

Використовуйте кеш оп-коду.

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

Натисніть якомога більше кешування на клієнта.

Використовуйте mod_gzip для стиснення всього, що можете.

C.

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

Взагалі простий - це швидко . Шаблони сповільнюють вас. Бази даних сповільнюють вас. Складні бібліотеки сповільнюють вас. Накладення шаблонів один на одного, витягування їх із баз даних та аналіз їх у складній бібліотеці -> часові затримки помножуються між собою.

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

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

@ Gary

Не використовуйте MySQLi - PDO - це «сучасний» рівень доступу до баз даних OO. Найважливіша функція, яку потрібно використовувати, - це заповнювачі у ваших запитах. Це досить розумно, щоб використовувати підготовку на сервері та інші оптимізації також.

На даний момент я переживаю PDO, і схоже, що ти маєш рацію - однак я знаю, що MySQL розробляє розширення MySQLd для PHP - я думаю, щоб досягти успіху або MySQL, або MySQLi - що ти думаєш про це?

@ Ryan , Eric , tj9991

Дякуємо за пораду щодо розширення кешування PHP - чи могли б ви пояснити причини використання один одного? Я чув чудові речі про приховані через IRC, але ніколи не чув про APC - що ви думаєте про них? Я вважаю, що використання декількох систем кешування є досить протидіючим ефектом.

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

Я не бачу, щоб незабаром переходити з MySQL - тому, мабуть, мені не потрібні можливості абстрагування PDO. Спасибі за ці статті DavidM, вони мені дуже допомогли.

Подивіться у mod_cache , кеш-вихід для веб-сервера Apache, аналогічний кеш-виводу в ASP.NET.

Так, я бачу, що це все ще експериментально, але це буде остаточним колись.

Я не можу повірити, що ніхто про це вже не згадував: Модулялізація та абстракція. Якщо ви думаєте, що вашому сайту доведеться розростатися до безлічі машин, ви повинні спроектувати його так, щоб він міг! Це означає дурні речі, як, наприклад, не припускайте, що база даних є на localhost. Це також означає, що спочатку вони будуть турбувати, як, наприклад, написання шару абстрагування бази даних (як PDO, але набагато легше, оскільки він робить лише те, що вам потрібно для цього).

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

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

Якщо ви працюєте з великою кількістю даних, а кешування не скорочує їх, подивіться у Sphinx. Ми мали чудові результати, використовуючи SphinxSearch не тільки для кращого пошуку тексту, але і як заміну пошуку даних для MySQL при роботі з більшими таблицями. Якщо ви використовуєте SphinxSE (плагін MySQL), це перевершило наші покращення в продуктивності, отримані від кешування декількох разів, а реалізація програми - це синхронізація.

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

Публікація "Порівняння продуктивності кешу" на блозі продуктивності MySQL містить цікаві орієнтири щодо цього питання - http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-compation/ .