Oghje vengu à parlavvi una volta di più nantu à unu di i servizii web i più aduprati in u mondu: U servore web Apache2.
Hè un tema chì hè statu parlatu parechje volte, ma avà vengu à parlavvi di un'altra caratteristica da tene in contu cù stu serviziu: U limitu di cunnessione simultanea. Ùn importa micca se avemu assai basicu o una nave spaziale cù un processore i7 è 32 GB di ram ...
U limitu di e cunnessioni simultanee serà sempre uguale a menu chì ùn pigliemu misure adeguate, chì significa chì se vulemu avè parechje persone cunnesse in u stessu tempu, ùn averemu micca solu un bonu hardware, ma dinò una bona configurazione.
In questu casu ùn hè micca necessariu installà nunda, tuttu hè basatu annantu à cuncetti simplici chì devenu esse pigliati in contu per cunfigurà l'apache; cuncetti chì devenu esse assai chjari prima di vulè fà cambiamenti.
A prima cosa à pensà hè: Chì capacità hà a mo squadra? Quante cunnessioni simultanee ponu supportà u mo equipagiu se u forza quant'è pussibule? Tuttu què dipende da un fattore unicu; RAM (Random Access Memory).
Più grande hè a RAM, più grande hè u numeru di cunnessioni, ancu s'ellu ùn ci hè micca un valore fissu (vale à dì, clienti X per ogni X ram), hè per quessa chì prima di tuttu hè impurtante di fà qualchì picculu calculu nantu à u nostru servore web, cù u per cunnosce i nostri limiti.
A prima cosa chì duvete sapè hè quantu RAM consuma in media ogni cunnessione à Apache, postu chì ogni cunnessione stabilita suppone un certu cunsumu di RAM in u sistema ... Ovviamente micca tutte e cunnessioni cunsumanu u listessu ram, cù quale unu duverebbe fà un media ... Tuttu què si pò uttene cù u cumandimu seguente:
ps -ylC apache2 --sort: rss | awk '{SUM + = $ 8; I + = 1} END {print SUM / I / 1024} '
U risultatu ottenutu seria ripresentatu in megabyte è pò varià secondu u numeru di cunnessioni attive, u tippu di pagine accessu, ecc ... Per quessa, hè cunsigliatu di fà a prova cù diverse schede aperte; ognuna mostra un cuntenutu diversu se hè pussibule. In u mo casu, per esempiu, u risultatu hè statu 9.5458, chì, se u circundemu in cima, sarebbe 10 MB RAM cunsumata in media per cunnessione.
Hè ancu impurtante sapè quantu RAM hè cunsumata da u restu di i prucessi chì sò attivi in u sistema, postu chì u serviziu web ùn hè micca l'unicu chì funziona in u sistema operativu è hè necessariu lascià memoria RAM libera nantu à u servitore per ch'ellu possa eseguisce u restu di i compiti. Questu pò esse ottenutu cù u cumandamentu mostratu sottu:
ps -N -ylC apache2 --sort: rss | awk '{SUM + = $ 8} END {print SUM / 1024}'
U risultatu ottenutu seria ancu ripresentatu in megabyte, è ci mostrerebbe abbastanza precisamente a quantità di RAM cunsumata da u restu di i prucessi; in u mo casu 800 MB. Cù queste informazioni pudemu fà un calculu generale di u numeru di cunnessioni simultanee chì pudemu avè; Calculu chì averiamu ottenutu per mezu di un'operazione assai semplice.
(RAMTOTAL - RAM_RESTOPROCESOS) / RAM_POR_CONNEXIÓN
Cù sta formula in manu, imaginemu chì avemu un urdinatore cù 4 GB RAM, vale à dì 4096 MB è chì u nostru urdinatore hà mostratu i risultati sopra menzionati; u calculu seria:
(4096 - 800) / 10 = 329 cunnessione simultanea
U prublema cù stu calculu hè chì unu hè troppu estremu, postu chì cunsumerebbe tutta a RAM (fendu chì u servitore cunsuma scambià) è ancu, in casu d'avè una basa di dati, cum'è MySQL o qualsiasi altra, e cunnessioni à questu cunsumerebbenu ancu RAM , dunque u numeru ottenutu puderia esse qualificatu cum'è numeru utopicu. Dunque, per liberà a memoria per i prucessi addiziunali pussibuli è cunsiderà ancu a pussibilità chì e cunnessione à una basa di dati sianu eseguite, ridurremu u numeru di cunnessione à 250.
Avà chì avemu u nostru numeru massimu di cunnessioni simultanee, duveriamu preparà Apache per pudè riceve stu numeru, ciò chì hè fattu in u fugliale di cunfigurazione di sta chjamata apache2.conf, chì hè allughjatu in / etc / apache2.
U schedariu in quistione seguita una struttura basata annantu à moduli, ognuna cù u so nome currispundente, ma seremu interessati solu à unu d'elli, chì si chjama mpm_prefork_module. U modulu in quistione hà i seguenti dati per difettu:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0
Stu modulu hà una seria di parametri assai impurtanti, ancu s'ellu ci hè unu di quelli chì ci interesserebbe particularmente, chjamatu MaxClients. Stu parametru specifica u numeru massimu di cunnessioni simultanee è deve esse modificatu in 250.
Un ditagliu da tene à mente hè chì quandu un valore altru chì u predefinitu hè specificatu in dittu parametru, hè necessariu aghjunghje un altru più ghjustu PRIMA di questu. Stu paràmetru hè chjamatu ServerLimit è stabilisce u limitu di e cunnessione chì u servitore puderia "tene" ancu quandu hè fora di u limitu.
U parametru ServerLimit deve sempre esse leggermente più altu ch'è MaxClients è quì, postu chì ci hè poca stanza per manuvra, un limite di 270. Questu faria chì u modulu pare cusì:
StartServers 5 MinSpareServers 5 MaxSpareServers 10 ServerLimit 270 MaxClients 250 MaxRequestsPerChild 0
Avà seria solu necessariu riavviare u serviziu Apache cù u cumandamentu:
/etc/init.d/apache2 riavvia
Cù questu pudemu dighjà gode di u nostru servore web ottimizatu.
Saluti.
21 cumenti, lasciate i toi
Grazie per u postu!
Sò cuntentu chì l'avete trovu utile.
Saluti.
Ci hè un modu per raggruppà Apache è dui servitori, pudete spiegà cumu funziona?
Ancu se aghju lettu qualchì teoria à propositu, ùn l'aghju mai applicata à a pratica. Eppuru, forse st'articulu vi pò dà qualchì guida à propositu, ancu se ripete chì ùn aghju micca avutu a pussibilità di mette lu in pratica:
http://www.muspells.net/blog/2011/04/alta-disponibilidad-con-apache2-y-heartbeat-en-debian-squeeze/
Avete dumandatu per un bellu pezzu, se ùn avete micca risoltu; Aghju un schema di bilanciamentu cù un terzu chì agisce cum'è un sistema di file, puntate e cartelle chì sò in var / www / html / (in u mo casu) versu u sistema di file, cusì spartenu a stessa informazione, è avete bisognu di un ip virtuale chì risponde è redirige à ips di l'apache, per questu pudete occupà un haproxy è se vulete in alta disponibilità pudete integrà keepalive in casu chì unu cade, l'altru continua à risponde, o ancu se avete dighjà un duminiu per l'applicazione, pudete bilancià cù libbra fà backends à i dui servitori, per casi specifici cum'è moodle o certe applicazioni chì si cunnettanu à una basa di dati in mysql, duverete creà un utilizatore per servitore app chì punta à a stessa basa di dati.
Vi ringraziemu assai per u postu, avete a ragiò assoluta, u ram hè u calculu primariu, ancu s'imaginu chì calculemu ancu u numeru massimu di prucessi chì u nostru processatore pò gestisce (benintesa, prima facendu u calculu di a memoria principale) è cumu u discu seria distribuitu dura (Esempiu di partizioni / var = 1TR).
Ai ragiò; tuttu hè impurtante, cum'è u cuntrollu di a temperatura frà altre cose. Ovviamente un putente processatore pò fà un numeru più numeruu di attività simultaneamente cun grande efficienza, ma l'ubbiettivu di questu post era di spiegà l'importanza di a RAM in quantu à u numeru di cunnessioni simultanee.
Un bonu modu per cuntrullà tutti questi fattori è vede se u nostru processatore ùn hè micca saturatu o se avemu poca RAM libera, seria aduprendu un script bash. Forse questu articulu chì aghju fattu pochi ghjorni fà à propositu hè interessante per voi, chì vi lasciu in u ligame chì seguita; Hè un surviglianza glubale ma pò esse interessante per qualchissia:
http://bytelearning.blogspot.com.es/2015/07/controlando-la-salud-del-equipo-con-bash.html
riguarda
Nota assai bona, ti ringraziu assai!
Grazie tante! Speru chì averete pussutu prufittà di ellu.
Ùn vogliu micca esse un idiota ...
... Ma aumentendu u numeru di cunnessioni ùn lasciate micca più vulnerabile à un attaccu DDoS?
Ùn hè una dumanda cretina tranquilla. A verità hè chì aumentendu u numeru di cunnessioni simultanee, furtificamu in parte Apache contr'à attacchi DDOS, perchè duvete tene contu chì u numeru di cunnessioni simultanee massime stabilite nantu à u servitore hè u numeru di cunnessioni massime totali, micca quelli chì venenu da un solu utilizatore. Cusì, mentre à u principiu pudemu solu supportà 150 cunnessioni simultanee (sì sò cunnessioni da una fonte legittima o micca) avà pudemu contà nantu à quanti supporta u nostru servitore, richiedendu un numeru più grande di cunnessioni in u stessu tempu per esse senza serviziu. Ovviamente, aumentà u numeru massimu di cunnessioni ùn hè micca un modu per pruteggervi da stu tippu di attaccu, ma piuttostu duverete implementà politiche di firewall. Se, per esempiu, u serviziu web chì vulete mette serà espostu à l'internet, una misura di sicurità chì puderia esse implementata seria l'aghjuntu di queste linee à u nostru firewall:
iptables -A INPUT -p tcp –syn –dport 80 -m connlimit –connlimit-finu à 10 -m state –state NEW -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -m state –statu STABILITU, RELATED -j ACCEPT
iptables -A INPUT -p tcp –dport 80 -j DROP
Una di e caratteristiche di l'attacchi DDoS hè chì un attaccante pò sembra invià pacchetti da diverse direzzioni diverse, chì impedisce u flussu di pacchetti di vene solu da una direzzione.
Avete ragiò in u sensu chì un firewall cum'è quellu chì aghju installatu ùn hè micca assai efficiente contr'à un attaccu DDOS, postu chì vene da diverse fonti. Eppuru, hè megliu à limità u numeru di cunnessioni à 10 per ognuna di queste fonti piuttostu chì ùn avè micca un limite, in modo chì ogni fonte possa stabilisce un centu di cunnessioni o più.
In ogni casu, u kit di a quistione hè chì più cunnessioni simultanee u servitore sustene, più serà difficiule di tomballu cun un attaccu DDOS, ciò chì renderebbe più difficiule per a pagina di esse abbattuta da un attaccante.
Saluti.
Bene. Per avà continuu cù NGINX in u mo situ per ùn torturà u VPS chì aghju.
Bellu postu @Drassill!
Vuliu cuntribuisce cù qualcosa forse più statisticu chè cunfigurazione.
Ancu se u modu u più faciule è u più veloce per calculà u paràmetru di cunsumu hè cù a media, forse puderiamu esse più rigorosi è aduprà a "mediana" invece di a "media". Chì ci salverebbe? Chì i numeri sparanu in casu chì una cunnessione hà cunsumatu assai memoria. Per esempiu, suppone chì i clienti seguenti chì cunsumanu i valori seguenti, in l'unità di memoria chì volenu (KB, MB, MiB, ecc):
10, 15, 150, 5, 7, 10, 11, 12
A media darà circa ~ 30
E questu perchè avemu un estremu assai grande (150), è i calculi sò pazzi. A mediana cunsiste à urdinà questi dati, dividendu u numeru di campioni per 2 (u nostru centru) è dopu uttene u numeru di quella posizione. Cù questu averebbe qualcosa cum'è
5, 7, 10, 10, 11, 12, 15, 150
Dunque a nostra media seria: 8/2 = 4 vale à dì ~ 10
Quì pudete vede chì, per quantu pazzu chì sia l'estremu, ci darà sempre un valore più realistu. Se aghjunghjemu un cliente chì cunsuma 200, a nostra mediana serà 11, mentre a media pò andà à .......
Hè solu una cuntribuzione, è hè assai discutibile, perchè cù e cunnessioni ùn hè micca avvitatu.
Hug people linuxera 🙂
Ciao, aghju avutu un prublema nantu à u mo servitore dedicatu, è hè chì ogni volta chì u numeru di circa 250 persone in linea s'avvicina, secondu google analytics in tempu reale, u mo servitore piace è crolla è a cunnessione diventa lenta finu à chì cade a cunnessione à u situ web è ùn carica mai più di quellu numeru di utenti in linea, ma quandu vedu e prestazioni di u servitore dedicatu chì hè 8gb ram mostra 10% di usu, a cpu: 5% di usu è u discu duru in: 1.99 % di usu.
Mi poi aiutà? Ùn possu truvà chì fà, sta procedura hè a soluzione?
Bon Carlos.
U prublema chì descrivi hè assai cumunu quandu u servitore ùn hè micca preparatu currettamente. U vostru servitore accetterà probabilmente un numeru assai più chjucu di cunnessioni simultanee è quandu ghjunghje à 250 cunnessioni si schianterà. Dopu à u manuale duverete esse capace di risolve u prublema, ancu se avete una basa di dati in quellu servitore, duverete ancu ottimisà quella basa di dati.
Saluti.
Drassill, aghju fattu a cunfigurazione chì avete menzionatu è hè stata soddisfacente, eri aghju ghjuntu à 280 utilizatori in linea è u servitore ùn hè micca impiccatu, sò assai cuntentu di stu risultatu, è vogliu ancu fà l'altra cosa chì mi dite d'ottimizà a basa di dati, ¿ Cumu uttene questu?
U cuncettu di basa di dati hè abbastanza apertu; aduprà mysql ùn hè micca listessu chè postgres (per esempiu). Ovviamente ùn cunnoscu micca tutte e basi di dati; Aghju pruvatu mysql è postgres, è l'aumentu di e cunnessioni simultanee in questi seria basatu nantu à u parametru cunnessioni max; L'ottimizazione mysql seria fatta in /etc/my.conf è u paràmetru di cunnessione max duverebbe esse cambiatu (frà altri). Per i postgres invece, aghju un articulu nantu à u mo blog chì spiega cumu ottimisallu chì pò esse utile per voi o chì pudete aduprà cum'è riferimentu per a vostra basa di dati:
http://bytelearning.blogspot.com.es/2016/02/postgresql-una-alternativa-mysql-en.html
Saluti.
Bonghjornu, quandu tiru u primu cumandamentu, mi mostra u valore 0. Chì puderia esse?
Grazie per questu postu.