ASP.NET - demande de page Web pour décompresser le fichier sur le serveur

Question

Nous utilisons SharpZipLib . Nous devons être en mesure de décompresser les fichiers sur le serveur et placez-les dans le dossier séparé. La demande de décompresser un fichier sera d'un utilisateur sur une page Web. J'imagine que si les fichiers sont assez grands, il faudra beaucoup de temps pour décompresser. Nous ne voulons pas que les utilisateurs à coller sur la page en attendant Décompressez à remplir afin de continuer à naviguer sur le site.

Quelle est une bonne façon de gérer ce scénario: essaimer un thread différent pour prendre soin de fichier décompressé, créer un service Windows distinct qui décompresse les fichiers, ou .... quoi?

Quels sont les avantages et les inconvénients de le faire via thread séparé ou d'un service de fenêtre?

Answer 1

Les avantages d'un processus séparé Le travail effectué dans un processus séparé peut être découplé dans le temps, ainsi que physiquement, et du point de vue de la sécurité, du flux de page. Découplé dans le temps: Si vous choisissez, vous pouvez atténuer les demandes de dézipper les choses jusqu'à ce que « plus tard » lorsque la charge est plus faible et lorsque vous avez des cycles de cpu de rechange pour le faire.

En outre découplé physiquement; pour un grand système à grande échelle, vous pourriez avoir plusieurs processus de travail, même déployé sur plusieurs machines indépendantes, en faisant ce travail de manière asynchrone, et que la couche de traitement peut évoluer indépendamment du traitement de la page Web. Dans tout système il y a des goulots d'étranglement, et l'avantage de déploiements distribués est que vous pouvez faire évoluer les charges de travail séparées indépendamment, pour éliminer plus efficacement les goulots d'étranglement.

Je dirais cependant que ce dernier avantage est utile dans les systèmes à grande échelle très très grande. Dans la plupart des cas, vous n'aurez pas le genre de volume de transactions qui bénéficierait d'une couche de mise à l'échelle physique indépendante. Cela est vrai non seulement de votre la charge de travail, mais de 98% de toutes les charges de travail. Le principe YAGNI s'applique à l'évolutivité, aussi.

découplage physique permet également la charge de travail disparates (flux de pages et déballer zip) à développer de manière indépendante. En d'autres termes, en supposant que l'élément de travail n'a pas été un simple « Décompresser un fichier » mais a été quelque chose de plus complexe, avec de multiples étapes et points de décision le long du chemin. Concevoir le processeur de travail dans un processus séparé permet l'écoulement de la page à être construit et testé indépendamment dans le traitement de l'élément de travail. Cela peut être un bel avantage si elles doivent évoluer de façon indépendante.

Ce découplage physique est aussi bien si workitems arrivent via différents canaux. Supposons que la page Web n'est pas la seule façon pour un workitem arriver. Supposons que vous ayez une chute de ftp, un service Web ou une boîte de courrier électronique surveillé machine qui peut également recevoir des éléments de travail. Dans ce cas, il est logique d'avoir le traitement WORKITEM physicall découplé du traitement de la page Web.

Enfin, ces choses sont découplés dans la sécurité lors de l'exécution. Dans certains déploiements de serveurs d'applications Web, les règles de sécurité interdisent le serveur Web de l'écriture sur le disque - serveurs Web ont pas de stockage de disque inscriptible. Un processus de travail asynch séparé peut être déployé dans une partie séparée du réseau, avec beaucoup de rangement et il est peut-être limité par un ensemble distinct d'exigences de sécurité. Cela peut ou peut ne pas être applicable à vous.

Avantages de traitement hiérarchique L'avantage de faire le travail dans un thread séparé est qu'il est beaucoup plus simple. Découplage introduit la complexité et le coût. La gestion du travail dans un thread séparé, vous ne disposez pas des frais généraux de fonctionnement de la gestion d'un processus distinct, potentiellement une machine séparée. Il n'y a pas de configuration supplémentaire, aucune nouvelle construction / étape de déploiement. Pas de sauvegarde supplémentaire. Aucune identité de sécurité supplémentaire pour maintenir. Pas d'échange de communication à se soucier (au-delà de l'envoi de fil).

