Mes webservices sont aussi structurées comme suit:l'enregistrement séquentiel rapide pour webservices
- Recevoir la demande
- Parse et valider l'entrée
- Do webservice réelle
- Valider la sortie
Je suis principalement en utilisant la journalisation à des fins de débogage, si quelque chose ne va pas, je veux savoir quelle était la demande afin que je puisse espérer la reproduire (c'est à dire. envoyer exactement la même demande).
Actuellement, je me connecte à une table de base de données MySQL. Après 1. un enregistrement est créé, qui est mis à jour avec plus d'informations après 2. et 3. et nettoyé après 4. (Les journaux des demandes réussies sont élagués). Je veux que la diagraphie soit aussi rapide et indolore que possible. Toute accélération ici améliorera considérablement la performance globale (aller-retour de chaque demande). Je pensais utiliser INSERT DELAYED
mais je ne peux pas faire cela parce que j'ai besoin du LAST_INSERT_ID
pour mettre à jour et ensuite supprimer l'enregistrement de journal, ou au moins enregistrer le statut de la demande (ie succès ou erreur) donc je sais quand tailler.
Je pourrais générer un identifiant unique moi-même (ou au moins un identifiant qui est "assez unique") mais même alors je ne connaîtrai pas l'ordre des instructions DELAYED
et je pourrais finir par essayer de mettre à jour ou supprimer un enregistrement n'existe pas encore. Et puisque DELAYED
supprime également la possibilité d'utiliser NUM_AFFECTED_ROWS
Je ne peux pas vérifier si les requêtes sont effectuées.
Des suggestions?
Normalement, les personnes se connectent à un fichier txt. Consignez tout ce qui suit avec un guide commun pour chaque demande afin que vous puissiez post-traiter le fichier plus tard. La connexion directe à une base de données est excessive et lente. – epascarello
La journalisation dans une base de données n'est pas beaucoup plus lente que la journalisation dans un fichier, j'imagine, car les deux feront des opérations d'E/S. Je ne vois pas comment la journalisation dans une base de données est excessive. Cependant, je * ne * vois pas non plus pourquoi il est nécessaire de muter le disque trois fois. –