HTTPS é 50 vezes mais lento que HTTP


8

Eu tenho um site que usa https para transmitir um arquivo javascript para o cliente. O site é getsimpleapps.com .

Acontece que esse arquivo está carregando 52 vezes mais devagar com https (20.08s - 29.08s) que com http (380ms).

A página inicial do site compartilha a mesma lentidão do arquivo javacript.

Recentemente, mudei do dreamhost para o linode e hackeei para que o SSL funcionasse no novo servidor até o momento. Eu não fiz nenhuma configuração maluca.

O linode está executando o Ubuntu 12.04 e o site está no topo de uma pilha (LAMP).

Minha pergunta para a comunidade de estouro de pilha é: Como faço para corrigir o SSL e HTTPS no meu servidor? Eu sei que o estouro de pilha está repleto de perguntas sobre a lentidão do HTTPS, mas nenhuma solução real é fornecida. Um tutorial ou guia de configuração do ubuntu seria o ideal.


arquivo: /etc/apache2/sites-enabled/getsimpleapps.com

<VirtualHost *:80>
     ServerAdmin admin@getsimpleapps.com
     ServerName getsimpleapps.com
     ServerAlias www.getsimpleapps.com
     DocumentRoot /srv/sites/getsimpleapps.com/public/
     ErrorLog /srv/sites/getsimpleapps.com/logs/error.log
     CustomLog /srv/sites/getsimpleapps.com/logs/access.log combined
</VirtualHost>

<VirtualHost 50.116.58.18:443>
     SSLEngine On
     #SSLCertificateFile /etc/apache2/ssl/www.getsimpleapps.com.crt
     #SSLCertificateKeyFile /etc/apache2/ssl/www.getsimpleapps.com.key
     #SSLCACertificateFile /etc/apache2/ssl/comodo.crt
     SSLCertificateFile /etc/apache2/ssl/dreamhost/dh.crt
     SSLCertificateKeyFile /etc/apache2/ssl/dreamhost/dh.key
     SSLCACertificateFile /etc/apache2/ssl/dreamhost/dh.cer

     ServerAdmin admin@getsimpleapps.com
     ServerName getsimpleapps.com
     ServerAlias www.getsimpleapps.com
     DocumentRoot /srv/sites/getsimpleapps.com/public/
     ErrorLog /srv/sites/getsimpleapps.com/logs/error.log
     CustomLog /srv/sites/getsimpleapps.com/logs/access.log combined
</VirtualHost>

Enrolar da estação de trabalho local