Vous pouvez choisir d'obtenir un peu plus sophistiqué sur le traitement des workitem, et éventuellement faire le travail de manière synchrone lorsque le zipfile semble assez petit. Supposons que vous établissez un seuil de 4 secondes le temps de réponse - au-dessus, vous avez besoin charge de travail asynchrone, en dessous de 4 secondes, vous le faites « en ligne ». Bien sûr, vous ne savez jamais exactement combien de temps un zipfile prendra, mais vous couldd établir une bonne heuristique basée sur la taille du fichier. Cette optimisation est disponible pour vous si vous utilisez un processus externe pour le travail async, ou un thread séparé, mais pour être honnête, il est plus simple de tirer profit de l'optimisation lorsque vous utilisez un thread séparé. Moins de travail supplémentaire à faire. Donc, cela est un avantage pour l'approche filetée.

Non différenciateurs Si vous choisissez d'avoir un mécanisme de vote AJAX pour la notification de l'état WORKITEM, tchapeau travaillerait avec soit le processus séparé ou le fil séparé. Je ne sais pas comment vous faire le suivi des éléments de travail, mais je suppose que lorsqu'un élément de travail particulier (fichier zip?) Est terminée, alors vous mettre à jour un dossier quelque part - un fichier dans un système de fichiers, une table dans une base de données . Cette mise à jour arrive si elle est faite par un fil dans le même processus, ou par un processus distinct (service Windows). Ainsi, le client AJAX que les sondages vont juste vérifier la table db ou système de fichiers dans tous les cas, et auront la notification du statut WORKITEM de la même manière, quelle que soit votre décision d'architecture.

Comment décider La théorie est intéressante mais finalement inutile, sans contraintes réelles de fonctionnement.

La charge de travail est l'un des éléments clés du monde réel. Vous ne dites pas la taille de ces fichiers zip sont, mais je suppose qu'ils sont « taille régulière ». Quelque chose au sujet 4gb ou moins. Normalement, un fichier zip comme ça prend 20-60 secondes pour décompresser sur mon ordinateur portable, mais bien sûr, sur un serveur avec un vrai système de stockage et processeur plus rapide, il sera moins. Vous aussi ne pas caractériser la concomitance des opérations - combien de ces choses vont se produire à un moment donné. Je suppose concurrence d'accès est pas particulièrement élevé.

Si tel est le cas, je tiens à l'approche de fil async plus simple. Vous faites cela dans ASP.NET, je suppose que sur un système d'exploitation du serveur. Le CLR a une bonne gestion des threads, et ASP.NET a une bonne capacité processus de montée en puissance. Ainsi, même dans les charges de travail élevées, vous obtiendrez une bonne utilisation du processeur et de l'échelle, sans une tonne d'effort de configuration.

Si les éléments de travail sont plus en cours d'exécution - disons de l'ordre des heures, voire des jours, et le temps était imprévisible (comme la fermeture d'un ordre d'achat d'actions) - bien dans ce cas, je pencherais vers un processus async. Si la concurrence était dans les milliers par seconde, ou encore très imprévisible, ce serait également recommander un processus distinct. Si les modes de défaillance ont été assez complexes, je pourrais avoir besoin d'être les éléments de travail dans un processus séparé juste pour le gérer. Si le traitement de workitem étaient susceptibles de changer régulièrement (en ajoutant une étape supplémentaire, en fonction de l'évolution des conditions d'affaires), je pourrais avoir besoin dans un processus séparé.

Mais aucune de ces choses semblent être vrai dans votre cas - le déballage des fichiers zip.

Answer 2

Les inconvénients d'un fil séparé sont les suivants:

1. Lorsque la page se termine il n'y a aucun moyen facile d'obtenir une notification sur ce que l'autre thread fait.
2. L'application pourrait être relancée à tout moment.
3. Il serait facile de démarrer accidentellement le processus deux fois si l'utilisateur soumet la page deux fois de suite.
4. du code multithread est difficile à déboguer.

Les avantages d'un thread séparé sont:

1. Moins de code
2. Facile à faire oublier le feu et si l'utilisateur n'a pas besoin d'être informé dès la Décompressez complète.
3. Pas de travail supplémentaire à installer.

Les avantages et les inconvénients d'un service de fenêtres sont à peu près le contraire de ce qui précède.

Answer 3

Personnellement, je descends la route de service Windows avec la messagerie entre eux pour le progrès, comme un retour à la Décompressez handle qui peut être utilisé pour surveiller l'état.

Cependant, vous pouvez aussi je pense que peut-être tourner au large d'un fil pour le faire et qui exécutera joyeusement et le retour de la page.

Answer 4

J'utiliser un processus asynchrone que vous pouvez facilement Interrogation une page AJAX. Lorsque vous avez terminé, la partie AJAX de la page peut présenter les détails que vous auriez normalement présentés pendant que l'utilisateur a attendu processus pour terminer de manière synchrone.