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

Днес идвам да ви поговоря още веднъж за една от най-използваните уеб услуги в света: Уеб сървърът Apache2.

Това е тема, за която се говори много пъти, но сега идвам да ви разкажа за друга функция, която да вземете предвид при тази услуга: Границата на едновременните връзки. Няма значение дали имаме много елементарен или космически кораб с i7 процесор и 32 GB RAM ...

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

В този случай не е необходимо да инсталирате каквото и да е, всичко се основава на прости концепции, които трябва да се вземат предвид за конфигуриране на apache; концепции, които трябва да са много ясни, преди да искате да направите някакви промени.

apache2_logo

Първото нещо, за което трябва да помислим е: Какъв капацитет има моят екип? Колко едновременни връзки може да поддържа моето оборудване, ако го принудя колкото е възможно повече? Всичко това зависи от един фактор; RAM (памет с произволен достъп).

Колкото по-голяма е RAM паметта, толкова по-голям е броят на връзките, въпреки че няма фиксирана стойност (т.е. X клиенти за всеки X ram), ето защо на първо място е важно да се направят някои малки изчисления на нашия уеб сървър, с за да знаем нашите граници.

Първото нещо, което трябва да знаете е колко RAM консумира средно всяка връзка с Apache, тъй като всяка установена връзка предполага определена консумация на RAM в системата ... Очевидно не всички връзки консумират един и същ RAM, с който човек трябва да направи медия ... Всичко това може да се получи със следната команда:

ps -ylC apache2 --sort: rss | awk '{SUM + = $ 8; I + = 1} END {print SUM / I / 1024} '

Полученият резултат ще бъде представен в мегабайта и може да варира в зависимост от броя на активните връзки, вида на страниците, до които се осъществява достъп и т.н. ... Следователно е препоръчително да се извърши тестът с различни отворени раздели; всеки от тях показва различно съдържание, ако е възможно. В моя случай, например, резултатът е 9.5458, което ако го закръглим нагоре ще бъде 10 MB RAM, изразходван средно за връзка.

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

ps -N -ylC apache2 --sort: rss | awk '{SUM + = $ 8} END {print SUM / 1024}'

Полученият резултат също ще бъде представен в мегабайти и ще ни покаже доста точно количеството RAM, консумирано от останалите процеси; в моя случай 800 MB. С тази информация бихме могли да направим общо изчисление на броя едновременни връзки, които бихме могли да имаме; Изчислявам, че бихме получили чрез много проста операция.

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN

С тази формула в ръка, нека си представим, че имаме компютър с 4 GB RAM, тоест 4096 MB и че нашият компютър е показал гореспоменатите резултати; изчислението ще бъде:

(4096 - 800) / 10 = 329 едновременни връзки

Проблемът с това изчисление е, че един е твърде екстремен, тъй като би консумирал цялата RAM (кара сървъра да консумира суап), а също така, в случай на база данни, като MySQL или друга, връзките към нея също биха консумирали RAM , така че полученото число може да бъде квалифицирано като утопично число. Следователно, за да освободим паметта за възможни допълнителни процеси и също така да разгледаме възможността за изпълнение на връзки към база данни, бихме намалили броя на връзките до 250.

Сега, когато разполагаме с максималния си брой едновременни връзки, ще трябва да подготвим Apache, за да може да получи този номер, което се прави в конфигурационния файл на това обаждане apache2.conf, който се хоства в / и т.н. / apache2.

Въпросният файл следва структура, базирана на модули, всеки със съответното име, но бихме се интересували само от един от тях, чието име е  mpm_prefork_module. Въпросният модул има следните данни по подразбиране:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0

Този модул има серия от много важни параметри, въпреки че има един от тях, който би ни интересувал особено, наречен Maxclients. Този параметър определя максималния брой едновременни връзки и трябва да бъде променен на 250.

Една подробност, която трябва да имате предвид, е, че когато в споменатия параметър е посочена стойност, различна от стойността по подразбиране, е необходимо да добавите още една, ПРЕДИ тази. Този параметър се извиква ServerLimit и задава лимита на връзките, които сървърът може да „задържи“, дори когато е извън лимита.