thomas@workstation:~$ time curl -Iv https://getsimpleapps.com/
* About to connect() to getsimpleapps.com port 443 (#0)
*   Trying 50.116.58.18... connected
* Connected to getsimpleapps.com (50.116.58.18) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: OU=Domain Control Validated; OU=Provided by New Dream Network, LLC; OU=DreamHost Basic SSL; CN=getsimpleapps.com
*    start date: 2012-02-23 00:00:00 GMT
*    expire date: 2013-02-22 23:59:59 GMT
*    subjectAltName: getsimpleapps.com matched
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=Comodo CA Limited; CN=PositiveSSL CA
*    SSL certificate verify ok.
> HEAD / HTTP/1.1
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
> Host: getsimpleapps.com
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 02 Aug 2012 20:31:39 GMT
Date: Thu, 02 Aug 2012 20:31:39 GMT
< Server: Apache/2.2.22 (Ubuntu)
Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.2
X-Powered-By: PHP/5.3.10-1ubuntu3.2
< Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2298c7e45da25e4aaf80f7a1e36ed4a006%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A13%3A%2250.75.209.154%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22curl%2F7.21.4+%28universal-apple-darwin11.0%29+libcurl%2F7.21.4+OpenSSL%2F0.9.8r+zlib%2F1.2.5%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343939499%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D80bf8ae5040fc47780ccd59f1fb8b267; expires=Thu, 02-Aug-2012 22:31:39 GMT; path=/
Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2298c7e45da25e4aaf80f7a1e36ed4a006%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A13%3A%2250.75.209.154%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A81%3A%22curl%2F7.21.4+%28universal-apple-darwin11.0%29+libcurl%2F7.21.4+OpenSSL%2F0.9.8r+zlib%2F1.2.5%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343939499%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D80bf8ae5040fc47780ccd59f1fb8b267; expires=Thu, 02-Aug-2012 22:31:39 GMT; path=/
< Vary: Accept-Encoding
Vary: Accept-Encoding
< Content-Type: text/html
Content-Type: text/html

< 
* Connection #0 to host getsimpleapps.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

real    0m29.078s
user    0m0.018s
sys 0m0.005s

Enrolar do servidor linode (via ssh)

thomas@vannevar:~$ time curl -Iv https://getsimpleapps.com/happy-ending/api/script.js?shop=holstee.myshopify.com
* About to connect() to getsimpleapps.com port 443 (#0)
*   Trying 50.116.58.18... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: OU=Domain Control Validated; OU=Provided by New Dream Network, LLC; OU=DreamHost Basic SSL; CN=getsimpleapps.com
*    start date: 2012-02-23 00:00:00 GMT
*    expire date: 2013-02-22 23:59:59 GMT
*    subjectAltName: getsimpleapps.com matched
*    issuer: C=GB; ST=Greater Manchester; L=Salford; O=Comodo CA Limited; CN=PositiveSSL CA
*    SSL certificate verify ok.
> HEAD /happy-ending/api/script.js?shop=holstee.myshopify.com HTTP/1.1
> User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: getsimpleapps.com
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Thu, 02 Aug 2012 20:43:30 GMT
Date: Thu, 02 Aug 2012 20:43:30 GMT
< Server: Apache/2.2.22 (Ubuntu)
Server: Apache/2.2.22 (Ubuntu)
< X-Powered-By: PHP/5.3.10-1ubuntu3.2
X-Powered-By: PHP/5.3.10-1ubuntu3.2
< Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2204a54136cab08f9fdc5f082ebb8e739a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%2250.116.58.18%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A97%3A%22curl%2F7.22.0+%28i686-pc-linux-gnu%29+libcurl%2F7.22.0+OpenSSL%2F1.0.1+zlib%2F1.2.3.4+libidn%2F1.23+librtmp%2F2.3%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343940210%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7De7d7b8e2ca69b34c531ba7472b4b21b7; expires=Thu, 02-Aug-2012 22:43:30 GMT; path=/
Set-Cookie: ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%2204a54136cab08f9fdc5f082ebb8e739a%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%2250.116.58.18%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A97%3A%22curl%2F7.22.0+%28i686-pc-linux-gnu%29+libcurl%2F7.22.0+OpenSSL%2F1.0.1+zlib%2F1.2.3.4+libidn%2F1.23+librtmp%2F2.3%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1343940210%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7De7d7b8e2ca69b34c531ba7472b4b21b7; expires=Thu, 02-Aug-2012 22:43:30 GMT; path=/
< Content-Type: text/javascript
Content-Type: text/javascript
* no chunk, no close, no size. Assume close to signal end

< 
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

real    0m25.991s
user    0m0.015s
sys 0m0.022s

1
"It turns out that this file is loading 52% slower with https (20.08s - 29.08s) that with http (380ms)."- Hã? Você pode verificar suas unidades e gramática lá, por favor. Isso não faz muito sentido.
MDMarra

1
Eu acho que o OP foi 53 vezes mais lento. O HTTPS está carregando muito lentamente.

Talvez você simplesmente solte o virtualmin nele e permita que ele configure tudo para você.
Andrew Smith

1
Hmm. Isto está errado. Existe algo nos logs do Apache que possa indicar onde está a desaceleração? No meu servidor, vejo 263ms para HTTPS e 84ms para HTTP. A grande diferença que você está vendo se deve a outra coisa.
CJC

1
Por favor, cole sua configuração do Apache.
Michael Hampton

Respostas:


3

Eu tive o mesmo problema, com diferenças de tempo de resposta quase idênticas entre HTTP e HTTPS. Acontece que o problema foi o da resposta de @htmltiger : o Apache2 estava simplesmente ficando sem processos de trabalho.

Isso faz com que novas solicitações sejam enfileiradas até que um trabalhador fique livre e possa processar a próxima [ origem ]. Suponho que a razão pela qual isso afeta apenas o HTTPS e não o HTTPS é que quase todo o tráfego é sobre HTTP e o Apache fornece às solicitações HTTP e HTTPS a mesma prioridade, tendo uma solicitação de cada fila por vez. Portanto, quando a fila HTTPS é muito mais longa, as solicitações aguardam muito mais. De fato, existem duas filas, pois a fila é simplesmente o mecanismo da fila de conexão TCP do Linux, e o Linux fornece uma fila por porta.

Diagnóstico

Se este for seu problema, os seguintes sintomas serão aplicados:

  • O melhor indicador: no seu servidor, apachectl statusmostra que todos os processos de trabalho permitidos estão em execução. Este é o caso em que nenhum ponto .é exibido na linha do placar do processo, indicando que não há "slot aberto sem processo atual" restante. A linha pode ficar assim, por exemplo:

    KKKKKKRKKKRRCWKKKCCKWKKKKCRCKKKKKKKCKCKKKKWRKKKKWRWKKKKKKCWKKWKKK
    
  • Você vê mensagens como esta no seu log de erros principal do Apache2 ( /var/log/apache2/error.lognão as específicas do domínio):

    [mpm_prefork:error] [pid 4715] AH00161: server reached MaxRequestWorkers 
        setting, consider raising the MaxRequestWorkers setting
    
  • Existem muitos processos no backlog do Apache. De acordo com este artigo detalhado , você pode ver isso no unacked:valor da ss -lti '( sport = :https )'saída. Dependendo da versão ou configuração ss, esse valor pode estar ausente.

  • A maior parte do atraso (digamos, 17 de 20 s) é mostrada no Firefox Network Console, na guia "Tempos" do URL inicial solicitado, como "Bloqueio".

Solução

Isso pressupõe que você use o módulo do servidor MPF prefork no Apache. É semelhante para os módulos MPM "event" e "worker" - detalhes .

  1. Edite /etc/apache2/mods-enabled/mpm_prefork.confe aumente a MaxRequestWorkersconfiguração.

  2. Se você aumentar para além do padrão de 256, também precisará definir ServerLimit para o mesmo valor para efetivar sua alteração.

  3. Aplique as alterações: service apache2 reload

  4. Na saída do placar, verifique se apachectl statusa nova MaxRequestWorkersconfiguração é eficaz. Tem que ser equivalente ao comprimento da linha do placar em caracteres.

  5. Se a configuração ainda não estiver em vigor, pesquise /etc/apache2diretivas de configuração antigas (e seus sinônimos obsoletos ainda mais antigos) que poderiam substituir sua alteração:

    grep -R MaxRequestWorkers /etc/apache2/*
    grep -R MaxClients /etc/apache2/*
    

Diagnósticos diferenciais

Caso você veja que o HTTPS é muito mais lento que o HTTP, mas nem sempre em uma série de recarregamentos de páginas (apenas em média), você pode ter uma variante desse problema sofisticado , com dois servidores Apache2 em execução na porta SSL 443.


0

Tente alterar a cifra para RC4-MD5 (bom equilíbrio de desempenho e segurança), ou seja:

SSLCipherSuite RC4-MD5

Felicidades


2
A disparidade relatada entre HTTP e HTTPS não é causada por uma opção de cifra. É alguma outra configuração incorreta.
CJC

@cjc Eu gostaria de ver se faz alguma diferença ... não faz mal tentar.
HTTP500

@ HTTP500 colocou isso em httpd.conf? Que tal SSLProtocol all?
ThomasReggi

@ThomasReggi, basta colocá-lo sob o seu SSLEngine On line. Eu sugeriria: SSLProtocol all -SSLv2
HTTP500 2/12/12

O que?! é muito mais rápido agora. Eu não reiniciei o apache2 está tudo bem?
ThomasReggi

0

Eu tive um problema semelhante para um servidor ocupado, mas aumentar o MaxRequestWorkers para 400 no mpm_prefork.conf o corrigiu.


-1

Acontece que meu problema foi que minhas chaves eram de outro servidor. Eu precisava obter um novo certificado e configurá-lo com novas chaves.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.