Hvordan øke samtidige tilkoblinger i Apache

I dag kommer jeg for å snakke med deg enda en gang om en av de mest brukte webtjenestene i verden: webserveren Apache2.

Det er et tema det har blitt snakket om mange ganger, men nå kommer jeg for å fortelle deg om en annen funksjon som du må ta hensyn til med denne tjenesten: Grensen for samtidige tilkoblinger. Det spiller ingen rolle om vi har veldig grunnleggende eller et romskip med en i7-prosessor og 32 GB ram ...

Grensen for samtidige tilkoblinger vil alltid være den samme med mindre vi tar de riktige tiltakene, noe som betyr at hvis vi vil ha mange mennesker tilkoblet samtidig, vil vi ikke bare kreve god maskinvare, men også en god konfigurasjon.

I dette tilfellet er det ikke nødvendig å installere noe, alt er basert på enkle konsepter som må tas i betraktning for å konfigurere apache; konsepter som må være veldig tydelige før du ønsker å gjøre noen endringer.

apache2_logo

Det første du må tenke på er: Hvilken kapasitet har teamet mitt? Hvor mange samtidige tilkoblinger kan utstyret mitt støtte hvis jeg tvinger det så mye som mulig? Alt dette avhenger av en enkelt faktor; RAM (Random Access Memory).

Jo større RAM, jo større antall tilkoblinger, selv om det ikke er noen fast verdi (det vil si X-klienter for hver X-ram), er det først og fremst viktig å gjøre noen små beregninger på webserveren vår, med for å kjenne grensene våre.

Det første du bør vite er hvor mye RAM i gjennomsnitt hver tilkobling til Apache bruker, siden hver tilkoblede tilkobling antar et visst RAM-forbruk i systemet ... Åpenbart ikke alle tilkoblinger bruker den samme RAM, som man må lage a media ... Alt dette kan fås med følgende kommando:

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

Det oppnådde resultatet vil være representert i megabyte og kan variere avhengig av antall aktive tilkoblinger, hvilken type sider du får tilgang til, osv ... Derfor anbefales det å utføre testen med forskjellige faner åpne; hver av dem viser om mulig annet innhold. I mitt tilfelle har resultatet for eksempel blitt 9.5458, som hvis vi avrunder det opp til toppen ville vært 10 MB RAM-forbruk i gjennomsnitt per tilkobling.

Det er også viktig å vite hvor mye RAM som forbrukes av resten av prosessene som er aktive i systemet, siden nettjenesten ikke er den eneste som kjører i operativsystemet, og det er nødvendig å legge igjen ledig RAM på serveren slik at den kan utføre resten av oppgavene. Dette kan fås med kommandoen vist nedenfor:

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

Det oppnådde resultatet vil også bli representert i megabyte, og det vil vise oss ganske nøyaktig hvor mye RAM som forbrukes av resten av prosessene; i mitt tilfelle 800 MB. Med denne informasjonen kan vi foreta en generell beregning av antall samtidige forbindelser vi kan ha; Jeg beregner at vi ville oppnå ved hjelp av en veldig enkel operasjon.

