Nous avons une application .NET qui est distribuée sur 6 serveurs locaux avec une base de données locale (Oracle), 1 serveur principal et 1 machine de balance de charge. Les demandes sont arrivées à l'équilibreur de charge qui redirige les demandes entrantes à l'un des 6 serveurs locaux. Dans certains intervalles de temps, les données sont recueillies sur le serveur principal et redistribués aux 6 serveurs locaux pour pouvoir prendre des décisions avec les données complètes.
Chaque serveur local a un composant de cache qui cache les demandes entrantes en fonction de différents paramètres (emplacement, paramètres entrants, etc.). Avec chaque demande, un serveur local décide d'accéder à la base de données (Oracle) ou d'obtenir la réponse du cache. Toutefois, dans les deux cas, le serveur local doit aller à la base de données pour faire 1 insertion et 1 mise à jour par demande.
Un jour de pointe Chaque serveur local reçoit 2000 demandes par seconde et le système commence à ralentir (CPU: 90%). J'essaie d'augmenter la capacité avant d'ajouter un autre serveur local au mélange. Après avoir exécuté quelques points de repère, le goulot d'étranglement tel qu'il est toujours, semble être l'inévitable 1 insertion et 1 mise à jour par demande à la base de données.
Pour pouvoir diminuer la fréquence, j'ai créé un service Windows situé entre la DB et l'application .NET. Il contient un serveur de tuyauterie et reçoit chaque insertion et mise à jour de l'application principale .NET et les enregistre dans une hache. Le nouveau service ensuite à certains intervalles de temps passe à la base de données une fois pour faire des inserts et des mises à jour par lots. Le point était d'aller à la base de données moins fréquemment. Bien que cela ait eu un effet positif, il n'a pas bénéficié de la charge du système autant que prévu. La plus grande partie de la charge de la CPU provient de Oracle.exe comme demande la deuxième augmentation.
J'essaie d'éviter d'aller à la base de données autant que je peux et que le seul moyen d'éviter que DB semble augmenter le ratio de frappe de cache autre que la solution mentionnée ci-dessus que j'ai essayée. Mon ratio de frappe de cache est d'environ 81% pour cent actuellement. Parce que chaque machine locale a son propre cache, je manque en réalité beaucoup de demandes macabes. Lorsque deux demandes similaires redirigent vers différents serveurs, la deuxième demande ne peut bénéficier du résultat mis en cache du premier.
Je n'ai pas beaucoup d'expérience dans l'architecture du système, donc j'apprécierais de l'aide à ce problème. Toute suggestion sur différentes architectures de mise en cache ou installation ou tout outil est la bienvenue.
Merci d'avance, espérons-le, j'ai fait clairement ma question.
3 Réponses :
demandes de 2000 par seconde par serveur, environ 24 000 rps à la base de données. C'est une énorme charge pour DB. Essayez d'optimiser, de l'échelle ou de la base de données de clusterize.
Peut être NOSQL DB (Redis \ Raven \ Mongo), car le middleware vous conviendra. Le serveur local lira \ Ecrire Shardled NOSQL DB, les données agrégées seront synchronisées avec des heures d'arrêt oracle.
En fait, chaque serveur a sa propre base de données, de sorte qu'il ressemble davantage à 4000 RP par serveur sans le middleware que j'ai mentionné dans la section Méthodes éprouvées. J'ai édité la question pour que ces pièces soient plus claires. Nosql peut-être une bonne solution, mais le problème est que nous ne pouvons pas trop attendre pour synchroniser les données car les statistiques en direct sont utilisées dans la couche d'entreprise. L'intervalle de temps pour synchroniser les données est de 2 secondes maximum pour répondre aux besoins de l'application.
Statistiques en direct + Haute charge = Besoin de la base de données d'échelle.
Oui, nous devrons probablement ajouter un autre serveur au mélange. J'essaie juste de comprendre si nous avons la structure la plus optimisée pour une application comme celle-ci.
La performance de Facebook est d'environ la moitié du maximum, Twitter peut être 10 fois plus lente que peut être (à cause de Ruby). Mais qui se soucie? Cela fonctionne, ça gagne de l'argent. L'optimisation de l'architecture entière peut produire des bugs et des limitations. Vous trouvez de la base de données Bottleneck - Combattez ce goulot d'étranglement.
Pour moi, cela ressemble à une application pour une solution horodaye. Dans ce cas, vous pouvez éliminer les bases de données locales et revenir à une seule. Lorsque vous avez maintenant les bases de données Oracle locales, vous pouvez implémenter une grille de cache. Très probablement, cela va être un cache AWT (async, écrire). Voir Concepts de cache de base de données Oracle dans la mémoire Ce n'est pas une option bon marché, mais si cela pourrait être d'une enquête. Vous pouvez continuer à vous concentrer sur la logique commerciale et ne vous inquiétez pas de la vitesse. Ceci ne fonctionne bien sûr que bien, si le code d'aplication est déjà réglé et que le SQL est performant et évolutif. Le SQL doit être préparé (en utilisant des variables de liaison) pour avoir la meilleure performance. Votre application se connecte au cache et ne plus dans la base de données. Vous créez les tables de cache dans le groupe de cache pour laquelle vous souhaitez avoir la mise en cache. Toutes les tables d'un SQL doivent être mises en cache, sinon, la SQL complète est transmise à la base de données Oracle. Dans la grille, un mécanisme de fusion de cache est en place, vous n'avez donc aucune inquiétude sur l'emplacement des données de votre grille. Dans le support de version actuel pour .NET est inclus. Les données sont cohérentes et mises à jour de manière asynchrone à la base de données Oracle. Si les données nécessaires sont dans le cache et que vous prenez la base de données Oracle vers le bas, l'application peut continuer à courir. Dès que la base de données est de retour, la synchronisation ramasse à nouveau. Très puissant.
Cela ressemble à un gros changement de mise en œuvre, mais il convient de rechercher une enquête. Donc, si vous devez échouer horizontalement, vous ajouteriez un nouveau cache à la grille?
Je sais que la question est vieille maintenant, mais je voulais laisser tout le monde savoir comment nous avons résolu notre problème.
Après avoir essayé de nombreuses optimisations, il s'est avéré que tout ce dont nous avions besoin était des lecteurs d'état solides pour les 6 machines locales. La CPU a diminué jusqu'à 30% en pourcentage immédiatement après les avoir installés. C'est la première fois que j'ai vu une sorte de mise à jour du matériel contribue autant à la performance.
Si vous avez une configuration de charge élevée, avant de faire des changements de logiciels ou d'architecture, essayez de passer à une SSD.
Merci à tous pour vos réponses.