Оптимізуйте apache / php / mysql, що працює на VPS для великого навантаження

Питання про оптимізацію сервера apache / mysql на VPS з 512м оперативної пам’яті. При нормальному навантаженні все працює швидко, відставання в підключенні немає. Однак, коли ми отримуємо великі дні трафіку (50 тис. + Відвідувань), сайт проскакує і потрібно 30 секунд, щоб повернути контент з апачі.

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

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

Будь-які рекомендації?

Для PHP є дві важливі речі, які підвищують потужність:

1. Розширене керування PHP (APC), як було зазначено. Це те, що ми використовуємо в Yahoo !. Є й інші подібні проекти, але цей - дитина Расмуса.
2. FastCGI замість mod_php. Існує дискусія з цього питання, оскільки mod_php, як правило, найшвидший. Однак я б припустив, що у вас є один сервер Apache, який доставляє як динамічний вміст PHP, так і статичні активи (JS, CSS, flash, зображення, PDF та ін.). Запити для цих статичних активів не потребують стільки пам’яті, але оскільки PHP є модулем, він є у кожній потоці Apache.

Для Apache:

1. Використовуйте робочу MPM
2. Увімкнути KeepAlive

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

Для MySQL:

1. Ваші зусилля з оптимізації принесуть 10 разів, витрачаючи на аналіз і виправлення запитів, замість того, щоб налаштовувати значення my.cnf. Я не кажу, що правильне кешування, з'єднання тощо не має правильності ... але для більшості людей це лише 9% проблеми.
2. Під час QA увімкніть загальний журнал запитів на staging / dev mysqld, щоб зафіксувати всі надіслані запити. (НЕ робіть цього на своєму сервері виробництва mysql!)
3. Використовуйте EXPLAIN для аналізу запитів. Особливо, якщо ви використовуєте фреймворк з ORM (абстрагує БД і не дозволяє вам писати свій власний SQL), вам потрібно буде очистити сторонні приєднання, вибору без застереження "WHERE", ORDER BYs, що спонукають "використовувати fileort", і запити які не використовують індексів.
4. Якщо ви використовуєте MySQL 5.1, скористайтеся профілем запиту .

Інші інструменти, які варто розглянути, - це mk-visual-тлумачення

Я цитував 10 чудових довідок. Ці речі повинні змусити вас гудити. Будь ласка, дайте нам знати, як це виходить.

Перемістіть файли сеансів PHP до tmpfs , використовуйте APC (або інший) та видаліть усі модулі PHP, які вам не потрібні. Видаліть усі модулі Apache, які вам не потрібні / не користуються.

