Поради щодо продуктивності сервера LAMP [закрито]

Які поради щодо ефективності можна запропонувати тому, хто працює на сервері LAMP?

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

Це дійсно залежить від вашої завантаженості.

• для L частини

  • отримати багато пам’яті,
  • якщо ви можете перейти на 4 Гб, перейдіть на 64 біт.
  • для розділів, де ваш вміст, журнали та дані MySQL використовують параметри кріплення: noatime, nodiratime.
  • використовуйте окремі фізичні накопичувачі / набори рейдів, в ідеалі зберігайте дані SQL, журнали, вміст, який ви обслуговуєте - кожен на окремому шпинделі.

• для A частини вашого стека - ну, можливо, ви хочете повністю замінити його на nginx або lighthttpd , а може просто залишити Apache для динамічного контенту і мати окремий сервер (як ці два або mathopd ) для статичного вмісту. Подивіться тут, щоб отримати більше варіантів. Якщо ви збираєтеся запускати і Apache, і інший сервер у тому самому полі, 2-а IP-адреса буде корисною. Щоб зменшити затримку для кінцевого користувача, використовуйте http / 1.1 з підтримкою "Keep-Live". Подумайте про використання CDN для статичного вмісту.

• для M частини лампи - подивіться на mysqlperformanceblog . зверху голови:

  • журнал повільних запитів,
  • дайте достатньо пам'яті,
  • розглянути можливість використання innodb.
  • якщо у вас є багато тексту для пошуку - використовуйте сфінкс та отримайте пакетну роботу, яка відновлює індекс.
  • розглянемо запити щодо вбивства, які тривають довше XYZ секунд. Краще засмутити 1% користувачів, ніж звести весь сайт в самий пік. Але це дійсно залежить, якщо ви обробляєте касові операції чи показуєте приємні фотографії.
  • використовуйте memcached, якщо можете, для кешування результатів більш "дорогих" SQL-запитів. Майте на увазі, що ви не можете визначити кеш-пам'ять при зміні вмісту SQL. З іншого боку, у мене досить мало сайтів, де всі дані зручно вписуються в пам’ять, і для цього MySQL швидко палає, і немає необхідності в додатковому кеші.

• для П

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

Насправді не підказка щодо ефективності, але робити резервні копії за межами місця. Дійсно.

Я дійсно пропоную розділити MySQL та Apache / PHP на двох різних машинах.

Наприклад, у мене була одна машина (C2D E6600), яка завжди досягала 2,0 і вище середнього навантаження. Я поставив MySQL на другу машину (P4C 3Ghz) і після цього обидва середні показники навантаження не перевищували 0,2-0,3. Тому я перейшов від дуже повільного сайту до швидкого сайту з двома серверами, що мають велику ефективність.

Щодо P частини, ви можете розглянути кешування опкоду за допомогою APC . Можна також розглянути mod_fastcgi з php замість типового mod_php.