Как да оптимизирате производителността на уеб сървъра на Apache

Състояние: Отхвърлено

Тази статия обхваща версия на Ubuntu, която вече не се поддържа. Ако в момента работите със сървър, работещ с Ubuntu 12.04, горещо препоръчваме да надстроите или мигрирате към поддържана версия на Ubuntu:

Причина: Ubuntu 12.04 достигна края на живота (EOL) на 28 април 2017 г. и вече не получава корекции или актуализации за сигурност. Това ръководство вече не се поддържа.

Вижте вместо това: Това ръководство все още може да бъде полезно като справка, но може да не работи с други версии на Ubuntu. Ако е налично, силно препоръчваме да използвате ръководство, написано за версията на Ubuntu, която използвате. Можете да използвате функцията за търсене в горната част на страницата, за да намерите по-нова версия.

Въведение

Apache е невероятно мощен и способен уеб сървър. За да направи първоначалната настройка възможно най-лесна, той идва с множество предварително инсталирани модули. Това го прави чудесен избор за нови проекти, когато трябва бързо да сте продуктивни. С разрастването на вашия сайт обаче може да започнете да се сблъсквате с проблеми с производителността.

Това, което първо ме привлече в DigitalOcean, беше ниската цена за започване. Най-малките и най-евтините капчици имат 512 MB RAM, което не изглежда много в днешния свят на големи рамки. Въпреки това ще се изненадате какво можете да направите с малък сървър като този, ако отделите малко време, за да промените настройките.

Ако използвате Apache на един от по-малките размери на капчици или ако искате да увеличите максимално ефективността си на по-големите капки, ето няколко неща, които трябва да направите. Ще използвам Ubuntu 12.04 в примерите, но принципите, които демонстрирам, са приложими и за други версии на Linux.

Разтоварване на ненужни модули

В системи, базирани на Ubuntu и Debian, ще видите папка, наречена /etc/apache2/mods-enabled, и папка, наречена /etc/apache2/mods-available/. Папката mods-available е списък на всички модули, инсталирани на определен сървър, а mods-enabled е модулите, които са активни в момента.

На моя VPS имам 17 активни модула по подразбиране. Това е твърде много и повечето не са необходими за моето приложение. За съжаление модулите, от които се нуждаете, може да не са точно ясни, защото някои са зависимости от други.

Това, което предлагам да направите, е да направите списък на всички активни в момента модули и да го запазите за бъдещи справки, в случай че трябва да се върнете обратно. След това просто деактивирайте модулите един по един и рестартирайте вашия Apache след всяка промяна, за да видите дали възникват грешки.

В Ubuntu и Debian деактивирате модул с командата (използвайки autoindex като пример):

sudo a2dismod autoindex

Някои модули, които са особено гладни за ресурси, които трябва да деактивирате, ако не ви трябват са:

PHPSSLRewritePerlPythonRack / Ruby / Passenger

Няколко от тези модули не са активирани по подразбиране, така че може да не сте ги активирали, а в някои случаи те са активирани, защото наистина имате нужда от тях.

Бърза бележка за „пренаписване“: Често този модул е ​​активиран, когато модулът „псевдоним“ всъщност би работил еднакво добре. Ако можете да се справите с псевдоним, тогава деактивирайте пренаписването. Rewrite е един от най-натоварващите модули, но също така дава на Apache някои забележителни сили.

Превключването от „пренаписване“ към „псевдоним“ е тема за напреднали (с малко полезна документация) Въпреки това, дори ако не можете да изключите напълно пренаписването, но можете да конвертирате някои от вашите правила за пренаписване в псевдоними, ще спечели предимство.

След като деактивирате модул и презаредите конфигурацията на Apache, можете да проверите регистъра за грешки на Apache за съобщения. В Ubuntu и Debian проверете /var/log/apache2/error.log.

Получавам грешка, която изглежда така:

