Actualizado después de problemas con el servidor de carga![]()
Actualizado después de problemas con el servidor de carga![]()
¿Alguien tiene alguna idea de cuán grande sea el caché de archivos podría llegar antes de que tenga un impacto negativo en el rendimiento?
Memoria caché de base de datos de caché sólo traducciones. El contenido HTML no se entera. Así que cuando alguna página traducida se genera, entonces normal de la página se genera la primera y después de que se analiza y traduce. Durante la caché de traducción DB se utiliza y frases traducidas se toman desde allí. Sentencias justas - No HTML todo, porque cada vez traducciones puede ser diferente (es decir, los privilegios de usuarios, el contenido ha cambiado). Una página HTML puede tener cientos de frases para traducir - VBET toma el contenido entre las etiquetas HTML. Gracias DB caché de las traducciones no tienen que ser tomados cada vez de Google - lo que consume mucho tiempo - en vez de eso, los que se han tomado de su base de datos local. Sin embargo - página normal que se genera y después lo tradujo.
Caché de archivo completo para visitas sólo funciona para los huéspedes. Gracias que no tiene que preocuparse de que los usuarios con diferentes privilegios y ver las cosas diferentes. invitados verá el mismo contenido. Debido a que no tiene que analizar y traducir los resultados pieza por pieza cada vez que - podemos simplemente hacer una salida de tiempo y memoria caché de HTML completo. Así que en este caso, cuando la página completa no se almacenan en caché, o memoria caché el contenido es demasiado viejo, a continuación, la traducción normal se produce - como se describe anteriormente. Pero esta vez en el mismo extremo de la salida HTML completo está escrito en el archivo. Así que la próxima vez que la misma petición proviene de clientes que no generan incluso el contenido normal de la página - simplemente flujo de alojamiento ya archivos HTML almacenados en caché. Es por eso que se ahorra gran cantidad de consultas SQL, la CPU y la memoria. Acabamos de dar al contenido de usuario desde un archivo estático. Por eso es importante para determinar cuánto tiempo esta caché es válida. Porque si algo va a cambiar - es decir, después de nuevo se llega a hilo, y luego los clientes no verán este nuevo cargo hasta que el archivo ya en la caché expire. Después de que durante la siguiente petición, la página de nuevo normal, se generarán, traducido y caché - y esto los invitados verán el contenido, es decir durante una hora (configurable). No se ve ningún cambio hasta que el archivo caché expire de nuevo. Por supuesto, los usuarios van a ver todo, ya que sólo funciona para los clientes (tanto para los robots también, porque los robots rastreen tu foro en calidad de invitados).
¿En qué lo ayuda y en caso de cualquier duda preguntarse - con gusto se la describe más![]()
Será, seráLa mayoría de cosas nuevas son ya probadas allí. Justo tenemos más para hacer en caso de Archivo Lleno Cache para Huéspedes encima vB4, porque apoyamos allí traducción de más clases de URLs para vBSEO y también Amistosos URLs de vB. Y de todo de aquellos lo tenemos que probar muy cuidadosamente y todavía tiene que implementar soporte de más temprano redirigir para algunos de aquellos. También - utilizaremos este tiempo adicional para comprobar cualesquier asuntos posibles con Archivo Lleno Cache Para Huéspedes (cuál está considerado BETA ahora) en vB3 foros. Lo probamos bien, pero es siempre mejor de preocuparse más sobre calidad buena
![]()
en el archivo /images/vbet/flags/vbet.css
Por favor, describa mejor lo que significa "raro" - tal vez seamos capaces de ayudarle. También le aconsejamos que se utilizará para tales cosas con el plugin de Firefox Firebug - que permitirá a mostrar exactamente lo que los estilos CSS se utilizan para los elementos especificados. Es muy útil![]()
Yo sé que para todo el mundo su versión es la más importanteY no quiero discutir con ese
En este caso vBET3.x es anterior por muy buenas razones: CALIDAD. Añadimos funcionalidad nueva e importante (Caché de archivos completa para personas de movilidad) en esta versión, y era mucho más fácil de añadir en vB3, porque no hay URLs Amigables, y que se traduce solo hilo de Url para vBSEO. En caso de vB4 es más complicado - Friendly URLs deben ser compatibles, y que se traduce mucho más tipos de direcciones Url. Poner primero en vB3. nos permitió probar muy bien en verdaderos foros, compruebe que se está trabajando muy bien, tal vez se muestran algunos de los errores antes de que se vaya a vB4. Y después estamos completamente seguros de que todo está bien, todavía tenemos que añadir en vB4 adicional de apoyo (Friuendly Url, más translted Url). Es por eso que esta vez vBET3.x es anterior y todavía tenemos 2 semanas para vBET4.x. Y gracias por lo que obtendrá la solución que tienen muy buena calidad, ewen si es más complicado thatin caso de vB3
No debe haber tal cosa como el impacto en el rendimiento negativo debido a la caché de archivos. Se debe a que la caché de archivos no crece ... Creamos un archivo separado para cada URL solicitada. Por lo que cada archivo de caché de archivos estáticos es simplemente HTML (salida en caché para la solicitud). Cuando el servidor de caché VBET más y más, simplemente crea más y más archivos. Así que cada vez que el fichero se lee:
1. Se lee único resultado de esta URL en particular
2. Incluso no lo leen en la memoria - simplemente se debe transmitir al cliente que utiliza la función de PHP: readfile
Debido a que incluso si su página de resultados es muy grande - archivo de caché que también es grande, no tendrá ningún impacto en el rendimiento negativo, ya que sólo transmitirá este archivo sin ni siquiera leer un entero en la memoria. Por lo que verá las ventajas no desventajas.