Параметърът ServerLimit винаги трябва да бъде малко по-висок от MaxClients и тук, тъй като има малко пространство за маневриране, ограничение от 270. Това би накарало модула да изглежда така:

StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0

Сега би било необходимо само да рестартирате услугата Apache с помощта на командата: 

/etc/init.d/apache2 рестартиране

С това вече бихме могли да се насладим на нашия оптимизиран уеб сървър.

Поздрави.


22 коментара, оставете своя

Оставете вашия коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *

*

*

  1. Отговорен за данните: Мигел Анхел Гатон
  2. Предназначение на данните: Контрол на СПАМ, управление на коментари.
  3. Легитимация: Вашето съгласие
  4. Съобщаване на данните: Данните няма да бъдат съобщени на трети страни, освен по законово задължение.
  5. Съхранение на данни: База данни, хоствана от Occentus Networks (ЕС)
  6. Права: По всяко време можете да ограничите, възстановите и изтриете информацията си.

  1.   зетатино каза той

    Благодаря за публикацията!

    1.    Драсил каза той

      Радвам се, че го намерихте за полезен.

      Поздрави.

  2.   Мигел Анхел каза той

    Има начин да се групират Apache и два сървъра, можете ли да обясните как работи?

    1.    Драсил каза той

      Въпреки че съм чел някаква теория за това, никога не съм я прилагал на практика. И все пак, може би тази статия може да ви даде някои насоки в това отношение, въпреки че повтарям, че не съм имал възможност да я приложа на практика:

      http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/

    2.    Едуардо Джалил каза той

      Вие сте питали дълго време, ако не сте решили; Имам схема за балансиране с трета страна, която действа като файлова система, насочвате папките, които са в var / www / html / (в моя случай) към файловата система, така че те споделят една и съща информация и евентуално ще ви е необходим виртуален ip, който отговаря и пренасочвате към ips на apaches, за това можете да заемете хапрокси и ако го искате във висока наличност, можете да интегрирате keepalive в случай, че единият падне, другият продължава да отговаря или също така, ако вече имате домейн за приложението, можете да балансирате с паунд като правите бекендове към двата сървъра, за конкретни случаи, като например moodle или определени приложения, които се свързват с база данни в mysql, ще трябва да създадете потребител на сървър на приложения, който сочи към същата база данни.

  3.   шамару каза той

    Благодаря ви много за публикацията, напълно сте прав, RAM е основното изчисление, въпреки че си представям, че ние също така изчисляваме максималния брой процеси, с които може да се справи нашият процесор (разбира се, първо прави изчислението на основната памет) и как ще бъде разпределен диска твърд (Примерни дялове / var = 1TR).

    1.    Драсил каза той

      Прав си; всичко е важно, като контрол на температурата, наред с други неща. Очевидно мощният процесор може да изпълнява по-голям брой задачи едновременно с голяма ефективност, но целта на тази публикация беше да обясни значението на RAM по отношение на броя на едновременните връзки.

      Един добър начин да контролираме всички тези фактори и да видим дали нашият процесор не е наситен или имаме малко свободна RAM, би бил с помощта на bash скрипт. Може би тази публикация, която направих преди няколко дни за нея, е интересна за вас, която ви оставям в следния линк; Това е глобален мониторинг, но може да е интересен за един:

      http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html

      поздрави

  4.   Серджо С. каза той

    Много добра бележка, много благодаря!

    1.    Драсил каза той

      Благодаря много! Надявам се, че сте успели да се възползвате от него.

  5.   клоун каза той

    Не искам да бъда глупак ...
    ... Но увеличавайки броя на връзките, вие не оставяте по-уязвими към DDoS атака?

    1.    Драсил каза той

      Това не е спокоен кретинов въпрос. Истината е, че увеличавайки броя на едновременните връзки, ние отчасти укрепваме Apache срещу DDOS атаки, защото трябва да вземете предвид, че броят на максималните едновременни връзки, установени на сървъра, е броят на общия максимален брой връзки, а не тези, идващи от един потребител. По този начин, докато в началото можехме да поддържаме само 150 едновременни връзки (независимо дали са връзки от легитимен източник или не), сега можем да разчитаме на толкова, колкото поддържа нашият сървър, изисквайки по-голям брой връзки едновременно, за да бъдат без услуга. Очевидно е, че увеличаването на максималния брой връзки не е начин да се предпазите от този тип атака, а по-скоро ще трябва да приложите политики на защитната стена. Ако например уеб услугата, която искате да поставите, ще бъде изложена на интернет, мярка за сигурност, която може да бъде приложена, би била добавянето на тези редове към нашата защитна стена:

      iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-up до 10-m state –state NEW -j ACCEPT

      iptables -A INPUT -p tcp –dport 80 -m state –state УСТАНОВЕНО, СВЪРЗАНО -j ПРИЕМ

      iptables -A INPUT -p tcp –dport 80 -j DROP

      1.    Клоун каза той

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

    2.    Драсил каза той

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

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

      Поздрави.

  6.   eliotime3000 каза той

    Добре. Засега продължавам с NGINX на моя сайт, за да не измъчвам VPS, който имам.

  7.   Бруно Касио каза той

    Хубав пост @Drassill!

    Исках да допринеса с нещо може би по-статистическо от конфигурацията.
    Въпреки че най-лесният и бърз начин за изчисляване на параметъра на потребление е със средната стойност, може би бихме могли да бъдем по-строги и да използваме „средната стойност“ вместо „средната стойност“. От какво би ни спасило? Че номерата изчезват, в случай че дадена връзка е отнела много памет. Да предположим например, че следните клиенти консумират следните стойности в единицата памет, която искат (KB, MB, MiB и т.н.):

    10, 15, 150, 5, 7, 10, 11, 12

    Средното ще даде приблизително ~ 30

    И това защото имаме много голям край (150) и изчисленията са луди. Медианата се състои от подреждане на тези данни, разделяне на броя на пробите на 2 (нашият център) и след това получаване на номера на тази позиция. С това щяхме да имаме нещо подобно

    5, 7, 10, 10, 11, 12, 15, 150

    Така че средната ни стойност ще бъде: 8/2 = 4, което е ~ 10

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

    Това е само принос и е много спорен, тъй като с връзките не е прецакан.

    Прегърнете хора linuxera 🙂

  8.   Карлос каза той

    Здравейте, имах проблем на моя специализиран сървър и той е, че всеки път, когато броят на приблизително 250 души онлайн се приближава, според Google Analytics в реално време, сървърът ми като че ли се срива и връзката става бавна, докато не падне връзката към уебсайта и никога не качва повече от този брой потребители онлайн, но когато видя производителността на специалния сървър, който е 8gb ram, той показва 10% употреба, процесорът: 5% употреба и твърдия диск за: 1.99 % от употребата.
    Можеш ли да ми помогнеш? Не мога да намеря какво да правя, прави ли тези стъпки решението?

    1.    Драсил каза той

      Браво Карлос.

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

      Поздрави.

      1.    Карлос каза той

        Drassill, направих конфигурацията, която споменахте, и тя беше задоволителна, вчера достигнах до 280 потребители онлайн и сървърът не се мотае, много съм доволен от този резултат и искам да направя и другото нещо, което ми кажете, за да оптимизирам базата данни, ¿ Как да постигна това?

    2.    Драсил каза той

      Концепцията на базата данни е доста отворена; използването на mysql не е същото като postgres (например). Очевидно не знам всички бази данни; Опитах mysql и postgres и увеличаването на едновременните връзки в тях ще се основава на параметъра max връзки; mysql оптимизацията ще бъде направена в /etc/my.conf и параметърът за максимални връзки трябва да бъде променен (наред с други). Вместо това за postgres имам статия в моя блог, която обяснява как да я оптимизирате, която може да ви бъде полезна или която можете да използвате като справка за вашата база данни:

      http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html

      Поздрави.

  9.   Ериксон Васкес каза той

    Здравейте, когато хвърлям първата команда, тя ми показва стойност 0. Какво би могло да бъде?

  10.   Даниел Охеда каза той

    Благодаря ви за този пост.

  11.   Роландо Агилера Салазар каза той

    Какво добро ръководство, тази информация е част от това, което търся... благодаря!

    Но сега, ако искам, когато тези 250 посетители бъдат надвишени, посетител 251 да отиде на чакаща страница или виртуална опашка, мога ли да го направя от същата тази конфигурация?

    Поздрави и благодаря!