Informações do Servidor [Uptime: 7 dias, 9 horas, 32 min e 9 seg]

meu server quando um cliente baixa um arquivo de texto ou pdf vem outro que não tem nada a ver com o cliente baixou, o que pode ser isso. ate pelo meu hotmail baixei um pedido mandado por e-mail e veio uma lista de compra de uma cliente minha, coisa sem nada a ver com o que deveria. e as vezes fica muito lento a navegação.

!! UM PROBLEMA QUE EU AINDA NÃO TINHA PASSADO !!

Guilhere ou alguém que saiba...tenho um script dentro do netwatch da RB monitorando o link principal e quando ele caí entra outro link automaticamente, neste exato momento caiu o principal e entrou o reserva porém apareceu o seguinte erro do Speedr:

O sistema retornou: (61) Connection refused

Este processo de troca de link já aconteceu em outras versões e nunca apareceu esta mensagem no Speedr, o que pode estar causando isto pessoal?

Everton, existe possibilidade de ele continuar encaminhando algumas requisicoes pra outra routing mark?

Esse erro na verdade é isso mesmo, ao tentar conectar o socket do speedr para o servidor de origem (na internet), a conexao foi recusada na porta solicitada.

Veja que o speedr se utiliza de algumas tecnicas do HTTP 1.1 que podem estar relacionadas com isso, principalmente relacionado a PIPELINING e conexoes persistentes (KEEP-ALIVE), onde o speedr abre um unico socket com o servidor de origem, e encaminha diversas requisicoes/respostas dentro do mesmo socket.

Quando existe a comutacao de link, a conexao ja estabelecida ou recem-estabelecida pelo speedr nao podem ter ficado dentro do link anterior, que estava down?

Guilherme... acho que é por aí mesmo, inclusive o Link reserva é de outra operadora, estou incrementando algumas coisas no script para evitar isto novamente.

Será que zerando as conexões da RB (firewall/Connections) antes de levantar o outro link poderia resolver/amenizar?

Outra coisa que lembrei é limpar a rotas dinâmicas da RB antes de levantar o link reserva, sei lá, aceito sugestões!

Outra opção, que inclusive apliquei agora, é desativar o Speedr quando entrar pelo link reserva, assim além de evitar "Connection refused" também evito de fazer cache com vínculos da outra operadora que não uso muito, me corrija se estiver errado!

Obrigado pelo retorno.

Everton, acho que zerando as conexoes da RB vai amenizar bastante o problema sim.

Em relacao a fazer cache com vinculos com outra operadora, vai ser OK, pq o conteudo que vem de uma vai ser servido quando der hit saindo pela outra tambem.

Ok Guilherme...Fiquei na dúvida sobre cache de operadoras diferentes (mesmo arquivo repetido no cache devido a endereços diferentes) porque nesta rede os link´s são ADSL´s então aparece na URL de arquivos armazenados do Speedr o endereço do cache da própria operadora.

Inclusive tirei o LoadBalance em redes com link´s ADSL que tem Speedr, inicialmente obtive melhores resultados, tanto na estabilidade como menor consumo de hd no cache, sei lá, posso estar errado.

Acredito que na outra rede, com link dedicado, não teria esta possibilidade de repetir arquivos no cache.

Como foi falado por alguns dos colegas anteriormente, realmente alguns vídeos não adiantam, fica obrigado a voltar para o início.

Henrique, meu server tem processador AMD X6 1100 com 32gb de memoria, estou pensando em mudar por um Intel 3930k, pois consegui uma placa asus com 8 slot ddr3, ai posso colocar 64gb de memoria. Porem um amigo me falou que o speedr funciona bem em cpu AMD 64bits, e em Intel nem tanto....porem vi vários prints de outros usuários e muitos usavam Cpu Intel. Isso do cpu amd ser melhor procede? o que vc acha desse novo server que estou querendo montar, vou ter um aumento bom no desempenho?

FJB, a informação de que intel não funciona bem não é verdadeira, inclusive eu só uso intel que também é 64 bits. Mais desempenho depende do tráfego que vai passar, a cpu influência para tráfego acima de 30 Mbps ou 40Mbps e mais de 8000 conexões, e os 64 GB de memória ajuda a servir arquivos pequenos com mais velocidade e da um desempenho melhor para um numero maior de conexões.

Leonardo, nós estamos focados em problemas mais graves por enquanto, mas em breve iremos analisar e resolver tudo que for possível tecnicamente.