Официальный сайт движения «Москва без Лужкова!»
Главная Новости Москвы Наши новости Популярное
  • Новости
  • Новости
  • ВХОД В ЛИЧНЫЙ КАБИНЕТ
    логин
    пароль
       
      Где купить переходник на фотоаппарат

      Я решила попробовать заработать в интернете на фотографиях, и приобрела хороший фотоаппарат. Спустя некоторое время я захотела снимать мелкие объекты, например песчинки песка или капельки воды. Но

      Уборка квартир в москве
      Проф уборка квартир в москве позволяет не беспокоиться о кавардаке, который повстречает Вас либо Вашу вторую половинку. Если Вы закатывали гулкую вечеринку, а на утро остались совершенно одни, то конкретно

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

    Новости

    Оптимізація продуктивності веб-сервера Apache

    1. Завантажуйте тільки необхідні модулі
    2. Виберете відповідний MPM
    3. DNS lookup
    4. AllowOverride
    5. FollowSymLinks і SymLinksIfOwnerMatch
    6. Content Negotiatio
    7. MaxClients
    8. MinSpareServers, MaxSpareServers, і StartServers
    9. MaxRequestsPerChild
    10. KeepAlive і KeepAliveTimeout
    11. стиснення
    12. Кешування на стороні клієнта

    Apache - популярний веб-сервер в інтернет, він обслуговує безліч серверів і сайтів. Часто виникає необхідність збільшити продуктивність веб-сервера. напевно кращий спосіб це зробити - перейти до схеми frontend + backend, але це може зажадати досить серйозних змін в додатку (наприклад, у вас напевно відваляться всілякі індикатори прогресу аплоаду файлів :).

    інший спосіб - просто збільшити продуктивність сервера - поставити більш швидкий процесор і більше пам'яті.

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

    Завантажуйте тільки необхідні модулі

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

    Запускайте apache тільки з необхідними модулями, щоб зменшити споживання пам'яті. Якщо ви вирішили скомпілювати apache самостійно, то або ретельно підходите до вибору списку модулів, які ви включите, або компілюйте їх як DSO використовуючи apxs в apache1 і apxs2 в apache2. Для того щоб відключити непотрібні DSO-модулі, досить закомментировать зайві рядки LoadModule в httpd.conf. Apache зі статично скомпільованими модулями буде споживати трохи менше пам'яті, проте вам доведеться кожного разу його перекомпіліровать для зміни списку модулів.

    Виберете відповідний MPM

    У apache кожен запит обробляється в своєму процесі або потоці. При компіляції apache дозволяє вибирати один з кількома MPM (Multi-processing module), які відповідають за прослуховування портів, прийом запитів і роздачу цих запитів дочірнім процесам або потокам, в яких ці запити будуть оброблені.

    Вибір MPM залежить від декількох факторів, таких як наявність підтримки потоків в ОС, кількості вільної пам'яті, а також вимог стабільності і безпеки.

    Якщо безпека дуже важлива, слід вибрати peruser MPM, пожертвувавши продуктивністю.

    Якщо важлива саме продуктивність, то вибір обмежується двома mpm: prefork і worker.

    Worker - потоковий MPM, тобто в ньому кожен запит обслуговується в окремому потоці одного з дочірніх процесів. Потоки - легші для ОС об'єкти, ніж процеси, вони більш ефективно використовують пам'ять і перемикання контексту для них відбуваються швидше. Однак, через те що кожен потік має доступ до всієї пам'яті процесу, worker mpm більш схильний до збоїв: збій одного потоку може спричинити падіння всього процесу, в якому знаходився цей потік (саме тому worker mpm запускає кілька дочірніх процесів з декількома потоками в кожному).

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

    На жаль, для зміни mpm потрібно перекомпіляція apache. Тут проявляють свої переваги source-based дистрибутиви: ви можете легко переконфігурувати apache і всіх залежних від нього пакети, які не перетворивши систему в смітник. Бінарні дистрибутиви виходять з цієї ситуації по-різному. Наприклад в RHEL в apache rpm знаходиться відразу дві версії apache - з worker і prefork mpm (prefork використовується за умовчанням). Однак worker mpm не підтримує php. Так що якщо ви хочете php і worker mpm вам доведеться компілювати його самостійно або шукати сторонні репозиторії.

    DNS lookup

    Директива HostnameLookups включає reverse DNS запити, так що в логи потраплятимуть dns-хости клієнтів замість ip-адрес. Зрозуміло, що це істотно сповільнює обробку запиту, тому що запит не обробляється поки не буде отримає відповідь від DNS-сервера. Тому стежте щоб ця директива завжди була вимкнена (HostnameLookups Off), а якщо вам все-таки потрібні dns-адреси, ви можете дізнатися їх пізніше, прогнавши лог в утиліті logresolve (яка поставляється з apache).

    Крім того, стежте щоб в директивах Allow from і Deny From використовувалися ip-адреси а не доменні імена. Інакше apache робитиме два dns запиту (зворотний і прямий) щоб переконатися що клієнт-той за кого себе видає.

    AllowOverride

    Якщо директива AllowOverride не встановлена ​​в 'None', apache намагатиметься відкрити .htaccess файли в кожній директорії яку він відвідує і у всіх директоріях вище неї. наприклад:

    DocumentRoot / var / www / html
    <Directory / var / www / html />
    AllowOverride all
    </ Directory>

    Якщо буде запропоновано ввести відповідний /index.html, apache спробує відкрити (І інтерпретувати) файли /.htaccess, /var/.htaccess, /var/www/.htaccess, і /var/www/html/.htaccess. Це збільшує час обробки запиту. Так що, якщо вам потрібен .htaccess тільки для однією директорії, дозволяйте його тільки для неї:

    DocumentRoot / var / www / html
    <Directory />
    AllowOverride None
    </ Directory>
    <Directory / var / www / html />
    AllowOverride all
    </ Directory>

    FollowSymLinks і SymLinksIfOwnerMatch

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

    Крім того, додаткові системні запити потрібні коли FollowSymlinks НЕ ВСТАНОВЛЕНО. Т.ч. найбільш оптимальна ситуація для продуктивності - коли опція FollowSymlinks включена.

    Content Negotiatio

    Намагайтеся уникати content negotiaion.

    MaxClients

    Директива MaxClients встановлює максимальну кількість паралельних запитів, які буде підтримувати сервер. Apache НЕ буде породжувати більше процесів / потоків ніж MaxClients. Значення MaxClient НЕ долно бути занадто маленьким (інакше багато клієнтів залишаться необслуженной), але і не варто встановлювати занадто велику кількість - краще НЕ обслужити частину клієнтів ніж вичерпати всі ресурси, залізти в своп і померти під навантаженням. Хорошим може бути значення MaxClients = кількість пам'яті виділене під веб-сервер / максимальний розмір породженого процесу або потоку. для статичних файлів apache використовує близько 2-3 Мб на процес, для динаміки (php, cgi) - залежить від скрипта, але зазвичай близько 16-32 Мб.

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

    MinSpareServers, MaxSpareServers, і StartServers

    Оскільки створення потоку, і особливо процесу - дорога операція, apache створює їх заздалегідь. Директиви MaxSpareServers і MinSpareServers встановлюють як багато процесів / потоків повинні очікувати в готовності прийняти запит (максимум і мінімум). Якщо значення MinSpareServers занадто маленьке і несподівано приходить багато запитів, apache змушений буде створювати багато нових процесів / потоків, що створить додаткове навантаження в цій стресовій ситуації. З інший боку, якщо MaxSpareServers занадто велике, apache буде сильно навантажувати систему цими процесами, навіть якщо кількість клієнтів мінімально.

    Постарайтеся встановити такі MinSpareServers і MaxSpareServers, щоб apache не створював більше 4 процесів / потоків в секунду. Якщо він створить більш 4, в ErrorLog буде надруковано повідомлення про це. Це - сигнал того що MinSpareServers занадто мало.

    MaxRequestsPerChild

    Директива MaxRequestsPerChild встановлює скільки запитів може обробити один дочірній процес / потік перш ніж він буде завершений. За замовчуванням значення цієї директиви встановлено в 0, що означає що одного разу створений процес / потік не буде завершено ніколи (ну крім випадків зупинки сервера або краху цього процесу / потоку). Рекомендую встановити MaxRequestsPerChild рівне якомусь досить великій кількості (кілька тисяч). Це не створить зайвого навантаження, пов'язаної з тим що apache буде змушений створювати нові дочірні процеси, в той же час це допоможе позбутися від проблем з витоком пам'яті в дочірніх процесах (що дуже можливо наприклад якщо ви використовуєте нестабільну версію php).

    KeepAlive і KeepAliveTimeout

    KeepAlive дозволяє робити кілька запитів в одному TCP-підключення. Це особливо корисно для html-сторінок з великою кількістю зображень. Якщо KeepAlive встановлений в Off, то для самої сторінки і для кожного зображення буде створено окреме підключення (яке потрібно буде обробити master-процесу), що погано і для сервера і для клієнта. Так що для подібних випадків рекомендується встановлювати KeepAlive в On. Для інших застосувань (наприклад для download-сервера) KeepAlive може бути потрібен і навіть шкідливий, тому що при включеному KeepAlive сервер закриває з'єднання не відразу, а чекає KeepAliveTimeout секунд нового запиту. Для того щоб процеси не висіли занадто довго в непотрібному очікуванні, встановлюйте KeepAliveTimeout досить малим, близько 5-10 секунд зазвичай достатньо.

    стиснення

    HTTP-стиснення було визначено в стандарті HTTP / 1.1, і зараз всі сучасні клієнтські програми і практично всі сервера його підтримують. сервер може віддавати відповідь в gzip або deflate, а клієнтська програма непомітно для користувача розтискає дані. Це зменшує кількість переданого трафіку (до 75%), але звичайно ж підвищує використання процесора.

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

    Кешування конфигурируется директивами модуля mod_deflate. Майте на увазі, що не слід встановлювати ступінь стиснення gzip більше 4-5 - це зажадає істотно більшого часу CPU, а ефект буде досить невеликий. Ну і зрозуміло не потрібно намагатися стиснути зображення в jpg, gif та png, музику, відео файли і всі інші бінарні файли, які вже і так добре стиснуті.

    Кешування на стороні клієнта

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

    Відмінна стаття, передрукував з сайту Highload Web .

    Ще записи по темі


     

    Найди свой район!

    Восточный

    Западный

    Зеленоградский

    Северный

    Северо-Восточный

    Северо-Западный

    Центральный

    Юго-Восточный

    Юго-Западный

    Южный

    Поиск:      


     
    Rambler's Top100
    © 2007 Движение «Москва без Лужкова!»