Posso usare Apache mod_proxy come pool di connessione, sotto Prefork MPM?

Question

Sommario/Quesiton:

ho Apache in esecuzione con Prefork MPM, in esecuzione php. Sto cercando di utilizzare Apache mod_proxy per creare un proxy inverso che possa reindirizzare le mie richieste attraverso, in modo che io possa usare Apache per fare il pool di connessioni. impl Esempio:

in httpd.conf:

SSLProxyEngine On 
ProxyPass /test_proxy/ https://destination.server.com/ min=1 keepalive=On ttl=120 

ma quando corro la mia prova, che è il seguente comando in un ciclo:

curl -G 'http://localhost:80/test_proxy/testpage' 

non sembra di ri- usa le connessioni.

Dopo qualche ulteriore lettura, sembra che non sto ottenendo la funzionalità del pool di connessioni perché sto usando l'MPM di Prefork piuttosto che il MPM di Worker. Quindi ogni volta che faccio una richiesta al proxy, esso fa girare un nuovo processo con il proprio pool di connessione (di dimensione uno), invece di utilizzare il singolo lavoratore che mantiene il proprio pool. Questa interpretazione è giusta?

---

informazioni Background:

C'è un server esterno che io faccio richieste di, tramite HTTPS, per ogni pagina ha colpito su un sito che corro.

La negoziazione dell'handshake SSL sta diventando costosa, perché uso php e non sembra supportare il pool di connessioni - se ottengo 300 richieste di pagine sul mio sito, devono fare 300 handshake SSL al server esterno, perché le connessioni vengono chiuse al termine di ogni script.

Quindi sto tentando di utilizzare un proxy inverso in Apache per funzionare come un pool di connessioni, per mantenere le connessioni tra i processi php in modo da non dover fare l'handshake SSL più spesso.

fonti che mi ha dato questa idea:

• http://httpd.apache.org/docs/current/mod/mod_proxy.html
• http://geeksnotes.livejournal.com/21264.html

Answer 1

Prefork può ancora Pool 1 connessione per server di backend per processo.

prefork non crea necessariamente un nuovo processo per ogni richiesta di frontend, i processi del server vengono "raggruppati" e il comportamento dipende, ad es. MinSpareServers/MaxSpareServers e amici.

Per massimizzare la frequenza con cui un processo di prefork avrà una connessione backend per voi, evitare maxspareserver molto alti o bassi o minspareserver molto alti poiché questi si tradurranno in processi "freschi" che accettano nuove connessioni.

È possibile registrare% P nella direttiva LogFormat per ottenere un'idea sulla frequenza di riutilizzo dei processi.

Answer 2

Prima di tutto, il metodo di test non può dimostrare il pool di connessioni poiché per ogni chiamata, un client di arricciamento nasce e quindi muore. Come i morti non parlano molto, un processo morto non può mantenere in vita una connessione.

Hai clienti che infastidiscono il tuo server proxy.

Client ====== (A) =====> ProxyServer 

Chiamiamo questa connessione A. Il server proxy non fa nulla, è solo uno spettacolo. Il server bello e laborioso è così umile che si nasconde dietro.

Client ====== (A) =====> ProxyServer ====== (B) =====> WebServer 

Qui, se non sbaglio, la connessione protetta è A, non B, giusto?

Ripetendo il mio primo punto, sul test, si crea un client separato per ogni richiesta. Ogni cliente ha bisogno di una connessione separata. La connessione è qualcosa che accade tra almeno due parti. Un lato lascia e la connessione è persa.

Ok, dimentichiamoci di ricci ora e guardiamo insieme cosa vogliamo veramente fare.

Vogliamo avere SSL su A e vogliamo che una parte del traffico sia il più veloce possibile. Per questo scopo, abbiamo già separato il lato B in modo tale da non renderlo ancora più lento, giusto?

Collegamento pooling? Non esiste una connessione di connessioni ad A. Ogni cliente va e viene facendo molto rumore. L'unica cosa che può aiutarti a ridurre questo rumore è "Keep-Alive" che significa, mantenere la connessione attiva dal client a per un breve periodo di tempo in modo che questo stesso cliente possa chiedere altri file che saranno richiesti da questa richiesta . Quando abbiamo finito, abbiamo finito.

Per le connessioni su B, le connessioni verranno raggruppate; ma questo non ti porterà alcuna prestazione dal momento che su una configurazione con un server non avevi questa parte della produzione di rumore.

Come possiamo aiutare questo sistema a funzionare più velocemente?

Se questi due server si trovano sulla stessa macchina, dovremmo sbarazzarci del server show-off e continuare con il nostro server web laborioso. Aggiunge un sacco di lavoro non necessario al sistema.

Se si tratta di macchine separate, allora si sta facendo piacere al server Web prendendo almeno un carico di encyrption (per ssl) da questo povero ragazzo. Tuttavia, puoi essere ancora più bello.

Se si desidera continuare su Apache, passare a mpm_worker da mpm_prefork. In caso di più di 300 richieste simultanee, funzionerà molto meglio. Non ho davvero idea della capacità del tuo hardware; ma se gestire 300 richieste è difficile, credo che questo piccolo cambiamento aiuterà molto il tuo sistema.

Se si desidera avere un sistema ancora più leggero, considerare nginx come alternativa ad Apache. È molto easy to setup funzionare con PHP e avrà prestazioni migliori.

Oltre al front-end, è consigliabile controllare anche il server del database. Il pool di connessioni farà davvero la differenza qui. Assicurati che l'installazione di PHP sia configurata per riutilizzare le connessioni al database.

Inoltre, se si ospita file statici sullo stesso sistema, quindi spostare fuori o su un altro server web o fare ancora meglio spostando i file statici a un sistema di nuvola con CDN come quella di S3 + CloudFront o Rackspace's CloudFiles AWS. Anche senza CloudFront, S3 ti renderà felice. La soluzione di Rackspace arriva con Akamai!

Estrarre file statici renderà il tuo server web "oh cosa è successo, cos'è questo silenzio? Ohhh cielo!" dal momento che hai menzionato questo è un sito web e le pagine web hanno molti file statici per ogni pagina html generata dinamicamente il più delle volte.

Spero che tu possa salvare il povero ragazzo dal lavoro assassino.

Answer 3

Il problema nel mio caso era, il pool di connessioni tra proxy inverso e server back-end non stava avendo luogo perché il server Backend Apache chiudeva la connessione SSL alla fine di ogni richiesta HTTPS.

Il backend Apache Server stava facendo questo becuse della seguente Direttiva essere presenti nel httpd.conf:

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown 

Questa direttiva non ha senso quando il server back-end è collegato tramite un proxy inverso e questo può essere rimosso dalla configurazione del server back-end.