problème avec des données énormes

Question

J'ai un service WCF qui lit les données de xml. Les données au format XML sont modifiées toutes les 1 minute. Ce fichier XML est très grand, il a environ 16k enregistrements. L'analyse prend environ 7 sec. donc c'est définitivement trop long.

Maintenant, il fonctionne de cette façon:

1. appel ASP.NET WCF
2. WCF Parse xml
3. ASP.NET attend le rappel WCF
4. WCF génère des données à ASP.NET

Bien sûr, il y a une mise en cache pendant 1 minute, mais après que WCF doit charger à nouveau les données.

Y at-il une possibilité de faire quelque chose qui actualisera les données sans arrêter le site? Quelque chose comme ... Je ne sais pas, double tampon? cela va récupérer les anciennes données s'il n'y en a pas de nouvelles? Peut-être que vous connaissez une meilleure solution?

meilleures salutations

EDIT: la déclaration qui est la plus longue:

 XDocument = XDocument.Load(XmlReader.Create(uri)); //takes 7 sec. 

Parse prend 70 ms, son Okey, mais ce n'est pas le problème. Y at-il une meilleure solution pour ne pas bloquer le site? :)

EDIT2: Ok J'ai trouvé une meilleure solution. Simplement, je télécharge le xml au hdd et je lis les données de celui-ci. Ensuite, l'autre processus commence à télécharger une nouvelle version de xml et remplace l'ancien. Merci pour l'engagement.

Answer 1

Tout dépend de la conception de votre base de données. Si vous avez conçu la base de données d'une manière vous pouvez reconnaître quelles données sont déjà interrogées, puis pour chaque nouvelle requête retourner seulement une différence d'enregistrements de la dernière heure de la requête jusqu'à l'heure actuelle. Peut-être que vous pourriez ajouter rowstamp pour chaque enregistrement et le mettre à jour sur chaque action ajouter/modifier/supprimer, alors vous pouvez facilement réaliser la logique dès le début de cette réponse.

De même, si vous ne voulez pas que le premier appel soit long (lorsque les données initiales doivent être collectées), pensez à stocker ces données localement.

Utilisez autre chose que XML (comme JSON). Si vous avez un surdébit XML important, essayez de remplacer les noms longs par quelque chose de plus court (comme les noms d'éléments à caractère unique).

Jetez un oeil à ceci:

1. What is the easiest way to add compression to WCF in Silverlight?
2. Create JSON from C# using JSON Library

Answer 2

Si vous prenez quelques stackshots, il pourrait vous dire que le plus grand "goulot d'étranglement" n'est pas l'analyse, mais les données l'allocation de structure, l'initialisation et la récupération de place ultérieure. Si c'est le cas, un moyen de contourner le problème est d'avoir un groupe d'objets de ligne pré-alloués et de les réutiliser.

En outre, si chaque élément est ajouté à la liste, vous pouvez le trouver passant une grande partie du temps à effectuer l'ajout.Il pourrait être plus rapide de simplement pousser chaque nouvelle rangée sur le devant, puis d'inverser toute la liste à la fin.

(Mais ne pas mettre en œuvre ces choses sauf si vous prouvez ce sont des problèmes de stackshots. Jusque-là, ils ne sont que suppositions.)

Il a été mon expérience que le coût réel de XML n'est pas l'analyse syntaxique, mais la manipulation de la structure de données.

Answer 3

Vous semblez avoir un outil XML vers objet qui crée un modèle objet à partir du code XML.

Ce qui prend habituellement la plupart du temps n'est pas l'analyse syntaxique, mais la création de tous ces objets pour représenter les données.

Alors, vous pouvez extraire seulement une partie des données XML qui sera plus rapide pour vous et ne pas créer systématiquement un grand arbre d'objet pour extraire seulement une partie de celui-ci.

Vous pouvez utiliser XPath pour extraire les pièces dont vous avez besoin à partir du fichier XML par exemple.

Je l'ai utilisé dans le passé un outil d'analyse XML agréable qui met l'accent sur les performances. Il s'appelle vtd-xml (voir http://vtd-xml.sourceforge.net/).

Il prend en charge XPath et d'autres technologies XML.

Il existe une version C#. J'ai utilisé la version Java mais je suis sûr que la version C# a les mêmes qualités.

LINQ to XML est aussi un bel outil et il pourrait faire l'affaire pour vous.