Java punto cuello de botella del rendimiento de aplicaciones es muy grande, factores sistémicos tales como discos, memoria, red de E / S, etc., código de la aplicación Java, la JVM GC, bases de datos, el almacenamiento en caché. Yo basado en la experiencia personal, la optimización del rendimiento de Java se divide en cuatro niveles: el nivel de aplicación, una capa de base de datos, una capa de marco, la capa de JVM , como se muestra en la figura.
La figura jerárquica rendimiento del modelo de optimización 1.Java
Cada capa de optimización cada vez más difícil, y el conocimiento para resolver los problemas que se plantean serán diferentes. Por ejemplo, la capa de lógica de la aplicación necesita entender el código, busque la línea de código en cuestión por la pila hilo Java, y así sucesivamente; la necesidad de nivel de base de datos para analizar el SQL, el posicionamiento de punto muerto; necesidad capa de entender el marco código fuente, un marco para entender el mecanismo; nivel JVM y el tipo de trabajo requerido para la GC mecanismos tienen una buena comprensión de la función de diversos parámetros ganancias de JVM.
Alrededor de la optimización del rendimiento de Java, hay dos métodos básicos de análisis: análisis in situ y análisis posterior.
El análisis del sitio por sitio de reserva, y luego localizar el análisis utilizando la herramienta de diagnóstico. Análisis del sitio mayor impacto en la línea, que forma parte de la escena (en particular cuando se trata de usuarios crítica para el negocio) no es adecuado.
El análisis posterior tiene que recoger datos de múltiples sitios, a continuación, restaurar inmediatamente el servicio, pero después del análisis y reproducida para la recolección de datos de campo. Empecemos desde el rendimiento de las herramientas de diagnóstico, comparten un número de casos y la práctica.
En primer lugar, la herramienta de diagnóstico de rendimiento
Uno de ellos es el diagnóstico de rendimiento para el diagnóstico de problemas de rendimiento han sido identificados y los sistemas de códigos, hay un par de líneas en las pruebas de rendimiento del sistema de pre-avance, para determinar si los requisitos de rendimiento en línea.
Este papel probado para el primero, este último puede ser presionado con la herramienta de medición vario funcionamiento (por ejemplo la JMeter), el rango no se discute en este documento.
Para aplicaciones Java, herramientas de diagnóstico de rendimiento se dividen principalmente en dos capas: nivel de sistema operativo y la aplicación a nivel de Java (incluyendo diagnósticos de códigos de aplicación y de diagnóstico GC).
diagnóstico OS
OS diagnóstico de las principales preocupaciones es la CPU, memoria, I / O en tres aspectos.
Dos, el diagnóstico de la CPU
La principal preocupación para la carga de la CPU promedio (carga media), uso de CPU, cambios de contexto (cambio de contexto).
Puede ver la carga del sistema y la utilización media de la CPU por el comando superior, la Fig. 2 es una vista superior de un sistema a través de un estado de comando.
Ejemplo de comando 2.top de la figura.
carga media de tres números: 63.66,58.39,57.18, respectivamente, más de 1 minuto, 5 minutos, 15 minutos de carga de la máquina. De acuerdo con la experiencia, si el valor es inferior a 0,7 * número de CPU, el sistema está funcionando correctamente; si hay más de este valor, incluso hasta cuatro o cinco veces el número de núcleos de CPU, la carga en el sistema es significativamente mayor.
En la Figura 2 la carga ha llegado a 15 minutos 57.18,1 carga es 63.66 minutos (para el sistema de 16 núcleos), el sistema descrito surgen problemas de carga, y la tendencia actual se incrementa aún más, la necesidad de localizar razones específicas.
Puede ser visto por la CPU vmstat cambios de contexto de comandos, que se muestran en la Figura 3:
ejemplos de comandos FIG 3.vmstat
El número de escena de ocurrencias de cambios de contexto tienen las siguientes categorías principales:
-
1) porción de tiempo expira, la CPU programación de tareas normal;
-
2) siendo el otro un derecho de prioridad tarea de mayor prioridad;
-
3) Realizar tareas encontraron con I / O obstrucción, suspender la tarea actual, un cambio de tarea a la siguiente;
-
4) iniciativa de código de usuario suspender la tarea actual de renunciar a la CPU;
-
5) los recursos multitarea preventiva, porque no se suspende ninguna de agarre;
-
6) interrupción de hardware.
contexto hebra Java conmutación principalmente de la competencia por los recursos compartidos. En general, un solo sistema de bloqueo de objetos rara vez se convierta en un cuello de botella, a menos que la granularidad de bloqueo es demasiado grande. Sin embargo, una frecuencia de acceso es alta, una pluralidad de objetos sucesivos en un bloque de bloqueo de código puede aparecer un gran número de cambios de contexto, se convierta en un cuello de botella del sistema.
Tres, Memoria
Desde la perspectiva del sistema operativo, la memoria, la atención a la adecuación del proceso de solicitud, se puede utilizar el comando free -m para ver el uso de memoria.
Puede ver el proceso utilizado por el VIRT memoria virtual comando superior y RES de memoria física, de acuerdo con la fórmula VIRT = SWAP + RES pueden calcular la aplicación partición de intercambio específico usado (SWAP), el uso de intercambio demasiado efecto sobre el rendimiento de aplicaciones Java puede ser swappiness transferido al valor tan pequeño como sea posible.
Debido a que para las aplicaciones Java, ocupan demasiado de intercambio puede afectar al rendimiento, el rendimiento del disco, después de todo, mucho más lento que la memoria.
Cuatro, I / O
I / O incluye un disco I / O, y la red I / O, el disco más propensos a los cuellos de botella de E / S en general. Se puede ver cómo el disco leído por iostat, a través de la espera de la CPU I O puede ser visto / / S de disco es normal.
Si el disco I / O ha estado en un estado de alta, que indica un fallo lenta o disco, se ha convertido en un cuello de botella, la necesidad de optimización de aplicaciones o el reemplazo de disco.
Además de la parte superior de costumbre, ps, vmstat, iostat comandos, hay otras herramientas de Linux para diagnosticar problemas del sistema, como mpstat, tcpdump, netstat, pidstat, sar y así sucesivamente. Resumen Linux Brendan listas diferentes tipos de herramientas de diagnóstico rendimiento del dispositivo, como se muestra en la Fig. 4, como referencia.
La figura Rendimiento Observación herramienta 4.Linux
Cinco, Java aplicaciones y herramientas de diagnóstico
El código de aplicación es relativamente fácil de resolver problemas de rendimiento de una clase de problemas de rendimiento. A través de algunas de monitoreo de alarmas a nivel de aplicación, si hay problemas y códigos determinados por el código puede ser localizado directamente, oa través de la parte superior + jstack, identificar pila de subprocesos problema, posicionado en temas código de rosca, se puede encontrar el problema. Para, la lógica más segmentos de código más complejo, más a menudo el código de la aplicación puede ser posicionado problemas de rendimiento Cronómetro mediante la impresión de registro de rendimiento.
Común de Java diagnóstico de aplicaciones, incluyendo la pila de hebras de diagnóstico, GC y otros aspectos.
jstack
jstack con el comando superior se utiliza típicamente proceso de localización Java y el hilo a través de la parte superior -H -p pid, reutilización jstack -l pid pila hilo de exportación. A medida que la pila de subprocesos es transitoria, por lo que requiere múltiples volcado, por lo general tres veces al volteo, por lo general cada cada 5s en la línea. El posicionamiento de la parte superior de rosca Java PID se convierten en hexadecimal, llegar Java nid pila hilo, el problema se puede encontrar en la pila de rosca correspondiente.
Figura 5. -p ver cómo funciona durante mucho tiempo hebra Java a través de la parte superior -H
5, en el que los hilos más largos que ejecutan 24.985, pueden ser un problema, transformado en datos hexadecimales por pila de subprocesos Java para encontrar la pila rosca correspondiente como 0x6199 para localizar problemas, como se muestra en la figura.
Figura 6.jstack visualización de pilas de subprocesos
JProfiler
JProfiler puede llevarse a cabo en la CPU, montón, análisis de la memoria, de gran alcance, como se muestra en la figura. En combinación con la herramienta de medición de la presión, el código puede ser estadísticas de muestreo que consumen tiempo.
7. Análisis de la memoria la figura por JProfiler
Seis, el diagnóstico de GC
Java GC aborda el riesgo de programadores gestionar la memoria, pero la aplicación de GC pausa causó otro problema a resolver convertirse. JDK proporciona una gama de herramientas para localizar el problema GC, más comúnmente utilizado jstat, jmap, así como las herramientas de terceros tales como los TMA.
jstat
comando GC jstat detallada, completa joven GC y GC pila información de frecuencia imprimible. El formato del comando es
jstat -gcxxx -t pid <intervalo> <contador>, como se muestra en la figura.
ejemplos de comandos FIG 8.jstat
jmap
jmap el proceso de impresión de Java montón de información jmap -heap pid. Por jmap -dump: file = xxx pid para apilar archivo de volcado pueden ser analizados además por el uso de otra pila de herramientas
ESTERA
MAT es la herramienta de análisis de montón de Java, proporciona un informe de diagnóstico intuitivo, un sistema incorporado en NCO permite las consultas SQL de clase montón, de gran alcance, de referencia saliente y entrante de referencia se pueden remontar a una referencia de objeto.
La figura ejemplo 9.MAT
La Figura 9 es un ejemplo usando MAT, MAT tiene dos columnas muestran el tamaño del objeto, el tamaño respectivamente superficial y tamaño retenidas, el primero representa el tamaño de la memoria ocupada por el objeto en sí mismo, que no contiene el objeto referenciado por el objeto en sí mismo y que se hace referencia directa o indirectamente tamaño superficial del objeto y que el objeto se libera después de ser recuperado tamaño de la memoria GC, el tamaño de los cuales puede en preocupación general.
Para algunas pilas (decenas G) de aplicaciones Java que requieren gran capacidad de memoria para MAT abierta.
Por lo general, la memoria de la máquina de desarrollo local es demasiado pequeño, no se puede abrir, se recomienda en línea en instalación en el servidor entorno gráfico y MAT, abierta a distancia para verlo. montones de estera o ejecutar comandos índice de crudo, el índice de la copia local, pero se limita de esta manera ver la información de la pila.
Con el fin de diagnosticar el problema GC, se sugirió añadir la JVM argumento -XX: + PrintGCDateStamps. GC parámetros utilizados comúnmente, como se muestra en la figura.
Figura Parámetros de GC comunes 10.
Para aplicaciones Java, por arriba + + jstack jmap + MAT puede localizar más aplicaciones y problemas de memoria, que se puede describir como una herramienta esencial. A veces, las aplicaciones Java necesitan para referirse a diagnosticar la información del sistema operativo, puede utilizar algunas de las herramientas de diagnóstico más completos, como Zabbix (OS y JVM de seguimiento integrado) y así sucesivamente. En un entorno distribuido, sistemas de seguimiento distribuidos y otras infraestructuras tiene sobre el diagnóstico de rendimiento de aplicaciones proporciona un fuerte apoyo.
Siete, la práctica de la optimización del rendimiento
Después de la introducción de alguna herramienta de diagnóstico que se utiliza comúnmente Después de la actuación, lo siguiente será combinar algunas de nuestras prácticas en el ajuste de las aplicaciones Java, caso de uso compartido de la capa de JVM, la capa de aplicación y la capa de base de datos de código.
JVM sintonización: dolor GC
A XX Seleccionar un sistema de plataforma de negocios como la reconstrucción interna de RMI protocolo de comunicación remota, comenzaron a aparecer periódicamente en el sistema después de que el servicio se detiene la línea de respuesta, tiempo de pausa que van desde unos pocos segundos a decenas de segundos. Al observar el registro de GC y se encontró que una hora después del servicio desde el lanzamiento habrá una completa GC. Debido a que la pila del sistema se hace más grande, completo GC tiempo de pausa será tiempo de aplicación más largo, esta mayor impacto en los servicios en tiempo real en línea.
Después del análisis, la situación sobre una base regular completa GC no aparece en el sistema antes de la reconstrucción, por lo tanto, se sospecha dimensión marco RMI. A través de la información pública y encontró que la GDC (Garbage Collection distribuida, la recolección de basura distribuida) de RMI se iniciará el hilo de utilidad periódicamente realizar la GC completa para recuperar el objeto remoto, el Listado 2 muestra el código para su hilo de utilidad.
Añadir 2.DGC demonio de código fuente hilo
privada estática clase Daemon extiende Tema { público vacío run () { a (;;) { // ... larga d = maxObjectInspectionAge (); si (d> = l) { System.gc (); d = 0 ; } // ... } } }
Después de localizar el problema a resolver relativamente fácil. Una de ellas es mediante la adición de -XX: + DisableExplicitGC parámetros, deshabilitar el Salón llamar directamente al sistema de GC, pero el sistema usando NIO, habrá el riesgo de desbordamiento de pila de memoria externa.
Otra forma es mediante el ajuste de los parámetros de la gran -Dsun.rmi.dgc.server.gcInterval y -Dsun.rmi.dgc.client.gcInterval, Encuadre de GC aumenta el intervalo, mientras que el aumento de la -XX parámetro: + ExplicitGCInvokesConcurrent, a un Stop completa el Mundial de Full GC ajustado a tiempo de ciclo de basura simultánea, reducir los tiempos de pausa de aplicación, mientras que no se verá afectada la aplicación NIO.
Visto desde la Fig. 11, Encuadre de GC después de ajustar el número de reducido significativamente después de tres meses.
Figura 11.Full GC vigilancia de las estadísticas
GC de ajuste para aplicaciones de alta concurrencia interactuar con grandes cantidades de datos sigue siendo muy necesaria, sobre todo en el valor por defecto los parámetros de JVM por lo general no están satisfechos con las necesidades del negocio, la necesidad de ajuste especializado. Interpretación de los registros de GC tiene una gran cantidad de información pública, esto no va a ir.
GC objetivo del ajuste básicos tres ideas: para reducir la frecuencia de GC, se puede generar mediante el aumento de la pila para reducir objetos innecesarios, los tiempos de pausa GC reducen, reduciendo el espacio de almacenamiento dinámico, utilizando el algoritmo CMS GC; evitando completa GC, disparador de ajuste CMS proporción, evitar el fracaso Promoción y fallo del modo concurrente (años de edad asignar más espacio, lo que aumenta el número de hilos de GC para acelerar la tasa de recuperación), para reducir la generación y otros objetos grandes.
Capa de aplicación de sintonización: huele mal gusto código
A partir de la capa de aplicación del código de inicio de sintonía, la raíz las causas de la disminución de la eficiencia del código, sin duda, uno de los buenos medios para mejorar el rendimiento de las aplicaciones Java.
Un sistema comercial (usando Nginx carga de equilibrio) después de un cierto tiempo todos los días en la línea, incluyendo un fuerte aumento de la carga de varias máquinas, el uso de CPU jugado rápidamente. Tuvimos una reversión de emergencia en línea y en el sitio a un servidor que se guarda por jmap y jstack.
Figura 12. Análisis por el MAT campo pila
Campo pila 12, de acuerdo con el análisis de los datos MAT volcado, más a menudo encontrados como un objeto de memoria y byte [] java.util.HashMap $ de entrada, y hay una referencia circular objeto java.util.HashMap $ de entrada. Preliminar localizar puede haber un problema bucle infinito (Figura java.util.HashMap $ Entrada 0x2add6d992cb8 y 0x2add6d992ce8 la siguiente forma de referencia de un ciclo) en la puesta en proceso HashMap.
El acceso a los documentos relevantes que pertenecen a la colocación de errores escena típica del uso concurrente de (http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6423457), puesto brevemente, es en sí misma HashMap no tiene características multithreading, en el caso de múltiples hilos de una operación de venta, que dará lugar a la interior de la estructura anular formada lista HashMap expansión interna de la matriz, de manera que un bucle sin fin.
Para la línea en, el mayor cambio es para mejorar el rendimiento del sistema a través de los datos del sitio de memoria caché, utilizando tanto mecanismo de carga diferida, como se muestra en el Listado 3.
Listado 3. Código de carga de datos Sitio web perezoso
privada estática Mapa <largo, UnionDomain> domainMap = nuevo HashMap <largo, UnionDomain> (); privadas booleanos isResetDomains () { si (CollectionUtils.isEmpty (domainMap)) { // 从远端http接口获取网站详情 Lista <UnionDomain> newDomains = unionDomainHttpClient .queryAllUnionDomain (); si (CollectionUtils.isEmpty (domainMap)) { domainMap = nuevo HashMap <largo, UnionDomain> (); para (UnionDomain dominio: newDomains) { si ! (dominio =nula ) { domainMap.put (domain.getSubdomainId (), de dominio); } } } Regresar verdadera ; } Devolver falsa ; }
DomainMap puede ver aquí es compartida recursos estáticos, es el tipo HashMap en una situación multiproceso dará lugar a su lista interna formar una estructura de anillo, un bucle infinito.
Se puede ver a través de los registros de conexión frontal y acceder a Nginx, ya que el sistema se reinicie Nginx amasado una solicitud del usuario para comenzar a contenedores de resina, muchos usuarios requieren afluencia de aplicaciones, varios usuarios simultáneamente solicitan datos y sitios de inicialización el trabajo, lo que lleva a problemas de concurrencia HashMap surgir. Después de la solución de localización de la falta es relativamente simple, las principales soluciones son:
-
(1) utilizando la sincronización de bloque o ConcurrentHashMap resolver los problemas concurrentes;
-
(2) completa caché web cargado antes que el sistema se inicia, retire la carga diferida y así sucesivamente;
-
(3) la sustitución de la memoria caché local como una memoria caché distribuida.
Para el posicionamiento de mal código, además de la revisión de código en el sentido convencional, con herramientas como MAT puede localizar rápidamente los cuellos de botella del sistema señalan en cierta medida. Sin embargo, en algunos casos vinculados a una escena específica o el enlace de datos empresariales, pero la necesidad de una revisión de código auxiliar, herramientas de pruebas de rendimiento, líneas de datos e incluso simular el drenaje, etc., para finalmente confirmar el origen de los problemas de rendimiento. El siguiente es un resumen de algunos de nuestra mala código puede algunas características, para su referencia:
-
(1) pobre legibilidad del código, sin las especificaciones básicas de programación;
-
(2) generación de objetos o la generación de objetos demasiado grandes, pérdidas de memoria y similares;
-
(3) IO operación de flujo excesiva, o se olvide de apagar;
-
El exceso de (4) para las operaciones de base de datos, la transacción es demasiado largo;
-
(5) utilizando los escenarios de error de sincronización;
-
tiempo de iteración (6) bucle de operación que consume.
Sintonización capa de base de datos: pesadilla interbloqueo
Para la mayoría de las aplicaciones Java, para interactuar con la base de datos escena es muy común, especialmente para OLTP esta consistencia de los datos las aplicaciones más exigentes, el rendimiento de la base de datos afectará directamente al rendimiento de toda la aplicación. sistema de plataforma de negocios Sogou como anunciantes y plataforma de publicidad que sirve, su puntualidad y consistencia del material tiene alta demanda, estamos en una optimización de bases de datos relacionales también ha acumulado cierta experiencia.
Para la publicidad biblioteca de materiales, una mayor frecuencia de funcionamiento (en particular a través de la operación de la herramienta de material a granel) muy fácilmente resultar en una situación de bloqueo de base de datos se produce, uno de los escenario más típico es la publicidad ajuste de precios material. Los clientes tienden a frecuentes ajustes de los materiales de la oferta, y por lo tanto causan indirectamente a una mayor presión para cargar el sistema de base de datos, también contribuyó a la posibilidad de estancamiento. A continuación se describirá un Sogou ajuste de los precios de materiales de publicidad plataforma de negocios caso el sistema de publicidad.
visitas del día de un aumento repentino en los sistemas comerciales, lo que resulta en un aumento de carga del sistema y la base de datos punto muerto frecuente, se muestra declaración punto muerto en la Figura 13.
declaración Figura 13. interbloqueo
En el que, GroupDomain la idx_groupdomain_accountid tabla de índice (accountid), idx_groupdomain_groupid (groupid), tres sola estructura índice primario (groupdomainid), utilizando Mysql innodb motor.
Esta situación se produce cuando se actualiza la oferta del grupo, hay un grupo de escena, grupo de la industria (tabla groupindus) y el sitio web del Grupo (tabla GroupDomain).
Al actualizar la oferta del grupo, si las ofertas de grupos de la industria que utilizan la oferta del grupo (marcado por isusegroupprice, si se trata de una oferta del grupo de uso). Al mismo tiempo, si el sitio Web del grupo de Oferta utilizando oferta del grupo de la industria (marcado por isuseindusprice, si se va a utilizar una oferta del grupo de la industria), el grupo también necesita actualizar su oferta sitio web. Desde el máximo posible para cada grupo después de un sitio de 3000, por lo que cuando se actualiza la oferta del grupo tendrán mucho tiempo para que los registros pertinentes bloqueado.
problemas de interbloqueo se pueden ver desde arriba, la transacción 1 y 2 Transacción se seleccionan idx_groupdomain_accountid un único índice. De acuerdo con Mysql innodb bloqueo motor cuenta en una sola transacción será optar por utilizar un índice, pero si el uso de índices secundarios Una vez cerrado, intenta bloquear el índice de clave principal. El análisis adicional muestra que una transacción de bloqueo en el índice secundario `idx_groupdomain_accountid` 2 transacción de solicitud celebrada (intervalo cerrado de" espacio ID 5726 página no 8658 n bits 824 de índice '), pero la transacción se ha índice secundario 2 (' espacio Identificación 5726 página no 8658 n bits 824 índice "en la) de bloqueo añadido, solicitudes de bloqueo en espera de un bloqueo en el índice principal índice de clave principal. Como el tiempo de ejecución de transacción de espera es demasiado largo o 2 mucho tiempo no para liberar el bloqueo, lo que resulta en una operación de deshacer la transacción se produce 1 final.
Durante el día la visita de seguimiento de registro se puede ver, hay un gran número de modificaciones iniciadas por la oferta al cliente para promover las operaciones del grupo a través de camino de la escritura de ese día, lo que resulta en un gran número de transacciones en el circuito primario de espera para el índice de clave principal de la operación anterior para liberar el bloqueo. Origen del problema está en realidad en el índice del motor InnoDB de MySQL para un uso limitado en una base de datos Oracle Este problema no es prominente.
La forma natural es resolver un solo bloqueos de transacciones el número de registros como sea posible, se reducirá considerablemente la probabilidad de este punto muerto. El índice de uso final (accountid, groupid) de material compuesto, lo que reduce el número de registros en un único bloqueo de transacción, sino también para promover la realización del aislamiento de los registros de datos en diferentes programas, reduciendo así la probabilidad de ocurrencia de un punto muerto tal.
En términos generales, para el ajuste de la capa de base de datos, básicamente, a partir de los siguientes aspectos:
(1) para optimizar el nivel de instrucción SQL: Análisis SQL lenta, análisis del índice y puesta a punto, dividir y otros asuntos;
(2) para optimizar el nivel de configuración de base de datos: tal campo está diseñado para ajustar el tamaño de memoria intermedia, el disco I / O, la optimización de parámetros de base de datos, la desfragmentación de datos;
(3) a partir de la base de datos para optimizar el nivel estructural: consideran base de datos de división vertical y horizontal de división, y similares;
(4) selección de un motor de base de datos adecuada, o adaptado a diferentes tipos de escenas, como NoSQL considerar la introducción similares.
Ocho, resumen y recomendaciones
2-8 sintonía sigue los mismos principios, el problema de rendimiento es del 80% desde el 20% del código generado, optimizando así el multiplicador código de la llave. Al mismo tiempo, para optimizar el rendimiento de la optimización on-demand a hacer, sobre-optimización puede introducir más problemas. Para la optimización del rendimiento de Java, no sólo para comprender la arquitectura del sistema, código de aplicación, requiere el mismo nivel de atención JVM e incluso el sistema operativo subyacente. Para resumir el principal puede ser considerado desde los siguientes puntos:
1) ajuste y el rendimiento de
propiedades de base en este documento se refiere al nivel de hardware, o para mejorar la optimización a nivel de sistema operativo, como la afinación de la red, que opera las actualizaciones de versión del sistema, optimización de hardware. Tales como el disco duro del uso de F5 y SDD introdujo, incluyendo una nueva versión de los aspectos Linux mejorar el rendimiento de NIO puede ser en gran medida la promoción de la aplicación;
2) Optimización del rendimiento de base de datos
Incluyendo asuntos de división común, optimización de índices, la optimización de SQL, y otra NoSQL introdujo, tales como la introducción de procesamiento asíncrono cuando la transacción se divide, y en última instancia lograr introducción coherencia de las prácticas, incluyendo la introducción de diversos tipos de bases de datos NoSQL para una escena en particular, puede facilitar en gran medida la escasez de bases de datos tradicionales a alta concurrencia;
3) marco de aplicación optimizado
Introducir algún nuevo marco de computación o almacenamiento, con la nueva característica de resolver el cuello de botella de la agrupación original de computación similares; o la introducción de una estrategia distribuida, nivel de cálculo y almacenamiento, que comprende pre calcula-por adelantado y similares, utilizando un espacio práctica típica para el tiempo de y similares; el sistema de carga se puede reducir en cierta medida;
4) el nivel operativo de optimización
La tecnología no es el único medio para mejorar el rendimiento del sistema en muchas escenas de los problemas de rendimiento, de hecho, se puede ver una gran parte debido a los escenarios comerciales especiales que se presenten, si es capaz de evadir o ajuste en los negocios, de hecho, a menudo los más efectiva.