Оптимизация на производителността на уеб сървъра на Apache
Бележки относно конфигурирането на Debian Ubuntu и Microsoft Windows
Apache е популярен уеб сървър в Интернет и хоства много сървъри и уебсайтове. Често има нужда от увеличаване на производителността на уеб сървър. Вероятно най-добрият начин да направите това е да преминете към схемата frontend+backend, но това може да изисква доста сериозни промени в приложението (например вероятно ще загубите всякакви индикатори за прогрес на качване на файлове :).
Друг начин е просто да увеличите производителността на сървъра - сложете по-бърз процесор и повече памет.
И първото, и второто обаче изискват много време и ресурси, така че за първи път можете да опитате да ускорите apache, като оптимизирате конфигурацията му. Има оптимизации, които могат да се прилагат само при повторно изграждане на apache, докато други могат да се прилагат без повторно компилиране на сървъра.
Заредете само модулите, от които се нуждаете
Apache е модулна програма, като по-голямата част от нейната функционалност е реализирана в модули. В същото време тези модули могат да бъдат както компилирани, така и асемблирани под формата на DSO - динамични библиотеки. Повечето съвременни дистрибуции доставят apache с набор от DSO, така че модулите, от които не се нуждаете, могат лесно да бъдат деактивирани без повторно компилиране.
Изберете правилния MPM
В apache всяка заявка се обработва в собствен процес или нишка. Когато компилирате, apache ви позволява да изберете един от няколко MPM (Мултипроцесорен модул), които са отговорни за слушане на портове, приемане на заявки и разпространение на тези заявки към дъщерни процеси или нишки, в които тези заявки ще бъдат обработени.
Изборът на MPM зависи от няколко фактора, като например наличието на поддръжка на нишки в операционната система, количеството свободна памет, както и изискванията за стабилност исигурност.
Ако сигурността е много важна, трябва да се избере MPM за потребителя за сметка на производителността.
Ако производителността е важна, тогава изборът е ограничен до две mpm: prefork и worker.
Worker - MPM с резба, т.е. в него всяка заявка се обслужва в отделна нишка на един от дъщерните процеси. Нишките са по-леки обекти за ОС от процесите, те използват паметта по-ефективно и контекстните превключвания за тях са по-бързи. Въпреки това, тъй като всяка нишка има достъп до цялата памет на процеса, mpm работникът е по-податлив на сривове: повредата на една нишка може да доведе до срив на целия процес, който е бил в тази нишка (поради което mpm работникът стартира множество дъщерни процеси с множество нишки всеки).
Perfork - mpm използва множество дъщерни процеси, всеки дъщерен процес обработва една връзка. Тъй като процесът е по-тежка структура, той използва малко повече ресурси, но е по-малко склонен към сривове - обработката на всяка отделна заявка не зависи от други процеси.
За съжаление, промяната на mpm изисква повторно компилиране на apache. Тук идват дистрибуциите, базирани на източника: можете лесно да прекомпилирате apache и всички негови зависими пакети, без да превръщате системата в дъмп. Двоичните дистрибуции се справят с тази ситуация по различни начини. Например, в RHEL, apache rpm съдържа две версии на apache наведнъж - с worker и prefork mpm (prefork се използва по подразбиране). Въпреки това работният mpm не поддържа php. Така че, ако искате php и worker mpm, ще трябва да го компилирате сами или да потърсите хранилища на трети страни.
DNS търсене
позволи отмяна
Ако директивата AllowOverride не е зададена на „Няма“, apache ще се опита да отвори.htaccess файлове във всяка директория, която посещава, и във всички директории над нея. Например:
DocumentRoot /var/www/html AllowOverride all
Ако се поиска /index.html, apache ще се опита да отвори (и интерпретира) файловете /.htaccess, /var/.htaccess, /var/www/.htaccess и /var/www/html/.htaccess. Това увеличава времето за обработка на заявката. Така че, ако имате нужда само от .htaccess за една директория, разрешете го само за тази директория:
DocumentRoot /var/www/html AllowOverride Няма AllowOverride всички
Следвайте SymLinks и SymLinksIfOwnerMatch
Освен това са необходими допълнителни системни извиквания, когато FollowSymlinks НЕ е ЗАДАДЕНО. Че. Най-оптималната ситуация за производителност е, когато опцията FollowSymlinks е активирана.
Договаряне на съдържанието
Опитайте се да избягвате преговорите по съдържанието.
MaxClients
Директивата MaxClients задава максималния брой едновременни заявки, които сървърът ще поддържа. Apache няма да генерира повече процеси/нишки от MaxClients. Стойността на MaxClient не трябва да е твърде малка (в противен случай много клиенти ще останат необслужвани), но не трябва да се задава твърде висока - по-добре е да не обслужвате някои клиенти, отколкото да изчерпите всички ресурси, да влезете в суап и да умрете под натоварване. Добра стойност може да бъде MaxClients = количеството памет, разпределено за уеб сървъра / максималния размер на създаден процес или нишка. За статични файлове apache използва около 2-3 MB на процес, за динамични (php, cgi) зависи от скрипта, но обикновено около 16-32 MB.
Ако сървърът вече обслужва заявки за 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, тогава ще бъде създадена отделна връзка за самата страница и за всяко изображение (което ще трябва да бъде обработено от главния процес), което е лошо както за сървъра, така и за клиента. Така че за такива случаи се препоръчва да зададете KeepAlive на On. За други приложения (например за сървър за изтегляне) KeepAlive може да бъде безполезен и дори вреден, защото когато KeepAlive е активиран, сървърът не затваря връзката веднага, а изчаква KeepAliveTimeout секунди за нова заявка. За да предотвратите висене на процеси твърде дълго в безполезно чакане, задайте KeepAliveTimeout сравнително ниско, около 5-10 секунди обикновено са достатъчни.
HTTP компресията е дефинирана в стандарта HTTP/1.1 и сега всички модерни клиентски програми и почти всички сървъри я поддържат. Сървърът може да даде отговор в gzip или deflate, а клиентската програма декомпресира данните незабележимо за потребителя. Това намалява обема на предавания трафик (до 75%), но разбира се увеличава използването на процесора.
Въпреки това, ако вашият сървър се посещава от много клиенти с бавни връзки, компресията може да намали натоварването на вашия сървър, тъй като сървърът може да изпрати компресирания отговор по-бързо и да освободи ресурси, заети от дъщерния процес. Този ефект може да бъде особено забележим, ако имате бърз процесор, но малко памет.
Кеширане от страна на клиента
Не забравяйте да зададете заглавки Expires на статични файлове (вижте модула mod_expires). Ако файлът не се промени, винаги трябва да се опитвате да го кеширате на клиента. Тогава клиентът ще зарежда страници по-бързо и сървърът ще бъде освободен от ненужни заявки.