Створити tmpfs (каталог в оперативній пам'яті!)

mkdir /tmpfs; chmod 777 /tmpfs
mount -t tmpfs -o size=256M tmpfs /tmpfs

У / etc / fstab додайте рядок нижче, щоб створити його при перезавантаженні!

tmpfs     /tmpfs    tmpfs   size=256m,mode=0777    0       0

У /etc/apache2/php.ini налаштуйте, щоб зберігати свої сеанси в оперативній пам'яті (tmpfs)!

session.save_handler = files
session.save_path = "/tmpfs"

Примітка: З вашими PHP-файлами та файлами сеансу в оперативній пам'яті ви ледь торкаєтесь диска!

Використовуйте expires_module в apache, щоб браузери кешували більшість речей.

ExpiresActive On
ExpiresDefault "access plus 90 days"
ExpiresByType image/gif "access plus 90 days"
ExpiresByType image/ico "access plus 90 days"
ExpiresByType image/png "access plus 90 days"
ExpiresByType image/jpeg "access plus 90 days"
ExpiresByType image/x-icon "access plus 90 days"
ExpiresByType text/css "Access plus 90 days"
ExpiresByType text/html "Access plus 90 days"
ExpiresByType application/x-shockwave-flash "Access plus 90 days"
ExpiresByType application/x-javascript "Access plus 90 days"

Не використовуйте файли .htaccess ! Натомість жорсткий код їх у конфігураційному файлі vhost! Різко усуне / зменшить перевірку дисків на всі запити http ... це дійсно додається.

Options FollowSymLinks 
AllowOverride None

Приклад .htaccess, який використовується у вашому файлі vhost.conf ...

<Directory /home/user/www/site.com/secure>
    Order Allow,Deny
    Deny from All
</Directory>

Пару речей приходять на думку.

Кеш-код опкоду - це завжди хороша ідея. Я віддаю перевагу http://eaccelerator.net/ над APC. Якщо ви не розробляли APC по дорозі, намагаючись додати його, майже завжди боляче. Еакселератор, хоча і не такий фантазійний, здається, працює.

Зворотний проксі - також хороша ідея, але вам потрібно спостерігати за використанням оперативної пам'яті. Я знаходжу Apache 2.2 з mpm-працівником, щоб самостійно зайняти неабияку кількість оперативної пам'яті. У вашому випадку я рекомендую щось легше, як Nginx і запускати Apache з PHP як FASTCGI або просто залишити його відповідно до процесу. Ідея використання Varnish, Squid, Nginx тощо полягає в тому, щоб вони обслуговували статичний контент, працювали з підключеннями користувачів і передавали лише PHP-запити Apache, які ви розглядаєте як сервер додатків.

Якщо ви працюєте з досить недавньою версією Mysql 5.1, як-от принаймні 5.1.24, тепер у вас є доступ до нижчих секундних повільних журналів. Я б почав long_query_time з 1 або 2, а потім знизити його до 0,5, коли ви отримаєте ручку на дійсно довгі. Також в мережі є багато загальної інформації про настройку для Mysql, але оперативної пам'яті у вас немає, щоб зробити багато. Чи збільшили ви будь-який з параметрів за замовчуванням? Більшість файлів my.cnf налаштовані на використання близько 64 Мб оперативної пам’яті. Я, щонайменше, я підніс буфер key_buffer з 16MB до 64MB.

Додатково ви використовуєте таблиці Myisam або Innodb? Якщо ви ведете сеанс у БД, вам потрібно змінити таблицю сеансу на Innodb (або зробити її замість файлу cookie), а не залишити її таблицею Mysiam, яка робить блокування рівня таблиці, а не блокування рівня рядків. В основному будь-яка таблиця, яка записує більше 20% до 80% читань, є кандидатом на перехід до Innodb. Пам’ятайте, що вам потрібно буде збалансувати об'єм оперативної пам’яті між таблицями Myisam та таблицями Innodb, оскільки буфери для кожного налаштовані окремо.

І нарешті, ще 512 Мб оперативної пам’яті пройдуть довгий шлях у ваших налаштуваннях або навіть інший 512 МБ VPS для запуску Mysql, якщо це дешевше або приблизно однакова ціна. Я насправді схиляюся до другої інстанції, тому що це подвоїть доступний IO диска. Однією з проблем із серверами VPS є те, що ваш IO не захищений від інших людей на тому ж фізичному сервері.

Хммм, мій пост всілякі розсіяні, але дають вам багато місця для пошуку. Удачі.

• Використовуйте кеш-код опкоду для php, наприклад, apc.
• Використовуйте прискорювач http, наприклад, кальмар або лак.

У ситуації з низькою пам’яттю (512 Мб мало, для сервера з високим трафіком) варто врахувати свій вибір веб-сервера та двигуна БД.

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

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

Інший варіант, простий варіант, - отримати більше оперативної пам’яті у віртуальній машині, якщо ви можете собі це дозволити.

Крім чудових пропозицій тут, слід зазначити, що всі VPS 'не створюються рівними. На мій досвід, PHP виявився важким для процесора.

Бенчмарк Wordpress AB (ab -n 500 -c 25 http://domain.com/index.php ) nginx / apc / phpfpm / mysql (локальний) на EC2 призвів до ~ 2 запитів / секунди на їх початковому рівні "2 Гб Оперативна пам'ять / 1 сервер обчислювальних блоків ".

Один і той же Бенчмарк працює проти того ж точного стека (розгорнутий за сценарієм в ідентичну ОС) на 512 Мб Rackspace Cloudserver повертається ~ 80 рек / с. Тож в 4 рази менше оперативної, 40-кратної продуктивності в цьому рудиментарному експерименті.

Переглядаючи верхню частину AB під час AB, ви бачите, що EC2 просто не впорався з одночасністю, і негайно вдарив би на 100% завантаження процесора та замикався. Переглядаючи вершину на сервері 512 МБ (віртуалізований чотирьохядерний процесор) за тією ж орієнтиром, Ядра вдарять ~ 60% Навантаження та плавно керують еталоном.

VPS надзвичайно легко розгортатись та вимикатись без будь-яких зобов'язань, це не завадить поставити інфраструктуру, у якій знаходиться VM / VPS.

EDIT 1: Крім того, малий екземпляр EC2 "High CPU" мав змогу отримати лише ~ 10 / req секунди, CPU все ще є вузьким місцем. Мій висновок полягав у тому, що ви жертвуєте продуктивністю заради стабільності / надійності за допомогою EC2, і, звичайно, є багато випадків використання, які вимагають такого середовища.