2012-07-12 13 views
7

Antecedentes¿La forma en que traducimos nuestro sitio web genera problemas de rendimiento?

Nuestro sitio es un sitio de prensa y es visto por muchas personas en todo el mundo. Obviamente, esto significa que localizaremos el sitio en la mayor cantidad de idiomas posible. Se contratará un traductor profesional para cada idioma.

Cómo funciona nuestro sitio Actualmente

La forma en que hemos planeado para hacer esto es mediante el almacenamiento de una traducción para cada elemento de la página en la base de datos vinculada por un GUID. Por lo tanto, cuando la página se carga, las cadenas se extraen de la base de datos utilizando la Guía y las preferencias de idioma del usuario.

Tenemos varios documentos en nuestro proyecto que contienen traducciones al inglés. Como este:

public class StandardButtonToken : LocalisationToken 
{ 
    protected StandardButtonToken(string defaultText, Guid key) : base(defaultText, key) 
    { 
    } 

    public static readonly LocalisationToken Update = new StandardButtonToken("Update", Guid.Parse("8a999f5b-7ca1-466d-93ca-377321e6de00")); 
    public static readonly LocalisationToken Go = new StandardButtonToken("Go", Guid.Parse("7a013ecc-0772-4f87-9f1f-da6a878a3c99")); 
    public static readonly LocalisationToken Edit = new StandardButtonToken("Edit", Guid.Parse("c31be427-5016-475d-997a-96fa5ff8b51f")); 
    public static readonly LocalisationToken New = new StandardButtonToken("New", Guid.Parse("f72d365c-b18f-4f01-a6e4-b0cd930dc730")); 
    public static readonly LocalisationToken More = new StandardButtonToken("More", Guid.Parse("bd4da7df-afd2-481e-b6b6-b4a989324758")); 
    public static readonly LocalisationToken Delete = new StandardButtonToken("Delete", Guid.Parse("ab00ec14-4414-4cda-a8e2-4f03c9e7c5a8")); 
    public static readonly LocalisationToken Add = new StandardButtonToken("Add", Guid.Parse("01e44600-a556-4a07-8a2a-e69a1ea79629")); 
    public static readonly LocalisationToken Confirm = new StandardButtonToken("Confirm", Guid.Parse("4c50e91e-3e2f-42fa-97aa-9f1f6f077f09")); 
    public static readonly LocalisationToken Send = new StandardButtonToken("Send", Guid.Parse("24121766-f424-4d73-ac58-76f90d58b95c")); 
    public static readonly LocalisationToken Continue = new StandardButtonToken("Continue", Guid.Parse("dd2ca0e5-8a35-4128-b2e8-db68a64a6fe5")); 
    public static readonly LocalisationToken OK = new StandardButtonToken("OK", Guid.Parse("9a359f93-7c23-44ad-b863-e53c5eadce90")); 
    public static readonly LocalisationToken Accept = new StandardButtonToken("Accept", Guid.Parse("3206a76b-1cd7-4dc3-9fff-61dfb0992c75")); 
    public static readonly LocalisationToken Reject = new StandardButtonToken("Reject", Guid.Parse("f99c6a9c-6a55-4f55-ac4b-9581e56d18d3")); 
    public static readonly LocalisationToken RequestMoreInfo = new StandardButtonToken("Request more info", Guid.Parse("19f3d76b-dafa-47ae-8416-b7d61546b03d")); 
    public static readonly LocalisationToken Cancel = new StandardButtonToken("Cancel", Guid.Parse("75617287-5418-466b-9373-cc36f8298859")); 
    public static readonly LocalisationToken Publish = new StandardButtonToken("Publish", Guid.Parse("efd87fd4-e7f1-4071-9d26-a622320c366b")); 
    public static readonly LocalisationToken Remove = new StandardButtonToken("Remove", Guid.Parse("f7db5d81-5af8-42bf-990f-778df609948e")); 
} 

Cada vez que creamos una página nos aseguramos de que los botones utilizan estos símbolos en lugar de escribir manualmente el texto. Entonces, si decidimos que necesitamos un nuevo botón, agregaremos un nuevo token en el siguiente archivo y cuando el sitio se ejecute por primera vez, se comprobará si existe en la base de datos y, de no ser así, se creará.

Por lo tanto, en lo que se refiere a la traducción, enviaremos estos tokens a los traductores y solo cambiarán el texto. Esto se agregará al sitio en el idioma correspondiente y la página llamará a la traducción correcta en función del idioma seleccionado.

problema/pregunta

Nuestros signos traducción tiene el texto predeterminado como cadenas, pero estoy preocupado de que el servidor tiene que cargar todas estas cadenas de texto en la memoria en el arranque. En realidad, solo se usan para almacenar la traducción en el DB y nunca se usan en el código, por lo que creo que podría ser un desperdicio. En cambio, creo que podríamos llamar estas traducciones por separado cuando sea necesario, quizás desde algún tipo de tabla de búsqueda que no esté en la memoria.

Así que la pregunta es. ¿La forma en que estamos haciendo esto va a causar problemas de rendimiento?

Si es así, ¿alguien puede sugerir alguna solución mejor?

