Circulaire de vérification et de commutation des API pour maintenir des flux de traductions

[vBET]

Je comprends votre description et votre point de vue. Nous avons maintenant découvrir comment il suppose de travailler sur le plan technique.

Une question, que je vois ici, c'est comment nous reconnaîtrons que nous avons déjà les limites disponibles après celles où atteint avant.

Nous pouvons simplement chaque fois demander fournisseur préféré et puis aller vers le suivant. Ce coût performance - car pour chaque demande de page qui exige la traduction, qui nous fera infructueux appel au fournisseur préféré, puis au prochain un (donc il peut être plusieurs appels infructueuses lorsque vBET soutiendra plus API).

Autre solution consisterait à stocker les informations de ce fournisseur préféré n'est pas disponible et aller directement au prochaine une. Ce serait beaucoup plus rapidement, parce que la variable locale est beaucoup plus rapide que d'attendre de réponse du serveur externe de la vérification. Cette fois nous avons autre question - nous ne savons pas quand le fournisseur préféré est disponible. Nous pouvons évidemment fait quelque tâche planifiée qui demandait simple traduction (courte) par exemple une fois par heure par jour pour le vérifier. Donc dans cette stratégie, nous avons de décider combien de fois par défaut telle tâche suppose de travailler. Bien entendu nous il vérifie uniquement lorsque certains fournisseur est marqué comme non disponible.
Également si nous marquons fournisseurs comme indisponible - ce qu'il faut faire lorsque nous savons que tous les fournisseurs ne sont pas disponibles - ajouter des informations pour l'utilisateur final ou juste traduire ce qui est dans le cache et le reste en originales, sans n'importe quelle information supplémentaire sur l'absence temporaire de fournisseurs de traduction.

N'importe quelle façon ce sera fait, Google sera traitée comme une API (v1 ou v2 selon configuration) - il n'y a aucun sens de split, parce que v1 de Google sera fermé très bientôt.

Une autre chose est de permettre de configurer la file d'attente de fournisseurs pour chaque paire de langue séparément. En ce moment VB Enterprise permet déjà de configurer le fournisseur de traduction pour chaque paire de langue. Je pense que nous pouvons changer il d'une valeur de valeurs séparées par des virgules (CSV). De cette façon, nous saurons pour chaque paire de langue permettant aux fournisseurs de soutenir cette traduction et quels sont les préférences de l'ordre (ordre juste sur la liste CSV).

S'IL VOUS PLAÎT NOTE: Cela aura un impact sur les performances de toute façon. Au lieu de créer un objet pour la traduction, nous aurons créer le tableau de ces objets et l'objet emballage supplémentaires (pour le rendre transparent pour d'autres parties du code et moins de bogues sujettes). Bien entendu nous allons créer pas les objets pour nous savons les fournisseurs ne sont pas disponibles en ce moment.
Solution pour cela serait de reconfigurer pour de meilleures performances et supprimer la file d'attente de fournisseurs - tout comme il est maintenant - un seul fournisseur par paire de langue.
Cela ne devrait pas être cher pour les performances, mais encore quelques autre consommation logique et de la mémoire.

Veuillez indiquer quelle solution est préférable.