Синтактична грешка на ред 6 на /etc/apache2/sites-enabled/site1:Невалидна команда „DAVLockDB“, може би неправилно изписана или дефинирана от модул, който не е включен в конфигурацията на сървъра. Действието „configtest“ е неуспешно.

Това означава, че модулът I беше необходим просто деактивиран. В този случай модулът беше dav_fs, така че просто го активирам отново с:

sudo a2enmod dav_fs

След това рестартирах Apache и потърсих следващата грешка. Може да отнеме няколко опита, преди да подредите минималния списък. Бъдете търпеливи, струва си.

Преместете кода извън Apache

Ако работите с PHP сайт, шансовете са големи да използвате известния mod_php. Ако управлявате Ruby сайт, лесното решение е Passenger Phusion, известен още като mod_rails или mod_rack.

Проблемът с това е, че C кодът за интерпретатора за този език е вграден в Apache, като по този начин се използва повече памет при всеки преглед на страница. Ако популярна страница на вашия сайт причини 30 HTTP заявки, една от тях ще бъде за динамичната страница, а останалите 29 вероятно са за статични ресурси като изображения, css и javascript. Защо да използвате раздут Apache за тези 29 заявки, които не обслужват никакво динамично съдържание?

Разликата може да бъде драматична. Активирането на mod_php може да го накара да използва над 100MB RAM за всеки дъщерен процес на Apache! Като се има предвид, че по подразбиране вашият Apache сървър може да има 25 или повече работещи процеса, можете да разберете защо това може да се превърне в проблем.

Ето някои инструменти, които можете да използвате, за да направите това:

Недостатък на извършването на тази промяна е, че е по-трудно нещата да работят първоначално. В някои случаи документацията е много добра. В други случаи, кашлица php-fpm кашлица документацията е оскъдна.

Обикновено това, което се случва, е, че се стартира специален сървърен процес за PHP, Python или Ruby, след което Apache, вместо инстинктивно да знае как да се справи с тези заявки чрез вграден код, просто препраща извикването за динамично съдържание към този бекенд процес.

Ще се изненадате колко голяма е разликата. След премахването на mod_php от моя виртуален сървър, размерът на моите Apache процеси премина от 90-120MB всеки до под 10MB. Успях да обслужвам цялото си динамично съдържание само с два php backend процеса, които използваха само 60MB всеки.

Ограничаване на броя процеси и деца на Apache

Повечето конфигурации на Apache по подразбиране на операционни системи не са подходящи за по-малки сървъри – често се срещат 25 дъщерни процеса или повече. Ако всеки от вашите дъщерни процеси на Apache използва 120 MB RAM, тогава вашият VPS ще се нуждае от 3 GB само за Apache.

Уеб браузърът на един посетител може да поиска 4 елемента от уебсайта наведнъж, така че само 7 или 8 души, които се опитват да заредят страница едновременно, вашият облачен сървър може да се претовари. Това кара уеб страницата да виси в състояние на постоянно зареждане за нещо, което изглежда като цяла вечност.

Често се случва сървърът да поддържа тези мъртви Apache процеси активни, опитвайки се да обслужва съдържание дълго след като потребителят се е отказал, което намалява броя на процесите, налични за обслужване на потребителите, и намалява количеството налична системна RAM. Това причинява това, което е известно като низходяща спирала, която завършва с лошо преживяване както за вас, така и за посетителите на вашия сайт.

Това, което трябва да направите, е да разберете колко RAM се нуждае от вашето приложение, след това да разберете колко остава и да разпределите по-голямата част от това на Apache.

Например, ако имате три php-fpm процеса, обработващи динамично съдържание и всеки може да използва до 70MB RAM, а вашият MySQL сървър може да използва до 120MB RAM, това комбинира общо 330MB, използвани от приложение. Това ви позволява да разпределите около 150MB за Apache.

Докато Apache работи, отворете горната команда на сървъра. Ще поставя малко от това, което ще видите, като отрежа повечето от редовете, които не са уместни:

