Comment fournir de gros fichiers ASP.NET Réponse?

Je ne suis pas à la recherche d'alternative de fichier de transmission en continu de contenu
la base de données, en effet, je suis à la recherche de la racine du problème, c'était
exécutant le fichier jusqu'à IIS 6, où nous avons donné notre application en mode classique, maintenant, nous
mise à niveau de notre IIS 7 et nous sommes application en cours d'exécution de la piscine en mode pipeline et
ce problème a commencé.

J'ai un gestionnaire d'événements, où j'ai à fournir de gros fichiers à la demande du client. Et je fais face à des problèmes suivants,

Fichiers sont de taille moyenne, de 4 à 100 MO, donc permet de considérer 80 MO de téléchargement de fichier cas.

De Mise En Mémoire Tampon, Démarrage Lent

Response.BufferOutput = True;

Il en résulte un démarrage très lent de fichier, comme utilisateur télécharge et même barre de progression ne s'affiche pas jusqu'à quelques secondes, généralement de 3 à 20 secondes, la raison est derrière, IIS lit tout le fichier d'abord, détermine la longueur du contenu et ensuite commencer le transfert de fichiers. Fichier est lu dans un lecteur vidéo, et il fonctionne très très lent, mais l'iPad ne télécharge que la fraction de fichier de sorte qu'il fonctionne rapidement.

De Mise En Mémoire Tampon, Aucune Content-Length, Démarrage Rapide, Aucun Progrès N'

Reponse.BufferOutput = False;

Il en résulte démarrage immédiat, toutefois client final (typique d'un navigateur comme Chrome) ne sait pas Content-Length qu'IIS ne sais pas non plus, de sorte qu'il n'affiche pas le progrès, au lieu de cela il dit X KO téléchargé.

De mise en mémoire tampon Off, Manuel Content-Length, Démarrage Rapide, le Progrès et la Violation de Protocole

Response.BufferOutput = False;
Response.AddHeader("Content-Length", file.Length);

Cette résultats dans le bon immédiate fichier de téléchargement dans google Chrome, etc, toutefois, dans certains cas, IIS gestionnaire de résultats dans la partie "Client Distant a Fermé la Connexion d'erreur" (ce qui est très fréquent) et d'autres WebClient résultats en violation de protocole. Ce qui se passe de 5 à 10% de toutes les demandes, pas toutes les demandes.

Je suppose que ce qui se passe est, IIS ne pas envoyer quoi que ce soit disant 100 continuer quand nous ne faites pas de mise en mémoire tampon et le client peut déconnecter n'attend rien en sortie. Cependant, la lecture de fichiers à partir de la source peut prendre plus de temps, mais à côté client, j'ai augmenté délai d'attente, mais semble comme IIS timesout et n'ont aucun contrôle.

Est-il de toute façon je peux forcer Réponse à envoyer 100 de continuer et de ne pas laisser quelqu'un de fermer la connexion?

Mise à JOUR

J'ai trouvé en-têtes suivants dans Firefox/Chrome, rien ne semble inhabituel ici pour Violation de Protocole ou de la Mauvaise Tête.

Access-Control-Allow-Headers:*
Access-Control-Allow-Methods:POST, GET, OPTIONS
Access-Control-Allow-Origin:*
Access-Control-Max-Age:1728000
Cache-Control:private
Content-Disposition:attachment; filename="24.jpg"
Content-Length:22355
Content-Type:image/pjpeg
Date:Wed, 07 Mar 2012 13:40:26 GMT
Server:Microsoft-IIS/7.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET

Mise à JOUR 2

Tournant de Recyclage encore n'offre pas beaucoup, mais j'ai augmenté mon MaxWorkerProcess à 8 et maintenant, je reçois un moins grand nombre d'erreurs, alors avant de.

Mais sur une moyenne de 200 demandes en une seconde, de 2 à 10 requêtes échouent.., et ce qui se passe sur presque tous les deux secondes.

Mise à JOUR 3

Continue 5% des demandes à défaut avec "Le serveur a commis une violation de protocole. Section=ResponseStatusLine", j'ai un autre programme qui télécharge le contenu à partir du serveur web qui utilise le service WebClient, et qui donne cette erreur 4-5 fois par seconde, sur une moyenne, j'ai 5% de demandes de défaut. Est de toute façon il trace WebClient échec?

Problèmes Redéfini

Fichier De Zéro Octet Reçu

IIS connexion se ferme pour une raison quelconque, côté client dans le WebConfig, je reçois 0 octets pour le fichier qui n'est pas zéro octets, Nous ne hachage SHA1 vérifier, cela nous a dit que dans le serveur web IIS, aucune erreur n'est enregistrée.

Ce qui a été mon erreur, et sa résolu en utilisant Entity Framework, c'était la lecture sale (non validées lignes) que lire n'était pas dans l'étendue de transaction, de le mettre dans l'étendue de transaction a résolu ce problème.

Violation De Protocole Exception Soulevée

WebClient jette WebException dit "Le serveur a commis une violation de protocole. Section=ResponseStatusLine.

Je sais que je peux activer dangereux d'en-tête d'analyse, mais qui n'est pas le point, quand il est de mon Gestionnaire HTTP qui est de l'envoi de la bonne en-têtes, je ne sais pas pourquoi IIS est l'envoi de quelque chose de supplémentaire (vérifié sur firefox et chrome, rien d'inhabituel), cela n'arrive que 2% du temps.

