Desempenho com grande cache

[moman]

Actualmente tenho o meu sistema configurado para limpar todo o cache a cada semana. Com um cache vazio, meu banco de dados é de cerca de 1.1GB, enquanto com um cache cheio, trata-se de 4,5 GB.

Tenho notado que quanto maior o cachê, quanto maior a minha carga média servidor recebe. Em um determinado momento meu fórum tem entre 650 e 1300 usuários online, mas isso não parece afetar a carga tanto quanto o tamanho do cache.

Com um cache grande, carga do servidor é 3,3-3,8, enquanto que com um vazio, ele permanece na faixa de 2,0-2,5. Isso não é mau de todo, como eu tenho um servidor 16-core, mas eu estava apenas querendo saber se tal comportamento é de se esperar com o tamanho do banco de dados flutuantes!

Obrigado,
Adão

[vBET]

vBET tem índices para as tabelas de cache mais rápido e usa motor de MySQL para chapéu - MyISAM. Portanto, temos melhores escolhas para o cache DB. Diferença toda que você observa não está na lateral do vBET, mas no lado do MySQL, que executa consultas. Dá-lhe índices de resposta mais rápidos e assegura que o tempo de resposta não vai dramaticamente com maior quantidade de dados. MySQL ainda tem que pesquisar índices maiores e como eu acho que é preciso mais recursos. É por isso que você percebe maior carga de servidor.

Também - quando a tradução estiver em cache, então ele é retirado de lá. Se não, então Google é convidado para a tradução. É preciso mais tempo, então, mas a maioria provavelmente leva também menos recursos do seu servidor. Demora mais tempo porque não há comunicação com servidor do Google que leva tempo, não há tradução que leva tempo e não há o envio de resultados de Google para o seu servidor, que também leva tempo. Demora menos recursos, porque o servidor está esperando por resposta de forma passiva e quando chega lá é só descompactar simples da resposta. Ficando tradução a partir do cache é muito, muito mais rápido - tradução já está feito e é em seu próprio servidor, ainda que precisam ser tomadas a partir de banco de dados, consulta têm de ser executados, MySQL leva um pouco de CPU e memória para isso.

Assumindo - usando cache é idéia muito boa. Se você vai sentir que o servidor tem problemas com que você pode experimentar para desabilitar o cache para alguns idiomas e comparar o desempenho do servidor. Não aconselhamos a remover de cache completamente.

[moman]

Isso é sobre o que eu esperava

O desempenho é bem agora, só que nunca a carga foi muito maior do que 2.0 antes vBET. Eu acho que vale a pena, embora!

Enquanto a carga estiver abaixo de 16,0, em seguida, o servidor não é tributado, então acho que estamos bem

[Konstantin]

É possível ou necessário para armazenar o cache em um arquivo - para reduzir a carga sobre o banco de dados MYSQL?
Eu só uso duas línguas como o número de posts muito e não querem um grande tamanho do banco de dados

Haverá um site melhor com o trabalho vbet após a instalação eaccelerator nginx,?
Já pensou em refazer o módulo para acelerar os seus trabalhos em fóruns de grande porte? Use o tamanho do cache de 1 a 2 GB no meu caso, não uma solução. Talvez existam maneiras de otimizar o trabalho?
É possível colocar o módulo vbet 3.3.1 + forum vb3.8.4 vBSEO 3.5RC2?
Por que tão caro versão sem direitos autorais? (220 $)
Eu uso vbet 2.4.3 e gostaria de comprar vbet 3.3.1. Meu fórum está vendendo links para trocas de SEO. Copyright duplicado referência a 15 000 páginas para mim certo - $ 90, mas dispostos a pagar 220 dólares é demais

[vBET]

É possível ou necessário para armazenar o cache em um arquivo - para reduzir a carga sobre o banco de dados MYSQL?
Haverá um site melhor com o trabalho vbet após a instalação eaccelerator nginx,?
Já pensou em refazer o módulo para acelerar os seus trabalhos em fóruns de grande porte? Use o tamanho do cache de 1 a 2 GB no meu caso, não uma solução.
Por que tão caro versão sem direitos autorais? (220 $)
Eu uso vbet 2.4.3 e gostaria de comprar vbet 3.3.1. Meu fórum está vendendo links para trocas de SEO. Copyright duplicado referência a 15 000 páginas para mim certo - $ 90, mas dispostos a pagar 220 dólares é demais
Eu só uso duas línguas como o número de posts muito e não querem um grande tamanho do banco de dados

Estamos planejando adicionar também cache de arquivos para vBET. Porque agora a nossa prioridade e mais esforços são em vBET4.0 temos nenhuma programação para a funcionalidade de cache de arquivos. Lembre-se que você pode personalizar quais idiomas irá trabalhar com cache. Então, se você quiser, pode usar o cache apenas para alguns de tradução que você vai disponibilizar. Também vale lembrar que a versão paga do vBET melhoraram cache de banco de dados de modo que é mais rápido que na versão gratuita. Há também outras melhorias na versão paga - em geral é mais rápido e tendo menos memória. Já temos clientes que estão usando com sucesso-lo em grandes painéis.
Nós não fez testes de desempenho com nginx acelerador portanto, não pode comparar.
Por favor note que a compra de licença de marca livre não é obrigatória e você pode sempre atualizar sua licença mais tarde.

[Konstantin]

Obrigado pela sua resposta. Nginx é um servidor como o apache. Aconselho você a ler - caching funciona melhor em php + nginx + eaccelerator e seu vbet pode ser muito mais rápido

[vBET]

Obrigado pela sua resposta. Nginx é um servidor como o apache. Aconselho você a ler - caching funciona melhor em php + nginx + eaccelerator e seu vbet pode ser muito mais rápido

Neste momento estamos muito perto de vBET4.0 lançamento e temos muito trabalho com isso. Se você quer que a gente teste vBET sob nginx, em seguida, por favor, abra nova thread na Solicitação de Recurso. Se nginx é executado php, em seguida, vBET vai trabalhar lá. Um problema se você deseja usar a tradução de SEO, links, em seguida, as regras de reescrita será necessário. Temos aqueles que estão preparados apenas para o apache .htaccess neste momento, mas se você não é capaz de reescrevê-lo, a partir de apache para nginx, em seguida, você sempre pode usar as ligações com linguagem atributo - isso é muito fácil. Você pode experimentar com versão gratuita para evitar problemas inesperados antes de comprar um pago.