топ -bn 1PID USERPRNIVIRTRESSHR S %CPU %MEMTIME+COMMAND[...]15015 www-data20 0232m 9644 1900 S0.01.6 0:00.02 apache215016 www-data20 0232m 9644 1900 S0.01.6 0:00.01 apa che215017 www-data20 0232m 9644 1900 S0.01.6 0:00.02 apache2

Забележете колоната RES за дъщерен процес на Apache и отбележете неговата RES стойност. Например, на моя виртуален сървър, който е добре оптимизиран, стойността е 9644, което означава, че използва не съвсем 10MB RAM. Ако огранича Apache до максимум 15 дъщерни процеса, тогава той трябва да достигне максимум около 150 MB RAM.

Редактирайте конфигурационния файл apache на вашия облачен сървър, който в Ubuntu и Debian е /etc/apache2/apache2.conf и намерете раздела за конфигурацията на mpmpreforkmodule. Потърсете реда MaxClients и го задайте на 15, след това запазете и рестартирайте Apache.

Ето пример за това, което ще търсите в Ubuntu:

StartServers3MinSpareServers 3MaxSpareServers 5MaxClients 30MaxRequestsPerChild 0

Виждате ли реда MaxClients там? Трябва да променим тази стойност на по-ниско число.

Ако вашият VPS се претовари и достигне максималния брой клиенти, които може да обслужва наведнъж, той ще обслужва тези и други потребители просто ще получат бърз отказ. След това могат да презаредят страницата и може би ще имат по-голям успех при втория опит.

Това звучи зле, но повярвайте ми, много по-добре е тези връзки да се затварят бързо, но да оставите сървъра в здраво състояние, вместо да виси отворен цяла вечност. Изненадващо можете да получите по-добра производителност от сървър, който има по-малко дъщерни процеси, но отговаря по-бързо, отколкото да имате сървър с повече дъщерни процеси, които не може да обработи.

В конкретния случай, сайт на Wordpress, който управлявам, се хоства на 1GB капка с помощта на 4 php-fpm процеса и може да обслужва над 950 едновременни потребители наведнъж. Това означава пиков капацитет от около 42 милиона показвания на страници на ден, ако този уебсайт някога стане достатъчно популярен!

Помислете за алтернативна конфигурация на MPM

Повечето конфигурации на Apache исторически са използвали prefork mpm, който е безопасен за нишки и следователно е подходящ за използване с PHP и други вградени езици.

Ако се отървете от външни модули като PHP или Rails, тогава можете да помислите за работния MPM, който често е по-бърз от prefork.

За да активирате работния модул, трябва да го инсталирате.

sudo apt-get install apache2-mpm-worker

Което ще ви покаже съобщение като това:

Следните пакети ще бъдат ПРЕМАХНАТИ: apache2-mpm-prefork libapache2-mod-php5 Ще бъдат инсталирани следните НОВИ пакети: apache2-mpm-worker0 надстроен, 1 новоинсталиран, 2 за премахване и 2 ненадстроени. Трябва да получите 2284 B архиви .След тази операция ще бъдат освободени 8718 kB дисково пространство. Искате ли да продължите [Y/n]?

Внимателно обърнете внимание, че в Ubuntu, ако инсталирате работния mpm, той ще деинсталира prefork mpm и ще деинсталира mod_php и други несъвместими допълнителни модули.

Тук обсъдихме четири оптимизации, които можете да направите на Apache, които трябва значително да подобрят производителността на вашето приложение, дори ако имате малък капчица.

Настоятелно препоръчвам да изпробвате това на тестова капчица, а не на вашия производствен сървър. Красотата на услугата на DigitalOcean е, че можете да завъртите нов дроплет точно за времето, необходимо за тестване на промените, и да го изключите, когато сте готови. С почасово таксуване това е нискорисков и евтин начин да намерите идеалната конфигурация за вашия VPS.

Изпратено от: Матю Нузум