Mise à JOUR 4

Trouvé sc-win32 64 erreur et j'ai lu quelque part que WebLimits pour MinBytesPerSecond doit être changé, passant de 240 à 0, encore tout est identique. Toutefois, j'ai remarqué que chaque fois que les journaux IIS 64 sc-erreur win32, IIS registres d'État HTTP 200 mais il y avait une erreur. Maintenant, je ne peux pas tourner sur l'Échec de l'enregistrement des Traces pour 200 car le résultat sera massive de fichiers.

Les deux problèmes ci-dessus ont résolu en augmentant MinBytesPerSecond et ainsi que la désactivation des Séances, j'ai ajouté réponse détaillée résumant chaque point.

C'est pourquoi ils ont inventé le Protocole de Transfert de Fichiers 😉
FTP 100 mo n'est pas un remplacement, Linux serveurs de téléchargement fonctionne correctement, sa IIS qui agit drôle, plus drôle la partie est IIS ferme la connexion du client et met en cause en tant que Client Distant a Fermé la Connexion !!
Plus au point, c'est pourquoi IIS 7 a une "la diffusion en continu Lisse Module" pour diffuser de la vidéo à Silverlight et les autres clients
Bien de ses états membres, de la bienséance chose, nos données existe dans le magasin d'objets blob dans MS SQL, et les blobs sont décomposés en 1 MO taille, ils n'existent pas en tant que fichiers dans le disque, nous savons à propos de filestream et elle se bloque pour plus de 100K de fichiers, et nous avons autour de quelques millions de fichiers, de sorte que nous devons nous en tenir à ce que nous avons. La diffusion en continu lisse et Statique Fichier modules de travail sur chaque fichier existant sur le disque, il ne fonctionne pas dans mon cas.
Assez vrai 😉
Il peut être intéressant de voir ce que le gestionnaire de fichier statique fourni avec IIS7 fait pour les gros fichiers et copie de la solution quelle qu'elle soit.
Je pense, et le cas de la session, je mets à jour ma réponse, vérifiez si vous utilisez la session lorsque vous envoyez le fichier et désactivé.

InformationsquelleAutor Akash Kava | 2012-03-07

12

