Infraestructura de Web
Proporciona escalabilidad para aplicaciones ASP.NET
Iqbal Khan
En resumen:
- Cuellos de botella de escalabilidad en aplicaciones ASP.NET
- Opciones de almacenamiento de estado de sesión
- Topologías de almacenamiento en caché disponibles
- Características de la caché distribuida es necesario
Contenido
Dónde están los problemas
¿Por qué existen estos problemas
¿Cuál es la respuesta?
Topologías de almacenamiento en caché
Opciones de diferentes
El mundo real
La popularidad de ASP.NET, el marco de aplicación Web de Microsoft, continúa creciendo por los límites dentro de la desarrollador, empresa y la jerarquía de TI y leaps. Hay un área de dificultad, sin embargo: escala aplicaciones ASP.NET fuera del cuadro simplemente no es posible.
Escalabilidad tiene dos significados en este contexto. Primero, tiene que poder controlar eficazmente cargas de usuario de pico porque todas las aplicaciones atraviesa picos y mínimos en términos del número de usuarios registrados en cualquier momento del tiempo. Al diseñar la infraestructura, desea diseñar la aplicación para que pueda controlar las cargas de pico como cargas de forma eficaz y tan rápida como nonpeak.
En segundo lugar, tendrá que pueda aumentar la capacidad total de su sistema. Hoy en día puede tener sólo 5.000 usuarios. Seis meses, un año hacia abajo de la carretera, puede tener 10.000 15.000 o 20.000 y, en unos pocos años podría acabar con 100.000 usuarios. Ser capaz de aumentan con el número de usuarios sin grinding la aplicación a detenerse es qué escalabilidad todo acerca de. Significa que se puede agregar más usuarios sin afectar negativamente el rendimiento de ninguna manera notable o, si hay cualquier posible degradación, debe ser en un rango aceptable.
Una típica aplicación ASP.NET se implementa en uno o más servidores Web que se vinculan juntos en una matriz Web, con un equilibrador de carga que distribuye el tráfico en todos los servidores Web. En teoría, los servidores Web más agregar, las solicitudes más debe capaz de procesar por segundo. La arquitectura de un conjunto de servidores Web está destinada a conceder escalabilidad a ASP.NET. Eso es la teoría; la realidad es un poco diferente.
El problema para las aplicaciones ASP.NET es que mientras tecnología Web proporciona una arquitectura elegante de conjuntos de servidores Web y de equilibradores de carga, las tecnologías de almacenamiento de datos no han mantiene hacia arriba. Sin duda puede escalar en una aplicación Web agregando más servidores o al aumentar la eficacia de los servidores individuales con más memoria y capacidad de CPU.
Pero como lo, almacenamiento de datos no es capaz de escalar en las mismas proporciones. Escala, pero no como mucho que el nivel de aplicación Web. En consecuencia, cualquier elemento de la aplicación ASP.NET asociada con almacenamiento de datos o acceso a datos es un potencial cuello de botella de escalabilidad. Más hasta el punto, un servidor de base de datos no se escala para sesiones o las aplicaciones de datos.
Dónde están los problemas
Echemos un vistazo a las acciones de acceso o de almacenamiento diferentes que tienen lugar dentro de una aplicación ASP.NET, comenzando por el almacenamiento de sesión. Para cada solicitud de usuario, una sesión se lee del almacenamiento de al principio y vuelven a escribir en el almacenamiento al final de la respuesta. Al principio de la solicitud de usuario, la página tiene que ejecutar y, para ello, necesita los datos de sesión. Los datos de sesión de todo, como un "objeto de sesión", se cargan para que la página, mientras ejecuta, hacer referencia a los datos. La página leer algunas de los datos desde el objeto de sesión. Colocará algunos datos más en el objeto de sesión. Todo esto ocurre dentro del proceso ASP.NET y no se estarán viajes de almacenamiento de sesión.
Cuando se realiza la página de ejecución, algunos tiene que se envían al usuario como resultado. La sesión probablemente se actualizó durante este tiempo de forma que la sesión ahora tiene que se vuelve a guardar el almacenamiento en. Se mantendrán almacenados hasta la siguiente solicitud de la misma sesión de usuario y el mismo proceso repite propio.
Desde perspectiva de un usuario, haga clic en un vínculo; en el momento en que el usuario ve la página generada a partir de ese vínculo, una sesión se ha leer y una sesión ha ha escribir volver al espacio de almacenamiento de una vez. Por lo que hay dos ida y vuelta a un almacenamiento de sesión que ha realizado la aplicación ASP.NET.
Ahora realiza las matemáticas. Si tiene 10.000 usuarios todas las páginas acceso al mismo tiempo, tendrá quizá 1.000 solicitudes por segundo. Haga clic cada usuario se va en algo cada pocos segundos, por lo que cada segundo que tendrá las solicitudes de al menos de 1.000 y probablemente más va al conjunto de servidores Web.
Supongamos que 1.000 o más solicitudes se van al conjunto de Web y cada solicitud que va a los resultados del servidor Web en dos viajes al almacenamiento de sesión. Desde una perspectiva de Web, esto significa que 2.000 viajes al almacenamiento de sesión. Puede ver qué rapidez puede aumentar la carga. Éste es un lugar que puede ocurrir un cuello de botella de escalabilidad.
Los cuellos de botella de escalabilidad también pueden ocurrir mientras se está ejecutando una página y se necesita leer o escribir algunos datos de aplicación. Vamos a utilizar compañía aérea vuelo disponibilidad como un ejemplo. El usuario hace clic en una página para buscar vuelos desde una ubicación a otra, que pueden como resultado varios viajes de lectura en la base de datos de la aplicación. A continuación, por supuesto, el usuario desea realizar una reserva de vuelo, lo que requiere algunos datos se coloca en la base de datos. Estos datos se denominaban datos de ésta y se almacena en la base de datos; esta operación de guardar podría realizar varios viajes de base de datos para almacenar varios elementos de datos.
Por lo tanto, podría, al final, Asimismo copia con el número de viajes de base de datos está 5, 10, 15 o 20 veces más que el número real de las solicitudes del usuario. Por lo que la carga en la base de datos es mucho más, y esto puede ser un cuello de botella importante.
Un cuello de botella de escalabilidad tercera incluye sobre si está utilizando un entorno de SOA (arquitectura orientada a servicios) y la aplicación hacen llamadas a otro nivel de servicio, que puede ser en el centro de datos o en un centro de datos diferentes.
La arquitectura de nivel de servidor normalmente implica un conjunto de servidores y, por tanto, es escalable de la misma manera que es la arquitectura de aplicación Web. Pero el nivel de servicio tiene los mismo cuellos de botella escalabilidad de la aplicación porque se basa en su propia base de datos.
Por lo que la aplicación tiene dependencias en otros servicios, que tiene dependencias en sus bases de datos, que a su vez tiene cuellos de botella de escalabilidad, y la cadena es sólo tan fuerte como su eslabón. Si un servicio no se escala debido a su base de datos de, no se puede escalar la aplicación (consulte la figura 1 ).
La figura 1 la base de datos se convierte en un cuello de botella a medida que crece el conjunto de servidores Web.
Realmente no importa si la base de datos es un gran sistema (mainframe) o una base de datos relacional. El acceso a datos o almacenamiento de datos simplemente no es capaz de escala, y no se puede mantener el ritmo la escalabilidad de la tecnología Web. Y las aplicaciones ASP.NET de ajuste de escala de evitar que estos cuellos de botella en el almacenamiento de datos.
¿Por qué existen estos problemas
¿Por qué no se puede escalar almacenamiento de datos? Vamos a tratar en primer lugar las tres opciones de almacenamiento de estado de sesión Microsoft ofrece: InProc, StateServer, SqlServer y. InProc tiene limitaciones. Se ha diseñado para utilizarse en un entorno de servidor único proceso único, y no funciona en un entorno de ASP.NET multi-process o de múltiples servidores. No se conserva la sesión.
Aquí es lo que ocurre. El usuario comienza en un servidor y se crea la sesión no existe. Si el equilibrador de carga, a continuación, envía al usuario a un servidor diferente, la aplicación no encontrar esa sesión, se cree el usuario es iniciar nuevas y pida su volver a iniciar una sesión en. Cada vez que un usuario hace clic en ningún valor, tendrá que iniciar sesión, por lo que no podrán continuar. La aplicación no funcionará.
Una forma puede resolver esto es mediante la característica "sesiones pegajosas", que le permite siempre enrutar la solicitud del usuario al mismo servidor para la aplicación encontrar esa sesión en el servidor.
También puede controlar InProc limitaciones creando un jardín Web no en el servidor. Hospedaje multiproceso en una única máquina es cuando la aplicación tiene varios procesos de trabajo ASP.NET que se ejecutan en el mismo servidor. Si evitar el uso de hospedaje multiproceso en una única máquina, hay sólo un proceso y que al menos permite InProc para utilizarse en un conjunto de servidores Web.
Estas dos soluciones son lejos de ideal, sin embargo. Sesiones pegajosas pueden provocar un cuello de botella de escalabilidad importante porque la carga en algunos servidores aumenta más que otros usuarios porque la longitud de una sesión de usuario no es uniforme. Algunos usuarios iniciar sesión durante únicamente un minuto, otros usuarios durante 20 minutos. Algunos servidores obtendrá una gran cantidad de sesiones, pero los se serán prácticamente vacía o libre o inactivo. Incluso si agrega más cuadros, no se mejora necesariamente el rendimiento.
Además, InProc tiene las limitaciones de memoria. Cada sesión en el proceso de ASP.NET requiere memoria. Medida que aumenta el número de sesiones, los requisitos de memoria del proceso de trabajo aumentar considerablemente. En una plataforma de 32 bits, sin embargo, hay un límite de 1 GB de memoria para un proceso de trabajo, y eso es un problema. No se puede aumentar los datos de sesión más allá de lo que cabe en una memoria de proceso de trabajo un gigabyte, junto con otro código de aplicación y de datos. Por lo que InProc hace que los cuellos de botella. Y cuantos más usuarios tienen, más se encontrará con estos problemas.
StateServer almacena el estado de sesión en un proceso que es independiente del proceso de trabajo de ASP.NET, pero también tiene limitaciones. Puede configurarlo para que cada servidor Web contiene su propia StateServer o puede dedicar un cuadro independiente y mantener el estado completamente en ese cuadro.
Con la primera opción, el problema es que aún tiene que utilizar sesiones pegajosas. Siempre que la sesión se creó, eso es que siempre tendrá que volver a él. Esta primera opción sólo mitiga la limitación de jardinería Web InProc. No resuelva el problema sesiones pegajosas que puede dejar con cuadros adicionales que no obtenga utiliza incluso mientras otros usuarios están obstruidos. El efecto neto para el usuario es que su tiempo de sesión y la respuesta es muy lenta.
El otro inconveniente de esta opción de configuración es si cualquier servidor Web queda inactivo, el StateServer en que también deja de cuadro de servidor Web, funcionar para perder todas esas sesiones. Es True, no perderá todas las sesiones en un sitio Web, pero pierde las sesiones almacenadas en ese cuadro de, y eso no es aceptable. Lo ideal es que nunca desea perder las sesiones.
Si elige la configuración de otra ofertas StateServer, un cuadro StateServer dedicado, ya no tiene que utilizar una sesión rápida ya que cada servidor Web va al mismo equipo dedicado. Pero ahora tiene un problema mayor: si ese cuadro alguna vez queda inactivo, el conjunto de servidores Web completo es hacia abajo porque cada servidor Web está intentando obtener su sesión de ese cuadro.
Eso no es todo. Este cuadro StateServer dedicado Obtiene superado a medida que se agregan más servidores Web y escalar de transacciones por segundo. Por lo tanto, se convierte rápidamente en un cuello de botella de escalabilidad. Por lo que el problema de la escalabilidad se resuelve no con StateServer, no con alguna de las configuraciones.
Ahora nos llegue a SqlServer, que almacena el estado de sesión en una base de datos de SQL Server y puede considerarse como un StateServer dedicado. Es servidor de base de datos principal de Microsoft diseñada para entornos de alta transacción. Es más escalable que un StateServer porque se puede crear un clúster de servidores de bases de datos.
En Configuración de SqlServer, todos los servidores Web conectar realmente a un cuadro SqlServer dedicado donde se almacenan todas las sesiones. Se trata como si cada uno de los servidores Web se han conectado a un cuadro StateServer dedicado. El concepto detrás de esto es que SqlServer será más escalable que un StateServer. Pero no es tan rápida como un servidor de estado de SqlServer porque un StateServer es un almacén de datos en memoria y en consecuencia, tiene un rendimiento aceptable. Por otro lado, SqlServer no es un almacén de datos en la memoria. Es un almacén de datos basados en disco. Todas las bases de datos se mantienen en el disco porque crecen tan grandes que la memoria no es suficiente para contener toda la base de datos. Por lo tanto, una base de datos almacena sus datos en almacenamiento persistente, que es un disco. Debido al almacenamiento en disco, SqlServer rendimiento no es tan rápida, lo que produce una caída de rendimiento.
SqlServer puede proceder en varias configuraciones. En una configuración independiente, que es el más común, hay sólo un servidor de base de datos que todos los servidores Web hablar con, y que aumentar el tamaño de la matriz Web y agrega más servidores Web, colocar más y más carga en la base de datos (consulte la figura 2 ).
La Figura 2 las sesiones ASP.NET aún un cuello de botella y la base de datos también no fullyscalable
Además, tiene un problema de rendimiento ya que SqlServer no está basada en la memoria, y haya un problema de escalabilidad porque no es capaz de escalar posible. Podría escalar haciendo el hardware más eficaz al agregar CPU a ese cuadro, pero no se puede mantener agregar más cuadros de servidor de base de datos a medida que crecen el conjunto de servidores Web. Puede quizá ir de uno a dos o dos o tres servidores de modo que SqlServer proporciona una base de datos clúster de capacidad, que escalar que más de un StateServer, pero también tiene sus limitaciones.
El otro problema SqlServer tiene almacenamiento es que todas las sesiones se mantienen en una sola tabla. La contención de bloqueo para el acceso simultáneo y las actualizaciones simultáneas de los datos de sesión queda patente tan pronto como escalar. Como tienen más y más transacciones por segundo, tiene más y más retrasos de bloqueo ya que todo lo que se mantiene en una tabla.
Por lo tanto, SqlServer escalas más de estado de servidor, y entrega un problema de rendimiento y no escala suficientemente. Además, no se escala linealmente. Se supone que pueda crecer una matriz Web de un 5-a 50 a 100 de servidores y se supone que el conjunto de servidores Web propio para crecer bastante sin problemas; sin embargo, el acceso a datos no aumentar igualmente. Como que se indicó anteriormente, una base de datos es uno de los accesos de almacenamiento de datos que no crecer, para almacenar las sesiones en una base de datos no realizar alguna mejora importante. Es sólo una mejora incremental a través de un entorno de servidor de estado. Además, un SqlServer se convierte en un cuello de botella para datos de aplicación, así como para las sesiones de datos. Por lo tanto, un servidor de base de datos no se escala para sesiones o las aplicaciones de datos.
¿Cuál es la respuesta?
La solución es un mecanismo de almacenamiento en memoria, por lo que puede ser muy rápido y tan rápida como una StateServer. Sin embargo, debe ser escalable casi linealmente. Escalabilidad lineal significa que la capacidad multiplica casi medida que se agregan más servidores. Le otorga por ejemplo, si se puede controlar 10.000 transacciones por segundo con un cuadro, agregar un segundo cuadro debería a usted cerca 20.000 transacciones por segundo total. Tenga en cuenta que "casi lineal" no significa exactamente 20.000, podría ser 19,000; sin embargo, no, es 12,000 o 15.000. Y esto es lo que necesitamos: almacenamiento que puede crecer casi linealmente y también debe en la memoria.
Debido a estas necesidades dos, de que no se hablando almacenamiento persistente, que tiene otros requisitos y está destinado a largo plazo. Una base de datos está pensada para almacenamiento a largo plazo, mientras que almacenamiento en memoria es siempre transitorios y temporales. Pero nuestras necesidades son temporales. Sólo se necesitan almacenar datos de este almacenamiento temporal durante una sesión de usuario o, quizás, para la duración de una aplicación, unas pocas horas a unos pocos días o quizá unas semanas en la mayoría. A continuación, los datos pueden desaparecen porque ya hay siempre permanente almacenamiento principal, que es la base de datos donde se pueden cargar los datos de nuevo.
Por lo que, con todo esto en cuenta, se puede considerar de un mecanismo de almacenamiento denominado una "caché distribuida," un concepto que se ha convertido en popular porque proporciona las ventajas citadas anteriormente, como La figura 3 se muestra.
La figura 3 caché distribuida relieving presión en el servidor de base de datos
Una caché de distribuida es en memoria, por lo que es rápido y está diseñada para distribuir el crecimiento de forma bastante lineal, especialmente si tiene el mecanismo de distribución derecha (también denominado topología de almacenamiento en caché).
Debe proporcionar una caché distribuida alto rendimiento y escalabilidad lineal y porque existe en la memoria, debe proporcionar la replicación para que, si cualquier equipo deja de funcionar (la memoria en ese equipo está disponible), otro equipo tendrá los datos y no pierda ninguna. Replicación proporciona más de una copia de los mismos datos en diferentes ubicaciones de distintos cuadros y, si lo hace, lograr 100 % de tiempo para la duración de su almacenamiento de datos.
Una caché distribuida almacena un objeto .NET o un objeto de Java o, para eso importa, otros datos como un documento XML. Almacena datos en un formato preparado. No tiene el concepto de las tablas y filas y las claves principales y claves externas que tiene una base de datos. Para los programadores, una caché distribuida es esencialmente una HASH tabla, que hay una clave y cada clave tiene un valor y que valor es un objeto. Necesita conocer la clave, y en función de la clave, se puede recuperar el objeto que desee. Esto es una caché lógica que puede abarcar varios servidores. Puede agregar servidores a la vez para aumentar el tamaño de caché del clúster, y se pueden quitar cuadros al mismo tiempo para reducir el clúster de memoria caché sin necesidad de detener nada.
Topologías de almacenamiento en caché
Las topologías de varias que debe proporcionar una caché efectiva se replican, particiones, un híbrido de replicado y con particiones y el cliente o caché local. La idea es que diferentes topologías de almacenamiento en caché para los distintos tipos de uso, que hace la memoria caché muy flexible. Una topología replicada replica la caché de muchas veces, según cómo muchas veces necesita (consulte la figura 4 ). Está dirigido situaciones donde tenga un uso de caché que hacen un uso intensivo de lectura, pero no una gran cantidad de actualizaciones.
La figura 4 la caché replicada es ideal para su uso que hacen un uso intensivo de lectura
Una caché con particiones es la topología altamente escalable para un uso intensivo de actualización o transaccionales datos que necesita para almacenar en caché. Podría tratarse de datos de sesión ASP.NET, que es muy transaccionales. Como se mencionó anteriormente, para cada solicitud Web, la sesión se lee una vez y se actualiza una vez, para que tenga un número igual de lecturas y escrituras.
Una topología con particiones (consulte la figura 5 ) es excelente para entornos donde las actualizaciones deben realizarse al menos tantas veces a medida que avance en lecturas o muy cerca que. En esta topología, se divide la memoria caché. Medida que se agregan más servidores de caché, la caché es más particiones de tal manera que casi un N (N significa que el número de nodos) de la memoria caché se almacena en cada servidor de caché.
La figura 5 una caché con particiones es ideal para su uso que hacen un uso intensivo de escritura.
Una topología de la tercera es un híbrido de las versiones con particiones y replicados. Puede dividir la caché y, al mismo tiempo, se puede replicar cada partición. Por lo tanto, se obtener lo mejor de ambos mundos. Podrá crear particiones y crecer, además de que puede replicar de disponibilidad para asegurarse de que no hay datos está perdidos (consulte la figura 6 ).
Figura 6 cachés de réplica de partición son ideales para la escritura de intensiveusage con confiabilidad.
Con la ayuda de las topologías de híbrido con particiones y replicación de particiones, puede aumentar la caché de forma lineal en términos de escalabilidad.
Un cliente o la memoria caché local es la topología muy útil cuarta que se encuentra en el servidor de la aplicación. Este tipo de caché es muy parecido a la aplicación y incluso pueden InProc. Normalmente es un pequeño subconjunto de la caché distribuida grande real y se basa en lo que se ha solicitando la aplicación en ese momento en el tiempo. Cualquier las solicitudes de aplicación, se conserva una copia en la caché del cliente. La próxima vez que la aplicación quiere los mismos datos, automáticamente resultará en la caché del cliente. No tendrá que ir a la caché distribuida, para guardar incluso como un viaje, porque la caché distribuida es a menudo a través de la red en un servidor de almacenamiento en caché independiente o clúster de servidores de caché. Una caché de cliente le ofrece un aumento del rendimiento y escalabilidad adicional.
Los datos en una caché de cliente se deben mantener sincronizados con la caché distribuida. Si se cambian los mismos datos en la caché distribuida, la caché distribuida debe sincronizar ese cambio con la caché del cliente. Este es un aspecto importante, no desea tener sólo una caché local que es totalmente desconectada. Eso es sólo el equivalente de una caché InProc, que es inaceptable porque tiene problemas de integridad de datos. Tiene varias copias de los mismos datos que obtiene una falta de sincronización.
Opciones de diferentes
Hay varias características de almacenamiento en caché distribuidos disponibles... Y, como en la mayoría de los casos, soluciones libres proporcionan un conjunto más limitado de características mientras las comerciales ofrecen mucha más opciones y características.
Aparte de alto rendimiento, escalabilidad y alta disponibilidad, una eficaz caché distribuida debe incluir varias características clave para ayudar a mantener la caché actualizada y sincronizada con el origen de datos principal, si la base de datos o gran sistema (mainframe). La caché debe tener una opción de caducidad por lo que se puede saber para realizar la caducidad automática, que puede ser una hora absoluta o lo que llama "tiempo deslizante". Básicamente, es tiempo de inactividad; si no utiliza los datos, está caducado automáticamente.
Una memoria caché también debe poder administrar las relaciones entre los diferentes tipos de datos. La mayoría de los datos se relacional. Por ejemplo, si tiene un cliente, tiene pedidos de ese cliente por lo que no hay una relación entre los datos del cliente y datos de pedidos. Si la caché cliente y orden de datos y sin darse cuenta elimina los datos del cliente de la caché, sentido que la orden se podría eliminar automáticamente. En este caso, no sabe si quita los datos del cliente de la caché o se elimina permanentemente se. En el caso de permanentemente había eliminado, el orden es también no válido ahora porque el pedido tiene que ser de un cliente válido.
Hay otros tipos similares de relaciones que deben administrarse en la caché. Si la caché de no hacerlo, a continuación, la aplicación tiene que mantener un seguimiento y es muy difícil. Un objeto de caché de Microsoft en ASP.NET que es muy útil se denomina un "caché dependencia concepto." Un elemento almacenado en caché depende de otra. Si ese otro elemento almacenado en caché se nunca se quita de la caché o incluso actualizado, el primer elemento de caché se quita también. Esto es un concepto de dependencia de caché eficaz que debería estar disponible en todas las cachés que almacenar en caché de datos relacionales.
Sincronizar con la base de datos es otra posibilidad de importante para la caché. Una base de datos normalmente se comparte entre varias aplicaciones. Si una aplicación mediante la caché es la única actualización de la base de datos, probablemente no necesite la característica de sincronización de la base de datos. Pero con bastante frecuencia, otras aplicaciones, las aplicaciones de terceros a veces, están actualizando datos en la base de datos porque la base de datos es un almacén compartido y común y las aplicaciones no están utilizando la memoria caché. No se incluso pueden las aplicaciones. NET. Pueden ser aplicaciones de terceros que no controlar, pero se actualizan en la base de datos. Por lo que tendrá que permitir en situaciones donde es posible que se actualizado la base de datos fuera de la aplicación, pero algunos de que los datos que ha sido actualizados en la base de datos también se almacena. Por lo tanto, la memoria caché tiene que ser capaz de sincronizar. Tiene que puedan saber siempre que los datos se son ya no la misma en la base de datos. Debe quitar los datos de la caché y quizá incluso a cargar la última copia de la base de datos. Sincronización de la base de datos se puede realizar a través de los eventos desencadenados por el servidor de base de datos o por la caché de sondear el base de datos. Los eventos son de curso más en tiempo real y sondeo tiene un pequeño retraso. Pero sondeo puede resultar más eficaz si se cambia una gran cantidad de datos.
La notificación de evento es entre las características más importantes que debe tener una caché distribuida eficaz. Una memoria caché a menudo se comparte entre varias aplicaciones y incluso en una aplicación entre varios usuarios. Por lo tanto, la caché debe tener un mecanismo de notificación de eventos en caso, por ejemplo, se actualiza o se quita un objeto almacenado en caché. Si la aplicación está utilizando los mismos datos, es posible que desea recibir una notificación por lo que puede volver a cargar en de la base de datos o una nueva copia de la caché de sí mismo. Un mecanismo de notificación mejora la colaboración entre varios usuarios o varias aplicaciones a través de la caché.
El mundo real
Administración de TI se enfrenta a todos los problemas de rendimiento asociados a bases de datos y, en el caso de cuellos de botella, si estás suerte poder a informar a los desarrolladores, es posible que intente solucionarlos. Por desgracia, desarrollo no siempre interna. A menudo se encuentra viven con y administrar una aplicación de terceros.
En cualquier caso, la mejor colocar para iniciar la implementación de la caché distribuida para abrir los cuellos de botella y turbo-cargo es sus aplicaciones con almacenamiento de sesión de ASP.NET, porque no tiene que dependen de los desarrolladores. No hay ninguna programación implicados. Es una simple cuestión de sustitución de almacenamiento de sesión existente con una caché distribuida en la memoria. Además, implementar una caché distribuida para almacenamiento de sesión de ASP.NET tendrá la oportunidad para ver las ventajas que acumulan para el rendimiento y la escalabilidad y, a continuación, puede decidir si desea hacer lo mismo para los datos de aplicación.
Para experimentar la mejora de escalabilidad, que bien tiene que ejecutar distribuida caché almacenamiento en el entorno de producción o tiene que simular que la carga en el entorno de prueba. Es posible que tiene acceso a control de calidad, lo que puede ayudarle a realizar una prueba de esfuerzo en un entorno de pruebas para simular una carga grande antes de poner una caché distribuida en el entorno de producción. La mayoría de los administradores de TI probablemente no sería cómodos poner una caché distribuida en la producción a menos que tenía probado, en primer lugar en su entorno de control de calidad, incluso si no pueden simular la misma cantidad de carga. Por lo que es un buen punto de partida.
Una vez eres instala y ejecuta con una caché distribuida y reaping sus ventajas, puede compartir los resultados de rendimiento y escalabilidad de sesión de ASP.NET nuevos con el equipo de desarrollo internos o de terceros de proveedor. Con la evidencia disco duro de mano, puede solicitar el equipo de desarrollo analizar las áreas donde pueden almacenar en caché datos de aplicación de esta caché distribuida así.
Almacenamiento en caché de datos de la aplicación proporciona un aumento más y en muchos casos mucho más aumentar que basta con utilizar una caché distribuida para almacenamiento de sesión de ASP.NET. Los desarrolladores podrían identificar todos los elementos de datos que se leen con más frecuencia que se actualizan. Datos incluso transaccionales (, como los clientes, pedidos y el tipo) es una buena candidata para el almacenamiento en caché, incluso si permanece en la caché durante unos minutos antes de caducidad. Esto se debe en este breve período de tiempo, los datos es posible que se releer muchas veces, y si este volver a leer desde la caché y no desde la base de datos, mitiga la base de datos de un lote de carga de lectura.
Sin embargo, para los desarrolladores a datos de aplicación de caché, tendrá que hacer algo de programación si realizar llamadas de API a la caché distribuida. La idea es muy sencilla. Siempre que su aplicación intenta recuperar datos de la base de datos, debe comprobar la caché. Si la memoria caché tiene los datos, se toma los datos de la caché. De lo contrario, la aplicación recupera los datos de la base de datos, almacena y, a continuación, le da al usuario. De este modo, los datos se encuentran en la caché de la próxima vez que se leyeron. Igualmente, cuando se modifican datos en la base de datos, se debe también se actualiza en la caché. Y, si la memoria caché resida en varios servidores, se debe, por tanto, se sincroniza automáticamente para asegurarse de que si la aplicación se ejecuta en un conjunto de servidores Web, los mismos datos de caché son accesibles desde todos los servidores del conjunto. Para obtener más información sobre el tema de cómo desarrollar una aplicación que utiliza una caché distribuida para una mejor escalabilidad, busque mi próximo artículo en la edición de julio MSDN Magazine.
Iqbal khan es el presidente y tecnología Evangelista de Alachisoft, la compañía que proporciona NCache, el sector del iniciales caché de .NET distribuido para aumentar el rendimiento y escalabilidad en aplicaciones de empresa. Iqbal recibió una Microsoft en el equipo Ciencias University Indiana, Bloomington, en 1990. Puede ponerse en iqbal@alachisoft.com.