Comment améliorer le temps de chargement XML de PHP?

Question

Laisser tomber mon statut de lurker pour enfin poser une question ...

J'ai besoin de savoir comment je peux améliorer les performances d'un script PHP qui tire ses données à partir de fichiers XML.

Un peu d'histoire:

• Je l'ai déjà mis en correspondance le goulot d'étranglement à la CPU - mais qui veulent optimiser les performances du script avant de prendre un coup sur les coûts de traitement. Plus précisément, la partie du script la plus consommatrice de CPU est le chargement XML. La raison pour laquelle j'utilise XML pour stocker des données d'objet parce que les données doivent être accessibles via une interface de navigateur Flash, et nous voulons fournir un accès utilisateur rapide dans ce domaine. Le projet n'en est encore qu'à ses débuts, donc si la meilleure pratique serait d'abandonner complètement le XML, ce serait aussi une bonne réponse. Beaucoup de données: Tracer actuellement pour environ 100k objets, mais généralement de petite taille - et ils doivent tous être repris dans le script, à quelques rares exceptions près peut-être. L'ensemble de données ne fera que croître avec le temps. Essais fréquents: Idéalement, nous exécuterions le script ~ 50k fois par heure; De manière réaliste, nous nous contenterions de courses de ~ 1k/h. Ceci, associé à la taille des données, rend l'optimisation des performances absolument indispensable.

• Déjà effectué une étape d'optimisation consistant à effectuer plusieurs passages sur les mêmes données plutôt que de les charger pour chaque exécution, mais cela prend encore trop de temps. Les analyses doivent généralement utiliser des données "fraîches" avec les modifications effectuées par les utilisateurs.

Answer 1

Juste pour clarifier: les données que vous chargez proviennent-elles de fichiers XML à traiter dans leur état actuel et sont-elles modifiées avant d'être envoyées à l'application Flash?

Il semble que vous feriez mieux d'utiliser une base de données pour stocker vos données et de les sortir de XML au besoin plutôt que de les lire en XML au préalable; Si la construction des fichiers XML ralentit, vous pouvez mettre en cache les fichiers au fur et à mesure qu'ils sont générés afin d'éviter la génération redondante du même fichier.

Answer 2

Si le XML reste, vous pouvez relativement statique, le cache comme un tableau PHP, quelque chose comme ceci:

<xml><foo>bar</foo></xml> 

est mis en cache dans un fichier comme

<?php return array('foo' => 'bar'); 

Il devrait être plus rapide pour PHP d'inclure simplement la version groupée du XML.

Answer 3

~ 1k/heure, 3600 secondes par heure, plus de 3 pistes une seconde (et encore moins 50k/heure) ...

Il y a beaucoup de questions. Certains d'entre eux sont:

• Votre script php doit-il lire/traiter tous les enregistrements de la source de données pour chaque exécution? Sinon, de quel type de sous-ensemble a-t-il besoin (~ taille, critères, ...)
• Même question pour l'application flash + qui envoie les données? Le script php? Demande "directe" pour le fichier xml statique complet?
• Quelles sont les opérations effectuées sur la source de données?
• Avez-vous besoin d'un mécanisme de concurrence?
• ...

Et juste parce que vous voulez fournir des données XML aux clients flash, cela ne signifie pas nécessairement que vous devez stocker des données XML sur le serveur. Si par exemple les clients n'ont besoin que d'un petit sous-ensemble des enregistrements disponibles, il est probablement beaucoup plus rapide de ne pas stocker les données en XML, mais quelque chose de plus adapté à la vitesse et à la "recherche" et de créer la sortie XML du sous-ensemble. assisté par un cache en fonction de quelles données la demande du client et comment/combien les données changent.

edit: Supposons que vous ayez vraiment, vraiment besoin de l'ensemble des données et que vous ayez besoin d'une simulation continue. Ensuite, vous pourriez envisager un processus continu qui garde en mémoire le «modèle mondial» complet et qui fonctionne sur ce modèle à chaque exécution (tick du monde). De cette façon au moins vous n'auriez pas à charger les données sur chaque tick. Mais un tel processus est généralement écrit dans autre chose que PHP.