Já comentei no blog sobre os malefícios quanto a instalação de um Waf, como o ModSecurity ou Naxsi, em um apache ou nginx que suportam mais de 30.000 conexões estabelecidas por segundo.

Para quem não sabe, 30.000 conexões HTTP estabelecidas por segundo são equivalentes a 5.000 usuários acessando este servidor via google chrome, já que cada requisição via este browser abre 6 conexões simultâneas com o webserver.

Acontece que o ModSecurity e o Naxsi são firewalls de aplicação, seguindo o modelo de camada OSI. Precisando assim de muitas regras para que funcionem quase que adequadamente.

A regra é clara, quanto mais regras, mais lento fica o seu ambiente.

Sendo assim, ao invés de possuírem um waf by software como frontend do seu web server, passem a utilizar um servidor de cache, como um Varnish, e aproveitem e coloquem algumas das regras nele, utilizando o VSF (Varnish Security Firewall ou o Security.vcl).

Garanto-lhes que o seu ambiente ficará bem mais performático, né rafinha.. 🙂

Compartilhar:

Este post tem 18 comentários

  1. Gustavo,
    Tenho duas dúvida, como posso saber quantidade de conexões abertas no meu apache? um simples netstat -nap grepando por 80, pode mostrar? outra coisa poderia explicar como calcular a quantidade de threads no weblogic, existe uma view para isso e como posso contar elas?

  2. tiago,

    o comando netstat -anp | grep 80 | grep -i stab | wc -l lhe passa esta informação. – estou terminando de colocar alguns detalhes em um post que explica isso. Mas uma coisa importante, q é a monitoração de conexões dos time_wait também deverão ser analisadas, já que elas consumem memória e devem ter o timeout parametrizado para o menor tempo possível, o qual as mata rapidamente e não afeta o seu ambiente. muita gente, como eu, parametriza para 5 segundos.
    depende da versão do weblogic – qual seria a sua ?

  3. Nada contra o Varnish, mais se vc souber usar o mod_secao inves de jogar um monte de regra que os outros fizeram pra vc….com certeza vc vai ganhar e muito em desempenho

  4. Júnior,

    4 profissionais já comprovaram que o mod_sec em um servidor web com mais de 30.000 conexões causa sérias perdas de performance. O tuning no mod-sec é mais do que necessário para que ele funcione, nem estou dizendo que ele seja performático.

    O problema é realmente na quantidade de regras que somos obrigados a implementar nele devido a arquitetura que ele precisa suportar. Apache respondendo para dezenas de urls, com os mais diferentes tipos de cmss.. 🙁

  5. Hoje temos em produção a versão 10 que me parece uma versão uper bugada + jrockit 6, já temos um plano de migração para versão 12c que ao meu ver é uma versão mais stable.
    Sobre as conexões em time_wait pelo que eu entendo é o estágio final das conexões que e estão sendo encerradas, mas que continuam a ocupar memória.

    Poderia postar um pouco mais sobre tricks and tips do weblogic 12c para versões anteriores.

  6. Uma outra dúvida é sobre a performance de huge pages, é verdadeiro a redução das TLB’s? hj temos uma máquina bem parruda com 20 instâncias, 10 front e 10 back, essas instâncias estão em uma lâmina de 100GB com 8×2 Core + com WLS 10, infelizmente a aplicação foi construida para trabalhar com multicast, além dos problemas com lost multicast temos esses problemas com a quantidade de GC’s, para o jrockit “server -Xms:6g -Xmx:6g -Xns:800m -Xgc:gencon -XXtlaSize:wasteLimit=64k,min=64k,preferred=512k -XX:+UseAllocPrefetch -XX:+RedoAllocPrefetch ” tem alguma dica?

  7. Tiago,

    Time_wait – vc está correto, por este motivo que é importante segmentar o weblogic do apache, e também, diminui-lo, alterando no /etc/sysctl.conf. Imagine este parâmetro configurado para 60segundos em um servidor que suporta 5.000 conexões http por segundo. Ele será responsável pelo consumo de mais de 30% de toda memória.

    Dicas de tuning para weblogic 12c e jrockit – tudo irá depender do seu ambiente(servidores + aplicação + acessos) – habilitar o output do gc é um começo e bem importante, mas antes de migrar para a última versão do jrockit, certifique-se que o seu time de desenvolvimento já realizou todos os testes de compatibilidade.

  8. Multicast – primeiro desabilite a opção de autonegociação de todas as interfaces de rede que fazem parte do seu cluster (quem cuida disso é o switch e não a interface de rede). segundo, dedique placas de rede e uma vlan para o tráfego multicast, mais um rota no seu servidor linux. essas duas dicas deverão ajudá-lo – há também a possibilidade de alterar alguns parâmetros de buffer do udp no /etc/sysctl.conf, mas precisamos analisar as mensagens utilizando o tcpdump antes de parametrizarmos qualquer coisa.

    Já testou o ambiente sem utilizar o optimizer e um sun jdk ? Eu já tive bons resultados, devido o tipo da aplicação, utilizando o java da sun, por incrível que pareça..

  9. Ok vamos por parte, acho que estamos nos limitando mesmo a versão ultrabug do WLS10
    – Já estamos com time_wait setados em 10.
    – A parametrização foi feita com a ajuda do mission control
    – Infelizmente não podemos mais subir para a versão do jrockit (JEE5) – > (JEE6) por causa da versão do WLS
    – Infelizmente a parametrização do buffer não da um ganho suficiente para correr o risco de aplicar.
    – Acredito que o tunnig do jrockit já está bom
    – A unica coisa que não vi está setado é huge pages que na minha opinião uma máquina que tem 100GB guardando endereços físicos na TLB de 4kb é uma loucura já que a nossa querido heap já aloca querendo ou não, mas acho que vamos usa-lo no futuro!
    —————————————————————–

    Estamos preparando para migrar para o WLS12c 🙂 + JEE6 + Unicast

    Vamos aguardar posto noticias dessa migração!

  10. Como assim a parametrização foi feita com a ajuda do mission control ? Vc analisou os timeouts do gc no olho ?
    Aconselho a geração dos printgc/verbosegc para que seja analisados os gcs que rodam, o full e os outros.
    Tuning de jvm sempre pode ser melhorado, isso depende da aplicação e de seus componentes funcionais, banco e jms, por exemplo.
    – o ponto dos 4kb que me intriga, já que essa é a alocação default do s.o. linux. O huge pages, queira ou não queira, é responsável por aumentar este parâmetro. Eu sempre utilizado 2048kb — eu sempre consulto este artigo -http://andrigoss.blogspot.com.br/2008/02/jvm-performance-tuning.html
    – quantas jvm fazem parte do seu cluster ? Pergunto isso pq é recomendado utilizar multicast para cluster que possuam mais de 12 jvms. Claro que seguindo dos os pré-requisitos para que tenhamos um ambiente que utilize multicast funcional e estável.

    O papo está maneiro — podemos marcar um encontro em SP só para isso..

  11. Hoje utilizamos 20 managed servers divídos em 2 machines.
    Sim seguimos uma série de recomendações da própria Oracle para esse ambiente, nosso cluster utiliza-se de muitas JMS acredito que mais de 40 dividias em jvm’s que atendem front e back.
    Na verdade quem parametrizou não está mais na empresa e fiquei com uma série de dúvidas sobre gencon , eu que sempre trabalhei com java sun estou me deparando com esse ambiente que é de missão crítica que se tornou um monstro rs.

    Tenho duas dicas legais
    -> para calculos de hugepage.
    http://www.peuss.de/node/67

    ->Livro perfeito (melhor livro de tricks and tips de weblogic)
    http://www.amazon.com/Oracle-WebLogic-Server-12c-Administration/dp/0980798019/ref=sr_1_1?ie=UTF8&qid=1386895740&sr=8-1&keywords=oracle+weblogic+12c

    Sobre bater um papo, claro! pq não

  12. Aliás comprei esse livro do Dr. Frank Munz e também o do Dalton Iwazaki (Oracle WLS 12c Advanced Administration Cookbook), seguindo sua dica

    Minha opinião, o livro do Dr. Frank é muito mais tricks para administradores experientes, já o Dalton escreve de uma forma para abordar as melhores práticas, passando pelas instalação, configuração JMS, JDBC, monitoring, troubleshooting, perfomance, e security….

    No final, digo vale a pena comprar os 2.

    Alias no seu post não tinha o livro do Dalton para consulta, bom se quiser eu tenho posso upar e ti passar o link 😉

  13. “Eu sempre utilizado tenho 2048kb” , então mas com jvms de 6GB vai dar m*, pq vm.nr_hugepages=2048 vc está dizendo para SO para alocar no máximo 4GB, ou vc usa 1 jvm só ou usa 4 de 1GB e por ai vai, limitou a 4GB o SO.

    Mas a vatangem é clara, imaginemos um pool de 10GB na blocagem de 2MB vc teria um ganho na TLB de 2621440 para 5120 páginas, bom isso heim! fora que eu não tenho swap, se conseguir alocar e as memórias corretamente pode colocar swappiness 0 de boa que o SO se vira.

    Encontrei uma charada bem legal, o que é mais rápido, uma jvm 32 ou 64? sem procurar no google,heim

  14. Obrigado pelas dicas.

    O Livro do Dr. já foi lido de trás para frente e tenho uma série pontos a favor e contra. normal. Quando vc trabalha muito tempo com performance java, vc acaba vendo tudo de um jeito diferente, próprio..

  15. Trabalhei com o Dalton.. 🙂 Uma figura..

    O livro dos dois são bons, muito bons, por sinal, e mais do que recomendados.

    Eu estou escrevendo o meu, focado em performance and tuning para weblogic. Muito material e pouco tempo para escrever, mas estou seguindo firme e forte.

    Tenho os dois livros. 🙂

  16. Mas Tiago, neste caso vc alocará 8GB para huge. Não se esqueça que a JVM não aloca somente 6GB de ram para os seus processos. Em média, o JAVA utiliza mais 30% de ram do SO por causa das shared libraries… C é foda.. isso é até uma discussão/artigo que estou preparando. 🙂

Deixe uma resposta

Fechar Menu