(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN

Med denne formelen i hånden, la oss forestille oss at vi har en datamaskin med 4 GB RAM, det vil si 4096 MB, og at datamaskinen vår har vist de ovennevnte resultatene; beregningen ville være:

(4096 - 800) / 10 = 329 samtidige tilkoblinger

Problemet med denne beregningen er at man er for ekstrem, siden den vil forbruke alt RAM (slik at serveren forbruker bytte), og i tilfelle du har en database, for eksempel MySQL eller andre, vil forbindelsene til den også forbruke RAM, som nummeret som oppnås kan kvalifiseres som et utopisk nummer. Derfor, for å frigjøre minnet for mulige tilleggsprosesser og også vurdere muligheten for at forbindelser til en database utføres, vil vi redusere antall tilkoblinger til 250.

Nå som vi har maksimalt antall samtidige tilkoblinger, må vi forberede Apache for å motta dette nummeret, noe som gjøres i konfigurasjonsfilen til denne samtalen. apache2.conf, som er vert i / etc / apache2.

Den aktuelle filen følger en struktur basert på moduler, hver med sitt tilhørende navn, men vi vil bare være interessert i en av dem, hvis navn er  mpm_prefork_module. Modulen det gjelder har som standard følgende data:

StartServere 5 MinSpareServere 5 MaxSpareServers 10 Maks Klienter 150 Maks Forespørsler Per barn 0

Denne modulen har en rekke veldig viktige parametere, selv om det er en av dem som spesielt vil interessere oss, kalt MaxClients. Denne parameteren angir maksimalt antall samtidige tilkoblinger og skal endres til 250.

En detalj å ta i betraktning er at når en annen verdi enn standard er spesifisert i nevnte parameter, er det nødvendig å legge til en annen mer FØR denne. Denne parameteren kalles ServerLimit og setter grensen for tilkoblinger som serveren kan "holde" selv når den er utenfor grensen.

ServerLimit-parameteren må alltid være litt høyere enn MaxClients, og her, da det er lite handlingsrom, er det en grense på 270. Dette vil få modulen til å se slik ut:

StartServere 5 MinSpareServere 5 MaxSpareServere 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0

Nå vil det bare være nødvendig å starte Apache-tjenesten på nytt ved hjelp av kommandoen: 

/etc/init.d/apache2 omstart

Med dette kunne vi allerede ha glede av vår optimaliserte webserver.

Hilsener.


Innholdet i artikkelen følger våre prinsipper for redaksjonell etikk. Klikk på for å rapportere en feil her.

21 kommentarer, legg igjen dine

Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.

  1.   zetatino sa

    Takk for innlegget!

    1.    Drassill sa

      Jeg er glad du syntes det var nyttig.

      Hilsener.

  2.   Miguel Angel sa

    Det er en måte å klynge med Apache og to servere, kan du forklare hvordan det fungerer?

    1.    Drassill sa

      Selv om jeg har lest noen teori om det, har jeg aldri brukt det på praksis. Likevel, kanskje denne artikkelen kan gi deg litt veiledning i denne forbindelse, selv om jeg gjentar at jeg ikke har hatt muligheten til å praktisere den:

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

    2.    Eduardo Jalil sa

      Du har spurt lenge, hvis du ikke løste det; Jeg har en balanseringsordning med en tredjepart som fungerer som et filsystem, du peker mappene som er i var / www / html / (i mitt tilfelle) til filsystemet, så de deler den samme informasjonen, og du vil muligens krever en virtuell ip som reagerer og omdirigerer til ips av apaches, for dette kan du okkupere en haproxy, og hvis du vil ha den i høy tilgjengelighet, kan du integrere keepalive i tilfelle den ene faller, den andre fortsetter å svare, eller også hvis du allerede har et domene for applikasjonen, kan du balansere med pund som gjør backends til begge serverne, for spesifikke tilfeller som moodle eller visse applikasjoner som kobles til en database i mysql, må du opprette en bruker per app-server som peker til samme database .

  3.   shamaru sa

    Tusen takk for innlegget, du har helt rett, rammen er den primære beregningen, selv om jeg forestiller meg at vi også beregner maksimalt antall prosesser som prosessoren vår kan håndtere (selvfølgelig først å gjøre beregningen av hovedminnet) og hvordan disken ville bli distribuert hardt (Eksempel på partisjoner / var = 1TR).

    1.    Drassill sa

      Du har rett; alt er viktig, som blant annet temperaturkontroll. Åpenbart kan en kraftig prosessor utføre et større antall oppgaver samtidig med stor effektivitet, men målet med dette innlegget var å forklare viktigheten av RAM med hensyn til antall samtidige tilkoblinger.

      En god måte å kontrollere alle disse faktorene og se om prosessoren vår ikke er mettet eller om vi har lite ledig RAM, ville være å bruke et bash-skript. Det kan hende du synes dette innlegget som jeg laget for noen dager siden var interessant, at jeg legger igjen deg i følgende lenke; Det er en global overvåking, men det kan være interessant for en:

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

      Hilsen

  4.   Sergio S sa

    Veldig bra merknad, tusen takk!

    1.    Drassill sa

      Takk så mye! Jeg håper du har klart å dra nytte av det.

  5.   klovn sa

    Jeg vil ikke være en skitten ...
    ... Men ved å øke antall tilkoblinger forlater du ikke mer sårbar for et DDoS-angrep?

    1.    Drassill sa

      Det er ikke noe stille cretin-spørsmål. Sannheten er at ved å øke antall samtidige tilkoblinger, styrker vi delvis Apache mot DDOS-angrep, siden du må ta i betraktning at antallet maksimale samtidige tilkoblinger som er etablert på serveren er antall totale maksimale tilkoblinger, ikke de som kommer fra en enkelt bruker. Selv om vi i begynnelsen bare kunne støtte 150 samtidige tilkoblinger (enten de er tilkoblinger fra en legitim kilde eller ikke), kan vi nå stole på så mange som serveren vår støtter, og krever et større antall tilkoblinger samtidig for å være uten service. Å øke det maksimale antallet tilkoblinger er åpenbart ikke en måte å beskytte mot denne typen angrep, men heller brannmurpolitikk bør implementeres. Hvis for eksempel nettjenesten du vil legge til, blir eksponert for internett, vil et sikkerhetstiltak som kan implementeres være tillegg av disse linjene til brannmuren vår:

      iptables -A INNGANG -p tcp –syn –port 80 -m connlimit –connlimit-upto 10 -m state –state NEW -j ACCEPT

      iptables -A INPUT -p tcp –dport 80 -m state –state ESTABLISHED, RELATED -j ACCEPT

      iptables -A INNGANG -p tcp –port 80 -j DROP

      1.    klovn sa

        En av egenskapene til DDoS-angrep er at en angriper kan se ut til å sende pakker fra flere forskjellige retninger, noe som forhindrer at strømmen av pakker bare kommer fra en retning.

    2.    Drassill sa

      Du har rett i den forstand at en brannmur som den jeg har satt opp ikke er veldig effektiv mot et DDOS-angrep, siden den kommer fra forskjellige kilder. Likevel er det bedre å begrense antall tilkoblinger til 10 for hver av disse kildene i stedet for å ikke ha en grense, slik at hver kilde kan opprette hundre forbindelser eller mer.

      Uansett er settet med spørsmålet at jo flere samtidige tilkoblinger serveren støtter, desto vanskeligere vil det være å slå den ned med et DDOS-angrep, noe som vil gjøre det vanskeligere for siden å bli slått ned av en angriper. .

      Hilsener.

  6.   eliotime3000 sa

    Flink. Foreløpig fortsetter jeg med NGINX på nettstedet mitt for ikke å torturere VPS jeg har.

  7.   Bruno cascio sa

    Bra innlegg @Drassill!

    Jeg ønsket å bidra med noe kanskje mer statistisk enn konfigurasjon.
    Selv om den enkleste og raskeste måten å beregne forbruksparameteren er med gjennomsnittet, kan vi kanskje være strengere og bruke "medianen" i stedet for "gjennomsnittet". Hva ville reddet oss? At tallene skyter opp i tilfelle en forbindelse har brukt mye minne. Anta for eksempel at følgende klienter som bruker følgende verdier, i enheten de vil ha (KB, MB, MiB, etc):

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

    Gjennomsnittet vil gi ca ~ 30

    Og dette fordi vi har en veldig stor ende (150), og beregningene er sprø. Medianen består i å bestille disse dataene, dele antall prøver med 2 (vårt sentrum) og deretter oppnå nummeret til den posisjonen. Med dette ville vi hatt noe sånt

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

    Så gjennomsnittet vårt ville være: 8/2 = 4 det vil si ~ 10

    Her kan du se at uansett hvor gal ekstremen kan være, vil det alltid gi oss en mer realistisk verdi. Hvis vi legger til en kunde som bruker 200, vil medianen vår være 11, mens gjennomsnittet kan gå til …….

    Det er bare et bidrag, og det er veldig diskutabelt, for med forbindelsene er det ikke skrudd.

    Klem folk linuxera 🙂

  8.   Carlos sa

    Hei, jeg hadde et problem på den dedikerte serveren min, og det er at hver gang antallet rundt 250 personer på nett nærmer seg, ifølge google analytics i sanntid, min server som den kollapser og forbindelsen blir treg til den slipper forbindelsen til nettstedet og laster aldri opp mer enn det antallet brukere online, men når jeg ser ytelsen til den dedikerte serveren som er 8 GB RAM, viser den 10% av bruken, CPU: 5% av bruken og harddisken i: 1.99% av bruk.
    Kan du hjelpe meg? Jeg finner ikke hva jeg skal gjøre, er løsningen å gjøre disse trinnene?

    1.    Drassill sa

      Bra Carlos.

      Problemet du beskriver er veldig vanlig når serveren ikke er ordentlig forberedt. Serveren din vil sannsynligvis akseptere et mye mindre antall samtidige tilkoblinger, og når den når 250 tilkoblinger, vil den krasje. Ved å følge håndboken bør du kunne løse problemet, men hvis du har en database på den serveren, må du også optimalisere databasen.

      Hilsener.

      1.    Carlos sa

        Drassill, jeg har gjort konfigurasjonen du nevnte, og den har vært tilfredsstillende, i går nådde jeg 280 brukere online og serveren krasjet ikke, jeg er veldig fornøyd med dette resultatet, og jeg vil også gjøre den andre tingen du ber meg om å optimalisere databasen, ¿Hvordan oppnår jeg dette?

    2.    Drassill sa

      Databasekonseptet er ganske åpent; Det er ikke det samme å bruke mysql som postgres (for eksempel). Åpenbart kjenner jeg ikke alle databasene; Jeg har prøvd mysql og postgres, og økningen av samtidige tilkoblinger i disse vil være basert på parameteren max tilkoblinger; mysql optimalisering vil bli gjort i /etc/my.conf og parameteren for maksimale tilkoblinger må endres (blant andre). For postgres i stedet har jeg en artikkel på bloggen min som forklarer hvordan du optimaliserer den som kan være nyttig for deg, eller som du kan bruke den som referanse for databasen din:

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

      Hilsener.

  9.   Erickson vasquez sa

    Hei, når jeg kaster den første kommandoen, viser den meg verdi 0. Hva kan det være?

  10.   Daniel Ojeda sa

    Takk for dette innlegget.