Bien que la bonne façon de livrer les gros fichiers dans IIS est l'option suivante,
1. Ensemble MinBytesPerSecond à Zéro dans WebLimits (Ce sera certainement aider dans l'amélioration de la performance, comme IIS choisit de fermer les clients qui détiennent des connexions Persistantes avec une plus petite taille transferts)
2. Allouer Plus de Processus de travail de l'Application de la Piscine, j'ai mis 8, maintenant cela devrait être fait seulement si votre serveur est en train de distribuer des fichiers plus volumineux. Ce sera certainement causer d'autres sites pour effectuer plus lent, mais cela va de mieux assurer les livraisons. Nous avons fixé à 8 que ce serveur n'a qu'un site web, il suffit de l'offre de gros fichiers.
3. Désactiver le Pool d'applications de Recyclage
4. Désactiver les Sessions
5. Congé De Mise En Mémoire Tampon Sur
6. Avant chacune des étapes suivantes, vérifiez si la Réponse.IsClientConnected est vraie, sinon abandonner et de ne pas envoyer quoi que ce soit.
7. De Contenu d'ensemble de la Longueur avant d'envoyer le fichier
8. Rincer la Réponse
9. Écrire Flux de Sortie, et Rincer à intervalles réguliers
InformationsquelleAutor Akash Kava
11

Lorsque vous avez défini la longueur du contenu avec le bufferOutput est fausse, alors la raison possible de l'échec est parce que IIS essayer de comprimer le fichier que vous envoyez, et en régler la Longueur du Contenu IIS ne peut pas le modifier à l'compressé, et les erreurs de chantier (*).

Donc keep the BufferOutput to false, and second disable the gzip from iis for the files you send ou désactiver iis gzip pour tous les fichiers et vous gérer le gzip partie de la programmation, de maintien de gzip les fichiers que vous envoyez.

Des questions similaires pour la même raison:
ASP.NET site parfois le gel et/ou en affichant bizarre de texte en haut de la page en cours de chargement, sur l'équilibrage de charge des serveurs

La Compression HTTP: Certains scripts externes/CSS de ne pas décompresser correctement de temps en temps

(*) pourquoi ne pas le changer à nouveau ? parce qu'à partir du moment où vous définir un en-tête, vous ne pouvez pas participer, sauf si vous avez activé cette option sur IIS et de prendre des cas que l'en-tête n'ont pas tous prêts envoyer au navigateur.

Suivi

Si pas gziped, la prochaine chose qu'il est venu à mon esprit, c'est que le fichier est envoyé et pour une raison quelconque, la connexion a eu du retard, et a obtenu un délai d'attente et fermé. Ainsi, vous obtenez le "Hôte Distant a Fermé La Connexion".

Cela peut être résolu en fonction de la cause:
1. Client vraiment fermé la connexion
2. Le délai d'attente est à partir de la page elle-même, si vous utilisez le gestionnaire (encore une fois, sans doute, le message doit être "à la Page a expiré" ).
3. Le délai d'attente est à venir à partir de l'arrêt en attendant, la page de la prendre plus que le temps d'exécution, obtient un délai d'attente et de fermer la connexion. Peut-être que dans ce cas, le message a la Page a expiré.
4. La piscine, faire un recyclage le moment d'envoyer le fichier. Désactiver tous les piscine recycle! C'est le plus possible les cas que j'en pense dès maintenant.
S'il est en provenance de l'IIS, allez dans les propriétés du site web et assurez-vous de définir le plus grand "Délai d'attente de Connexion", et "Activer les connexions HTTP persistantes".

Le délai de page en changeant le web.config (vous pouvez le modifier par programmation uniquement pour une page spécifique)
```
<httpRuntime executionTimeout="43200"
```
Également jeter un oeil à :
http://weblogs.asp.net/aghausman/archive/2009/02/20/prevent-request-timeout-in-asp-net.aspx

Session de verrouillage

Une chose que vous devez examiner est de ne pas utiliser de session sur le dispositif que vous utilisez pour envoyer le fichier, parce que la session se verrouille à l'action ce jusqu'à la fin et si un utilisateur de prendre plus de temps pour télécharger un fichier, une seconde peut obtenir le temps.

certains relative:

appel page aspx renvoie une image de ralentir au hasard

Remplacement ASP.Net s'session entièrement

Réponse.Fonction WriteFile échoue et donne 504 gateway time-out
- Tout ce que je suis en train de faire est, l'envoi de byte[] tampons, je ne suis pas l'envoi de fichiers, cependant, ressemble à une bonne idée, je vais vérifier sur elle.
- IIS Contenu Dynamique de Compression module n'est pas installé sur un de mes serveurs. Je suppose qu'IIS n'est pas la compression de contenu à tous les droits? ou est-ce quelque chose que j'ai explicitement éteindre quelque part d'autre? Par la manière, c'est mon MVC gestionnaire, et je suppose que le contenu dynamique est envoyé par nous. IIS Compression Statique est installé, dois-je le désinstaller trop?
- Vous pouvez facilement voir si les pages sont au format gzip, il suffit de regarder les en-têtes avec les outils du navigateur. Maintenant pas de désinstaller quoi que ce soit, juste désactivé. Dépendent de l'iis version de regarder sur internet comment vous pouvez le faire
- Vous pouvez le vérifier ma question, j'ai ajouté des en-têtes, je ne vois pas de compression. Aussi ce qui se passe de 5 à 10% des demandes, mais pas tous.
- Non bien sûr, il n'y a pas de gzip sur eux.
- Merci pour la mise à jour, j'ai mis tous connu des délais d'attente pour 1 heure, 3600, je pense que le recyclage est quelque chose qui est à l'origine de ce problème, j'ai fait creuser peu et a trouvé que mon ancien serveur qui exécute IIS en mode classique ne marche pas donner de tels problèmes, les pools d'applications s'exécutant en mode pipeline est donnant problème, mais j'étais sous l'impression qu'il ne le recycler si son inactivité, comment puis-je désactiver le recyclage et la façon d'améliorer les performances, j'ai un site web sur ce serveur et je veux seulement une piscine, un maximum de performance possible, même si cela prend 500mo pas de prob, 50% d'utilisation du processeur, pas de prob.
- Le recyclage a beaucoup d'options, peut faire recycler le repos, mais aussi sur la limite de mémoire, sur le temps de parvenir à l'heure, et d'autres... j'ai désactiver tous les recycler parce que je n'ai pas vraiment besoin d'eux, et je n'ai pas de problème. - aussi maintenant vous dites pipe-line, peut-être un module chargé de la vôtre faire de cette question, les vérifier.
- Je vous remercie pour votre temps, j'ai été en mesure d'améliorer les performances IIS et il y avait aussi un petit bug dans notre code, qui a été la lecture sale des lignes à partir de la base de données qui a causé les fichiers de zéro octet, d'autres que cela, j'ai reçu bounty pour vous, mais j'ai créé une nouvelle réponse en résumant tout. Merci également pour la Session point, je l'ai raté aussi, et il crée un grand nombre de cookies inutilement.
InformationsquelleAutor Aristos
5

Ce que je voudrais faire est d'utiliser la pas si bien connu ASP.NET Réponse.TransmitFile méthode, car il est très rapide (et, éventuellement, utilise IIS cache du noyau) et prend soin de tous les en-tête de trucs. Il est basé sur le Windows non géré TransmitFile API.

Mais pour être en mesure d'utiliser cette API, vous avez besoin d'un fichier physique pour le transfert. Donc, ici, est un pseudo-code c# qui expliquent comment faire cela avec une fiction myCacheFilePath physique chemin d'accès au fichier. Il soutient également la mise en cache du client de possibilités. Bien sûr, si vous avez déjà un dossier à la main, vous n'avez pas besoin de créer du cache:
```
    if (!File.Exists(myCacheFilePath))
    {
        LoadMyCache(...); //saves the file to disk. don't do this if your source is already a physical file (not stored in a db for example).
    }

    //we suppose user-agent (browser) cache is enabled
    //check appropriate If-Modified-Since header
    DateTime ifModifiedSince = DateTime.MaxValue;
    string ifm = context.Request.Headers["If-Modified-Since"];
    if (!string.IsNullOrEmpty(ifm))
    {
        try
        {
            ifModifiedSince = DateTime.Parse(ifm, DateTimeFormatInfo.InvariantInfo);
        }
        catch
        {
            //do nothing
        }

        //file has not changed, just send this information but truncate milliseconds
        if (ifModifiedSince == TruncateMilliseconds(File.GetLastWriteTime(myCacheFilePath)))
        {
            ResponseWriteNotModified(...); //HTTP 304
            return;
        }
    }

    Response.ContentType = contentType; //set your file content type here
    Response.AddHeader("Last-Modified", File.GetLastWriteTimeUtc(myCacheFilePath).ToString("r", DateTimeFormatInfo.InvariantInfo)); //tell the client to cache that file

    //this API uses windows lower levels directly and is not memory/cpu intensive on Windows platform to send one file. It also caches files in the kernel.
    Response.TransmitFile(myCacheFilePath)
```
- Nope, nous avons environ millions de fichiers, et nous voulons flux de blocs de bases de données directement, l'extraction de blocs et de création de fichier temporaire permettra d'ajouter des frais généraux de gestion et de les supprimer. Je veux trouver la cause du problème, pas de solution de rechange.
- Ce ne sont pas des "temp" les fichiers, mais à la place les fichiers mis en cache qui seront réutilisés sur les demandes ultérieures. Extraction de fichiers à partir d'une base de données à chaque requête n'est pas très bonne, d'où le cache de l'histoire, qui tire parti de Windows hi-perf inférieur IO couches. Et de stocker des millions de fichiers sur un disque n'est pas plus un problème que de stocker des millions de fichiers dans une base de données. C'est une solution pour les problèmes que vous décrivez.
- Nous traitons avec nos millions de fichiers dans la base de données depuis 7 ans, jusqu'à IIS 6.0 tout allait bien, ce problème est apparu récemment dans IIS 7.0 comme nous l'avons mis à jour nos serveurs. "L'extraction de fichiers à partir d'une base de données à chaque requête n'est pas très bon", avez-vous des tests de performance? Comment voulez-vous faire de vos données d'accès de l'ACIDE compatible avec juste des fichiers sur le disque? Ces questions sont hors de notre portée, je veux descendre en bas de la pourquoi IIS se comportent de façon étrange.
InformationsquelleAutor Simon Mourier

Ce bout de code fonctionne pour moi.
Il commence le flux de données pour le client immédiatement.
Il montre les progrès en cours de téléchargement.
Il ne viole pas les HTTP. Contenu de l'en-tête de Longueur est spécifiée et que le chuncked le codage de transfert n'est pas utilisé.

protected void PrepareResponseStream(string clientFileName, HttpContext context, long sourceStreamLength)
{
    context.Response.ClearHeaders();
    context.Response.Clear();

    context.Response.ContentType = "application/pdf";
    context.Response.AddHeader("Content-Disposition", string.Format("filename=\"{0}\"", clientFileName));

    //set cachebility to private to allow IE to download it via HTTPS. Otherwise it might refuse it
    //see reason for HttpCacheability.Private at http://support.microsoft.com/kb/812935
    context.Response.Cache.SetCacheability(HttpCacheability.Private);
    context.Response.Buffer = false;
    context.Response.BufferOutput = false;
    context.Response.AddHeader("Content-Length", sourceStreamLength.ToString    (System.Globalization.CultureInfo.InvariantCulture));
}

protected void WriteDataToOutputStream(Stream sourceStream, long sourceStreamLength, string clientFileName, HttpContext context)
{
    PrepareResponseStream(clientFileName, context, sourceStreamLength);
    const int BlockSize = 4 * 1024 * 1024;
    byte[] buffer = new byte[BlockSize];
    int bytesRead;
    Stream outStream = m_Context.Response.OutputStream;
    while ((bytesRead = sourceStream.Read(buffer, 0, BlockSize)) > 0)
    {
        outStream.Write(buffer, 0, bytesRead);
    }
    outStream.Flush();
}

InformationsquelleAutor HANiS

Vous devez vous connecter pour publier un commentaire.

Suivi

Session de verrouillage