En total hay 1000 de estos tokens en nuestro sitio.

Google no me ha sido muy útil en esta ocasión, por lo que cualquier consejo sería muy apreciado. He intentado tan duro como puedo decir esto para que tenga sentido. No es fácil de explicar.

Gracias de antemano por cualquier ayuda que puedan proporcionar las personas.

+2

por qué no intenta utilizar ** recursos ** archivos ... vea esto (http://msdn.microsoft.com/en-us/magazine/cc163566.aspx) – Yasser

+0

Desafortunadamente los archivos de recursos no son una opción como tenemos que ser capaces de cambiar cosas sobre la marcha y no tener que volver a compilar. –

+0

según entiendo de wat que leo ... necesita localización para los botones ¿no? – Yasser

Respuesta

3

Actualmente estoy trabajando con un equipo en un proyecto en el que tuvimos una situación similar. Nuestro proyecto es una aplicación basada en cliente/servidor. La base de datos con nuestras traducciones se basa en el servidor y todos nuestros controles tienen valores en inglés predeterminados. Originalmente, cuando se abría una nueva ventana, leíamos la base de datos y sacamos las traducciones necesarias y traducimos los controles. De esta forma, solo los valores que necesitábamos se traducían en memoria y solo mientras esa ventana los necesitaba. Cuando se cerró la ventana, la memoria se recuperaría utilizando la recolección de basura.

Lo que descubrimos fue incluso con todas las traducciones para cada botón, etiqueta, encabezado de columna, etc ... para todo el sistema se cargó en la memoria donde solo tratamos con un par de cientos K. Al final lo que hicimos fue:

  1. el usuario inicia sesión en:
    • si predeterminado a otro idioma además del Inglés una tabla de datos está configurado en la memoria y rellena con las traducciones de todos los controles de usuario en nuestro sistema desde el servidor.
    • Esta tabla de datos tiene una clave principal para ayudar a mejorar las consultas en su contra. Mientras la aplicación esté abierta, esta tabla de datos existe.
    • Cada vez que se crea una instancia de un control de usuario, se ejecuta un método que busca la traducción y la aplica.

El tiempo que tardó en conectar el usuario sí aumentó, pero sólo por unos pocos milisegundos en promedio.

Habiendo dicho todo esto, me pregunto si podría usar un diseño similar. Esta idea evitaría que el servidor rastreara las traducciones por sesión. Solo alimentaría la página al usuario.

  1. usuario inicia sesión en:
    • un objeto de tabla de datos se rellena con todas las traducciones para el sitio
    • WriteXML() se llama
    • el XML resultante se envía al cliente
  2. Cuando el usuario navega a una nueva página:
    • se llama a un script del lado del cliente que utiliza el XML para traducir la página en la máquina del cliente.

Se podría añadir un poco de almacenamiento en caché para que el XML solamente se reemplaza cuando su sitio se actualiza o simplemente podría haber cada usuario descarga el código XML cada vez que al iniciar la sesión. De cualquier manera, quita la carga del servidor.

+0

Una opción interesante, voy a tener una idea sobre esto, gracias Chris! –

+0

Aunque no he decidido si usar esta respuesta, es la mejor de las dos y por lo tanto puedes tener la recompensa. –

3

Ignorando otras implementaciones y centrándose en la configuración que está utilizando, la respuesta es "sí" y "no".

Sí, puede haber problemas de rendimiento con el método que está siguiendo si aumenta el número de solicitudes entrantes y especialmente a medida que aumenta el número de tokens. Esta relación se puede explicar fácilmente como "cuantas más solicitudes ingresen, más trabajo debe hacer el servidor. Cuantos más tokens existen, más trabajo debe hacer el servidor. Si aumentan las solicitudes y los tokens, está explotando. la cantidad de trabajo que el servidor tiene que hacer."

El" no "se puede lograr al agregar a su solución actual. Puede agregar un caché a su configuración que guardará las páginas traducidas para que el servidor no tenga que consultar la base de datos o traducir cada página Por ejemplo, si tiene una página mypage.aspx que contiene 20 tokens traducibles, deje que el servidor la traduzca la primera vez y luego guarde el archivo traducido como, por ejemplo, /localized/mypage.EN.html y todas las solicitudes futuras (si la página original no se ha modificado) o no se han agregado nuevos tokens) se enviará la página en caché en lugar de volver a traducir cada vez.

Además, puede hacer que el servidor genere todas las traducciones cuando la página se actualice o se actualicen en lugar de esperar fo r una solicitud de cliente para entrar.

+0

Ya almacena en caché, así que tal vez esta solución esté bien después de todo –

+0

Si se almacena en caché, no debería haber problemas de rendimiento pendientes: será una traducción única (cada tiempo que necesita ser actualizado, por supuesto). Además, si hay un retraso notable al cargar una página que ya debería estar en caché, el problema sería con los métodos de procesamiento de solicitudes y no con el código de localización. – newfurniturey

+0

Pruebe dotTrace, justTrace o similar herramienta de perfil de memoria. Le dirá la respuesta y también señalará los métodos que están "calientes" (es decir, que necesita trabajar para aumentar el rendimiento). – turtlepick

Cuestiones relacionadas