1. Optimisation du système sous haute simultanéité-aperçu + test de pression autonome

Il existe de nombreuses optimisations sous simultanéité. Résumons-les et testons-les un par un:

Opération de lecture:

Le premier est l'optimisation autonome:

1. Base de données: optimisez les instructions pour éviter les requêtes floues, les virgules multi-tables, etc.

2. Base de données: opération de lecture: ajoutez un index à la base de données pour augmenter la vitesse de requête.

3. Base de données: augmentez le nombre de connexions de socket de base de données, augmentez le cache, etc.

4. Conteneur: augmentez la longueur de la file d'attente Tomcat, le nombre de threads, etc.

5. Conteneur: établir une longue connexion avec le client

Basculez ensuite vers un cluster:

6. Équilibrage de charge du proxy inverse Nginx

7.nginx établit une longue connexion

8. Rejoignez le cache et utilisez redis

9. Ajouter le cache de lecture nginx lua

10. Accélération cdn des ressources statiques

11. Utilisez des robots d'exploration pour rendre la page statique et accélérer le cdn

Ensuite, l'optimisation de la transaction de pointe:

12. Base de données: opération d'écriture: opération d'écriture par lots mybatis, réduit le temps de pré-compilation SQL.

13. Rejoignez mq, utilisez des messages transactionnels pour déduire l'inventaire et d'autres opérations

14. Émettre des jetons de pointe limités pour contrôler le trafic en fonction du nombre de marchandises et épuisés

15. Utilisez le pool de threads, comptez sur la file d'attente et sur la fenêtre de congestion en aval pour ajuster la file d'attente en cas d'inondation.

16. Ajouter un code de vérification

17. Utilisez RateLimiter de Guava pour effectuer des compartiments de type jeton afin de limiter le courant

Effectuez principalement ces tests de pression et trouvez la meilleure méthode d'optimisation.


Je ne considère pas le problème de bande passante en premier, donc j'ai installé une machine virtuelle localement et la configuration de test est:

version mysql:

Volume de données:

jdk :

 

Outil de mesure de pression: jmètre 

Test ci-dessous


Autonome:


De base (clé non primaire sans index):

1000 fils, 20 fois

Courir au milieu et s'arrêter, c'est vraiment terrible.


Ajoutez un index ordinaire (ne pas ajouter une autre table à un million):

Étant donné que la clé primaire est incrémentée, l'index unique n'est pas mesuré

1000 fils, 20 fois

Toujours arrêté au milieu, mais on peut encore voir qu'il y a encore une certaine amélioration.


Les deux tables sont indexées:

1000 fils, 20 fois

tps est apparu instantanément, montrant l'importance de l'indexation.


La requête utilise la clé primaire (une seule table est utilisée, l'autre table ne peut pas utiliser la clé primaire et l'index normal est toujours utilisé):

On peut voir que l'index n'est pas utilisé efficacement lorsque la clé primaire est utilisée. Mais dans des circonstances normales, la clé primaire sera plus efficace que l'index ordinaire, nous vérifions donc à travers une seule requête de table:

Requête de clé primaire:

Requête d'index générale:

En effet, les index ordinaires sont plus rapides. Je suppose que si l'ID est la clé primaire, un index cluster basé sur la clé primaire sera créé. Dans le cas de grandes données, une valeur de clé d'index peut correspondre à une ou plusieurs pages de données, ce qui fait un id va scanner plus de pages de données pour obtenir la valeur id. Pour les index ordinaires, vous pouvez vérifier directement dans l'index, de sorte que la vitesse est plus rapide que la clé primaire. Bien entendu, cette question doit être étudiée plus avant.


Augmentez le nombre de connexions de socket de base de données, de cache, etc.:

Il y a deux endroits notables: 

Lorsque innodb_data_file_path est configuré, vous devez supprimer l'original ou déplacer un emplacement.

Supprimez ib_logfile0 et ib_logfile1 sous / var / lib / mysql.

Le temps de connexion est légèrement modifié. Bien entendu, ces valeurs doivent encore être ajustées après le test.


Optimisation d'un seul conteneur:

Aucun paramètre et paramètre ajouté, le nombre de threads à l'exécution:

 


Plus de longues connexions?

/**
 * 当spring容器内没有TomcatEmbeddedServletContainerFactory这个bean时,会把此bean加载进spring容器中
 */
@Component
public class WebServerConfiguration implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        //使用对应工厂类定制化tomcat connector
        ((TomcatServletWebServerFactory) factory).addConnectorCustomizers(new TomcatConnectorCustomizer() {
            @Override
            public void customize(Connector connector) {
                Http11NioProtocol protocol = (Http11NioProtocol) connector.getProtocolHandler();
                //定制化keepalivetimeout,30秒
                protocol.setKeepAliveTimeout(30000);
                //客户端发送超过10000个请求自动断开
                protocol.setMaxKeepAliveRequests(400);
            }
        });
    }
}

Au lieu de cela, le tps est en panne, nous devons donc étudier plus tard Http11NioProtocol.

Publié 97 articles originaux · remporté 28 · 10 000+ vues

Je suppose que tu aimes

Origine blog.csdn.net/haozi_rou/article/details/105477951
conseillé
Classement