Ver Versión Completa: Resolto Máis problemas de carga
Ok, entón eu fixen unha morea de probas.
Durante un período de 24 horas a miña carga aumenta de forma constante ao 30,00 's
A reinicio do servidor fixa-lo por máis de 24 horas.
Se eu desactivar o mod non ter este problema.
Non diga que con mod desactivada hai menos tráfico, que non é verdade, google aínda envía o tráfico mesmo con mod desactivado segundo as miñas estatísticas.
Por favor, explique, a carga está me deixando tolo.
Soa como bots están batendo as páxinas traducidas cando o mod está conectado. Ten que mirar para optimizar apache ou conseguir un servidor con máis poder de CPU. Vostede está executando vboptimise ou calquera tipo de mecanismo de caché, como o memcached?
O feito é que o meu foro está 30.000 unique por día, se eu desactivar a carga mod cae instantaneamente, e bots e os usuarios son aínda mostran páxinas de forma aínda están esixindo de alimentación do servidor, é simplemente que amosa páxinas traducidas usar os recursos 10x de páxinas estándar VB da base de datos normal. É mal escrito o código, e debe ser corrixido! Os outros mods nunca o fixo, só vbet, desexo que eu non cambiou máis, pero vai volver agora é demasiado tarde. : Tolo:
El realmente parece que está a empregar nun servidor de feble potencia. Eu estou nunha máquina Nehalem 8-core (así que nós estamos mirando para 8 núcleos máis virtual, debido á HT, para un total de 16). Eu tamén amplamente óptimo esta máquina usando as miñas propias técnicas, así como os punteiros do persoal da vbulletin.com.
vBET levanta a miña carga de preto de 2,5 a 3,0-3,5, dependendo do número de usuarios, e iso, obviamente, crece a base do tamaño do caché. Sen embargo, eu non creo que iso é moi malo en todo, como a miña canción de usuarios simultáneos dun 800 moi elevado para un aínda maior 1.200.
Ola:) Por suposto, a tradución debe levar algúns recursos - non hai maxia. Significa traducir páxina tomar resultado de saída e cambia-lo. Debido a que a tradución sempre levar máis que páxina normal.
Eu entendo que non está moi feliz de ter máis carga do servidor, pero teña en conta que vBET está tomando recursos só para a tradución. Para as páxinas normais, engade bandeiras só. Así, toda a carga adicional este vén de tráfico adicional a páxinas traducidas. Como escribiu o seu tráfico non caeu inmediatamente despois da desactivación vBET (se ten un tempo, polo que vai diminuír despois de desactivar - confíe en min) ea carga do servidor é menor - é obvio - os robots aínda están engatinhando URLs para páxinas traducidas, usuarios aínda están atopando nas ligazóns de Google para as súas páxinas traducidas. Entón aínda ten o tráfico mesmo, pero agora so as ligazóns traducida é simplemente duplicada contido - páxina normal que non é traducido. Se queres ficar con vBET desactivado recomendamos para engadir regra no seu arquivo htaccess. Que ha redireccionar todas as páxinas traducidas para unha normal, se non pode perder o seu SEO por mor do contido duplicado.
Teña en conta que nós xa planeou apoio doutros sistemas de caché e algoritmos de tradución son inmediatamente óptimo. É dicir, só descubrimos como diminúe drasticamente o rendemento PHP cando se traballa en grandes secuencias de caracteres e nós modificamos o noso algoritmo. Ela xa está liberada en vBET 4.2.0 con opcións de configuración adicional. E imos pasar todas as melloras tamén para vBET 3.x, que aínda está soportado:)
Eu entendo que na súa opinión, o noso código é feble. Eu non sei sobre o que está baseándose súas expectativas. Temos máis rápida de tradución para mod vB - non hai nada que funciona mellor. Tradución terá algúns recursos eo noso mod leva menos que calquera outro. Podes ver como vBET rápido pode traballar en moitos foros. Se ten problemas no seu servidor, polo que debes considerar o cambio de configuración ou a adición de recursos do servidor. Non vai poñer 20 litros de auga en balde 10 litros.
O noso concibir é: "Temos moito que cambiar". E é por iso que estamos experimentando, cambiando algoritmos de perfís, e gastar moito tempo buscando solucións que esixen menos recursos. Aínda non sabemos mod que pode ser calquera competición para vBET e hai algúns mods outra tradución. Fixemos moitos cambios algoritmo que tivemos que trow afastado porque non axuda, durante este proceso, tamén descubrimos moitas melloras. Pode que a súa impresión baseándose en cuestións de servidor, pero por favor, considere tes algunha solución mellor? O que podería dar unha información que talvez vBET non é solución errada porque está a traballar en miles de foros, quizais só está intentando poñer 20 litros de auga en balde 10 litros. Aínda así - temos moito que cambiar e lista de TODO grande na sección de optimización (preto do 70% para probar axudará ou non):) E está certo 100% - podemos facelo mellor, imos e estamos facendo todo o tempo:) Só ten que agardar a que mover todas as melloras que fixemos durante a implementación vBET4.x:)
Se eu te podo dar algúns consellos - comprobe como pode optimizar vBET: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html
Especialmente considerar a desactivación dalgunhas linguas e bloqueando páxinas spam polo robots.txt
Cal é o tempo de resposta para páxinas traducidas? Cal é o seu uso de CPU? Cal é o seu uso de memoria? Se é aceptable, polo que non ten nada para se preocupar. Moitas veces a xente está con medo, aumentando a carga do servidor, e mesmo non sei que iso significa. A carga do servidor 10 veces máis non significa 10 veces máis recursos utilizados. Significa só que máis threads están agardando na fila, o que é perfectamente normal, xa que agora os seus segmentos teñen que agardar unha resposta de Google se algunha tradución non é almacenado en memoria aínda. Entón thread está esperando por resposta de Google e leva no CPU AT ALL durante este tempo. Debido a que a súa carga do servidor será maior, aínda que vBET non aguantou recursos en todo (o que naturalmente non é posible).
Sobre bater servidor - é obviamente o problema do servidor. Isto acontece periódicamente. Eu tiven problema semellante no meu servidor. Foi causado por un erro de Apache para un segmento Apache foi crecendo e crecendo co uso de memoria ata que a memoria enteira foi consumida ans servidor caché. Só un segmento se comporta así - os outros segmentos Apache foi normal. Xoguei con Apache configuración e problema está resolto. Eu creo que o Apache só tiña un baleirado de memoria - como eu me lembro engada menor valor de peticións que pode ser detido por unha lista de correo. Houbo tamén outros cambios. Suxiro comprobar o seu uso de memoria e monitor-lo por algún tempo. Tamén pode ser útil para comprobar cantidade media de memoria utilizada por un fío de Apache, fixo algúns cálculos e axuste o valor apropiado de threads máximo para Apache.
Se ten algunha dúbida é só pedir máis, por favor:)
Hey - Eu só estaba no seu foro traduce ULTRA Rápido ... Entón o que está reivindicando e por que actitude tan irritado con vBET, cando ten un servizo de tradución super rápido? ...
Por favor, considere que a carga do servidor significa. Comprender o seu significado pode ser moi útil para entender o que ocorre no servidor e como pode estar relacionado con temas que están agardando na fila non porque non ten recursos, pero están á espera de resposta doutro servidor (Google neste caso).
Na miña opinión ten super traducións rápidas e ten nada que se preocupar:)
Teño está a construír sitios de 10 anos, teño plena conciencia de carga 10x non significa recursos 10x, deixe de me trate como un idiota e coller alimentándose me de lixo. Os feitos son fríos con este mod vs o mod outras liberar a súa carga é mega. E nos horarios de pico meu sitio agora é lento e sen resposta. Si, traducir páxinas rápido off-Peak, pero a un custo dun servidor lento ao final do día. Eu teño un quad core, raid 15k SAS servidor, que é optimizada moi ben, el executar 0,50 durante todo o día antes que con gran tráfico. É o código VBET que engade carga e fai que o servidor lento en horarios de pico, é un feito, non é aumento do tráfico, eu tiven o mesmo tráfico e bots antes eo servidor lidou moi ben, é o produto de tradución. Período. Apresuraron-se e resolve-lo, realmente non quere pagar máis 300 quilos por mes para unha actualización do servidor para rodar un MOD lol.
Cantos idiomas ten activado? Cantos artigos ten? Ten vBSEO e sitemap xerador instalado? Cantos bots están accedendo ao sitio ao día?
Ola!
32 idiomas habilitado.
100.000 artigos.
vBSEO e sitemap instalado.
sitemap plugin di 1000.000 páxinas indexadas ao día.
O feito é que, se eu desactivar o mod e reiniciar o servidor bot, e os usuarios aínda están acertando meu servidor a mesma de antes, as mesmas páxinas aínda están en no índice google e, así, eu recibín o mesmo tráfico habilitado ou non.
A única diferenza é que co mod desactivado os bots e os usuarios de Google obter a páxina en inglés, así, o tráfico é idéntica, a única diferenza é que eles non están a ver unha páxina traducida, evitando así os problemas da base de datos mods.
Claro como o día para min ese mod foi liberada sen probas apropiados, e claramente o propietario non está interesado en abordar as cuestións.
Fallar.
Michael, está mal, esa carga non é causada por un aumento no tráfico, é causada pola lectura e escritura traducións para mysql.
Se o equipo vBulletin pode ler e escribir para mysql con carga baixa por que non pode vostede?
Pobres código do meu amigo.
Teño está a construír sitios de 10 anos, teño plena conciencia de carga 10x non significa recursos 10x, deixe de me trate como un idiota e coller alimentándose me de lixo. Os feitos son fríos con este mod vs o mod outras liberar a súa carga é mega. E nos horarios de pico meu sitio agora é lento e sen resposta. Si, traducir páxinas rápido off-Peak, pero a un custo dun servidor lento ao final do día. Eu teño un quad core, raid 15k SAS servidor, que é optimizada moi ben, el executar 0,50 durante todo o día antes que con gran tráfico. É o código VBET que engade carga e fai que o servidor lento en horarios de pico, é un feito, non é aumento do tráfico, eu tiven o mesmo tráfico e bots antes eo servidor lidou moi ben, é o produto de tradución. Período. Apresuraron-se e resolve-lo, realmente non quere pagar máis 300 quilos por mes para unha actualización do servidor para rodar un MOD lol.
Eu entendo que xa estaba familiarizado con información sobre a carga do servidor que che dei. Ten en conta que eu non teño coñecemento sobre no; avanzada é cada un dos milleiros dos nosos usuarios e cada vez que vou dar información ass completa, xa que pode ser útil. Non significa que eu estou te tratando como idiota - isto significa que me preocupa o que lle dá informacións que poden ser útiles para ti e avaliación da súa condición de servidor. Por favor, me apunte o mod outras libres que está falando terei pracer en facer algunha comparación:) Tamén en calquera momento vostede é libre para escoller a mellor solución para vostede.
Eu comproba o foro de novo e de novo parece responder moi rápido. Por favor, me dea estrutura mellor momento para poder observar o que está escribindo sobre as súas respostas lento no hora punta.
Se quere comprobar como o seu tráfico alterado debido a vBET - por favor, xerar algún informe que debería amosar-lle todo o tráfico para páxinas traducidas - é o que gañou grazas á vBET.
Está absolutamente seguro que as traducións necesita recursos adicionais - non hai outro camiño e nunca vai atopar o produto que pode traducir a súa web sen ningún custo. Como eu xa mencionei máis tempo require á espera de tradución de Google cando non está en cache, e durante este tempo a súa temas teñen que agardar unha resposta que teñen maior impacto na carga do servidor. É posible axustar o tempo de caché maior para vivir - entón traducións moitas veces necesaria xa está na caché. Pero para non traducións caché calquera produto vai ter que esperar para a tradución. Non hai outra maneira.
Teña en conta que pensa que ten que ser dobres para ser capaz de reparalos lo.
Como eu xa escribín para ti, estamos constantemente a mellorar o desempeño vBET. E eu xa escribín para ti, que temos melloras de rendemento que está preparado agora en fase beta en vBET4.x. Hoxe imos lanzar a versión vBET4.x novo con melloras de rendemento adicional. E cando os bugs para quen (se) serán corrixidos, imos mover esas melloras vBET3.x Non é necesario para empurrar.
Tamén ninguén o obriga a pagar máis 300 quilos por mes para un servidor - está facendo as súas propias decisións e ten moitas opcións aquí. Ata diminuíndo o número de linguas admitidas, ou mesmo o cambio a outro produto que mencionar é moito mellor. Entendemos completamente que as solucións que está a usar debe caber ás súas necesidades e posibilidades. Temos o pracer de dar aos nosos clientes produtos cada vez mellores. E somos conscientes de que en situacións en que petición debe agardar formulario de resposta doutro servidor a carga do servidor será maior, non importa que as solucións que imos usar. Teremos o pracer se queda co noso produto e configuralo para caber yo súas posibilidades. E teremos o pracer de lle dar unha man nesta área:)
Teña en conta que só deu nova solución para integrar co Sitemap Generator. Se está integrada - por favor, consulte as instrucións de integración de novo aquí:
Ela aumenta dramaticamente a velocidade de xeración de sitemap (no noso foro con máis de 12 veces).
Claro como o día para min ese mod foi liberada sen probas apropiados, e claramente o propietario non está interesado en abordar as cuestións.
Fallar.
Se ten dúbidas sobre proba adecuado propoño comprobar o historial de vBET - foi probado por centos de foros real antes de avanzada para versión de pago:)
Sobre o tratamento da cuestión. Sinto moito. Eu supuxo erradamente que o que lle dá a primeira resposta esta información, estaba claro que estamos a tratar o tema:
Teña en conta que nós xa planeou apoio doutros sistemas de caché e algoritmos de tradución son inmediatamente óptimo. É dicir, só descubrimos como diminúe drasticamente o rendemento PHP cando se traballa en grandes secuencias de caracteres e nós modificamos o noso algoritmo. Ela xa está liberada en vBET 4.2.0 con opcións de configuración adicional. E imos pasar todas as melloras tamén para vBET 3.x, que aínda está soportado:)
...
O noso concibir é: "Temos moito que cambiar". E é por iso que estamos experimentando, cambiando algoritmos de perfís, e gastar moito tempo buscando solucións que esixen menos recursos. Aínda non sabemos mod que pode ser calquera competición para vBET e hai algúns mods outra tradución. Fixemos moitos cambios algoritmo que tivemos que trow afastado porque non axuda, durante este proceso, tamén descubrimos moitas melloras. Pode que a súa impresión baseándose en cuestións de servidor, pero por favor, considere tes algunha solución mellor? O que podería dar unha información que talvez vBET non é solución errada porque está a traballar en miles de foros, quizais só está intentando poñer 20 litros de auga en balde 10 litros. Aínda así - temos moito que cambiar e lista de TODO grande na sección de optimización (preto do 70% para probar axudará ou non):) E está certo 100% - podemos facelo mellor, imos e estamos facendo todo o tempo:) Só ten que agardar a que mover todas as melloras que fixemos durante a implementación vBET4.x:)
Se eu te podo dar algúns consellos - comprobe como pode optimizar vBET: http://www.vbenterprisetranslator.com/forum/general-discussions/243-vbet-performance.html
Especialmente considerar a desactivación dalgunhas linguas e bloqueando páxinas spam polo robots.txt
Eu me sinto totalmente responsable de este malentendido. Unha vez moi triste. Por favor diga connosco, o camiño que temos para lle dicir que estamos mellorando vBET o tempo, e como podemos asegurar-lle de novo que vBET3.x terá outra melloras de rendemento, para facelo claro que estamos a tratar o tema? Estaremos sempre moi ben mellorar a nosa forma de comunicación co cliente:)
Michael, está mal, esa carga non é causada por un aumento no tráfico, é causada pola lectura e escritura traducións para mysql.
Se o equipo vBulletin pode ler e escribir para mysql con carga baixa por que non pode vostede?
Pobres código do meu amigo.
Xa notou que planeamos soporte de sistemas de caché (arquivos e motores existentes). Por favor, considere cales son as súas intencións neste fío e que está indo na dirección correcta para mellorar o estado do servidor tour - aínda é o punto.
A súa cuestión asume que a carga é causada pola comunicación co mysql. Podes por favor darnos esta fonte de diagnosticar? Imos estudala la feliz:)
Eu tiven o mesmo problema, Sever sobrecarga. Finalmente eu desactivado VBET do meu foro e todo está normal agora. :)
Eu tiven o mesmo problema, Sever sobrecarga. Finalmente eu desactivado VBET do meu foro e todo está normal agora. :)
Cal versión usou? Por favor, actualice a última versión - fixemos melloras de rendemento óptimo. Moitos usuarios escribiron as súas grazas a que, vendo gran diferenza - especialmente na área de carga do servidor:)
Editado:
Acaba de comprobar o seu foro e vBET está a traballar alí - por favor, non escriba declaracións falsas sobre a condición vBET.
Automatic Translations (Powered by Google, Microsoft®,
Yandex, SDL Language Cloud, IBM Watson and Apertium):
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.
