Paramètres ColdFusion pour les téléchargements de fichiers volumineux


8

J'essaie de configurer un serveur ColdFusion pour accepter les téléchargements de fichiers volumineux et je me heurte à certaines limites. Voici ce que j'ai observé jusqu'à présent:

Il existe deux paramètres dans ColdFusion Administrator qui limitent la taille des téléchargements: "Taille maximale des données de publication" et "Demande de mémoire de limitation". Si la taille de votre téléchargement (y compris la surcharge HTTP) est supérieure à l'un de ces paramètres, le téléchargement est rejeté. Je ne peux pas comprendre pourquoi nous en avons besoin de 2; celui qui est réglé plus haut n'a aucun effet pour autant que je sache. Le plus bas gagne.

Lorsque quelqu'un essaie de télécharger un fichier trop volumineux, il ne reçoit pas un joli message d'erreur. Le téléchargement se bloque pour toujours après l'envoi d'environ 1 fenêtre TCP de données. Et ça accroche vraiment mal. Même après que le client abandonne et se déconnecte, le thread Apache associé est toujours attaché (je peux le voir en utilisant mod_status). Les threads bloqués continuent de se constituer jusqu'à ce qu'il n'en reste plus pour prendre de nouvelles requêtes et que le serveur doive être redémarré.

Le "Request Throttle" est une chose que je ne comprends vraiment pas. Toute la documentation à ce sujet en parle comme de la taille d'une région mémoire. Si c'est ce que c'est, alors je ne vois pas comment cela est lié à la taille des fichiers. Cela fait allusion à quelque chose que je ne veux tout simplement pas croire: que ColdFusion détruit l'intégralité du fichier téléchargé en mémoire avant de l'écrire sur le disque. Aucune personne sensée ne ferait cela, quand une boucle de téléchargement (lire un bloc de taille moyenne, l'écrire sur le disque, répéter jusqu'à la fin) est si facile. (Je sais que la structure d'un article HTTP multipart / form-data le rend un peu plus difficile, mais ... une grande entreprise comme Adobe avec un produit de développement Web peut sûrement faire les choses correctement ... n'est-ce pas?)

Si le slurping de fichiers entiers est réellement ce qui se passe, comment s'attendent-ils à ce que nous choisissions une taille limite utilisable? Autoriser un gigaoctet et quelques utilisateurs simultanés peuvent exécuter votre serveur sans mémoire sans même essayer. Et qu'allons-nous faire, ne pas autoriser les téléchargements de gigaoctets? Les gens ont des vidéos à publier et pas le temps de les éditer!

INFOS SUPPLÉMENTAIRES

Voici quelques numéros de version.

Serveur Web:

Server: Apache/2.2.24 (Win64) mod_jk/1.2.32

Fusion froide:

Server Product           ColdFusion
Version                  ColdFusion 10,285437
Tomcat Version           7.0.23.0
Edition                  Enterprise
Operating System         Windows Server 2008 R2
OS Version               6.1
Update Level             /E:/ColdFusion10/cfusion/lib/updates/chf10000011.jar
Adobe Driver Version     4.1 (Build 0001)

INFOS SUPPLÉMENTAIRES # 2

Je ne sais pas pourquoi vous voulez savoir quelles valeurs j'ai mises dans les champs de limite, mais ils ont tous deux été définis sur 200 Mo pendant un certain temps. J'ai augmenté la "taille maximale des données de publication" à 2000 Mo et cela n'a pas eu d'effet. J'ai déjà compris que si j'augmente "Request Throttle Memory" à 2000 Mo, cela permettra un téléchargement plus important. Ce que je recherche ici, ce n'est pas un petit "truc plus gros là-dedans!" réponse, mais une explication détaillée de la signification réelle de ces paramètres et de leurs implications pour l'utilisation de la mémoire du serveur.

Pourquoi le thread du serveur se bloque indéfiniment au lieu de renvoyer un message d'erreur lorsque la limite est dépassée peut être une question distincte. J'ai supposé que ce serait un problème bien connu. Je devrais peut-être demander d'abord si quelqu'un d'autre peut le reproduire. Je n'ai jamais vu un message d'erreur "fichier trop volumineux" renvoyé à un client par ColdFusion. Est-il censé en avoir un?

INFOS SUPPLÉMENTAIRES # 3 Certaines expérimentations m'ont conduit à une réponse partielle. La première chose qui me manquait était que "Request Throttle Memory" (RTM) fait quelque chose d'utile s'il est défini plus haut que "Taille maximale des données de publication" (MSOPD). Lors de ma première série de tests, sans aucune idée de la relation entre eux, je les ai inversés. Avec ma nouvelle compréhension, je peux voir que le rapport RTM / MSOPD est le nombre de téléchargements simultanés qui seront autorisés s'ils sont tous proches de la taille maximale.

En supposant que la "demande de mémoire d'accélérateur" est en fait un tampon de mémoire et non un fichier temporaire, cela signifie que mes pires craintes étaient correctes. Chaque fichier est conservé entièrement en mémoire pendant toute la durée de son téléchargement. Personne n'a rien dit pour me faire croire le contraire (bien que je ne vois pas non plus quelqu'un sauter pour dire "oui, ils ont fait cette chose stupide")

Avec cette nouvelle compréhension également, les téléchargements bloqués ont un certain sens. Le serveur n'a pas de mémoire disponible pour accepter le téléchargement, il ne lit donc pas du socket. Les tampons TCP se remplissent, la taille de la fenêtre devient 0 et le client attend qu'il s'ouvre à nouveau, ce qui devrait se produire dès que le serveur commence à lire la demande. Mais dans mon cas, pour une raison quelconque, cela n'arrive jamais. Le serveur oublie complètement la demande, donc elle persiste.

Le cas de "Taille maximale des données de publication" qui est atteint est encore un peu mystérieux. Les demandes qui atteignent une limite stricte ne doivent pas être mises en file d'attente, mais simplement rejetées. Et je reçois un message de rejet ("La taille du message dépasse la limite maximale de 200 Mo.") dans server.log. Mais là encore, le serveur semble oublier la requête sans jamais envoyer d'erreur au client.


Deux questions: 1. Êtes-vous sûr qu'il s'agit de Cold Fusion, et non du serveur Web lui-même? et 2. Avez-vous examiné le délai d'expiration de la demande?
Katherine Villyard

1
Je suis sûr. Il n'y a pas de délai d'attente (le téléchargement remplit une fenêtre TCP, puis se bloque. Prouvé avec wirehark. Coupez quelques octets à la fin du fichier et il envoie en 13 secondes.) Et je peux publier un téléchargement sur une page HTML statique et il envoie bien (il n'est enregistré nulle part car il n'y a rien qui traite les données du formulaire, mais le fait est qu'elles ne calent pas.)

Réponses:


1

Je vais également essayer d'expliquer les paramètres de réglage: -

  • Nombre maximal de paramètres de demande POST - Il s'agit du nombre maximal d'attributs / paramètres envoyés sur une demande particulière. Utilisé en particulier, lors de la publication de données sur un formulaire.
  • Taille maximale des données de publication - Il s'agit des données maximales qui peuvent être publiées sur un serveur. Il s'agit de la somme de toutes les données sous une forme particulière lors d'une demande POST.
  • Seuil de limitation des demandes - ColdFusion peut limiter (ralentir avec force) les demandes entrantes si nécessaire. Cependant, de très petites demandes (celles avec une petite charge utile) peuvent être autorisées, quel que soit l'état de l'accélérateur. Pour permettre le traitement de petites demandes, spécifiez la taille maximale autorisée (la valeur par défaut est un maximum de 4 Mo).
  • Request Throttle Memory - Pour limiter les demandes, spécifiez la quantité maximale de mémoire allouée pour la limitation. S'il n'y a pas assez de mémoire totale disponible, ColdFusion met les demandes en file d'attente jusqu'à ce que suffisamment de mémoire soit disponible (la valeur par défaut est 200 Mo). Il ne réserverait pas la mémoire à Req1, car elle est inférieure à Threshold.

Considérez qu'il existe trois demandes simultanées Req1 (3 Mo), Req2 (6 Mo) et Req3 (9 Mo). Avec les paramètres par défaut, Request Throttle Threshold défini sur 4MB, ColdFusion réserve (6 + 9 = 15MB) dans la mémoire de l'accélérateur. De même, il continuerait à ajouter la mémoire de requête pour toutes les requêtes simultanées et la limite est celle que nous avons définie pour la mémoire de requête (la valeur par défaut est de 200 Mo).

J'espère que cela t'aides.


Ceci est similaire à toutes les autres descriptions que j'ai trouvées sur google. Tous omettent la seule chose que je devais savoir: cette demande de mémoire d'accélérateur est censée être plus grande que la taille maximale des données de publication. Et je suppose également que la demande de mémoire de limitation doit être inférieure à la taille de segment JVM, ce qui rend impossible le téléchargement de fichiers vraiment volumineux (proches ou plus grands que la RAM de votre serveur) en parallèle. Néanmoins, c'est la meilleure réponse jusqu'à présent, donc je vote en amont et je l'accepterai si rien d'autre ne se produit avant la fin de la prime

1

Vous pouvez utiliser cftry-catch pour capturer l'erreur et afficher un message personnalisé à vos utilisateurs. Cela dit, quelles sont les valeurs définies pour le nombre maximal de paramètres de demande POST, la taille maximale des données de publication, le seuil de limitation de la demande et la mémoire de limitation de la demande . Utilisez-vous CF Std ou Ent et quelle est la version de ColdFusion?


Il n'est pas possible d'attraper l'erreur avec cftry. La connexion se bloque sans jamais exécuter la première ligne du cfm. (J'y ai mis un cflog pour savoir s'il est allé si loin et ce n'est pas le cas.) J'ajouterai des informations de version à la question.

Le message d'erreur "Fichier trop volumineux" est généralement émis par le serveur Web et non par ColdFusion. Si vous n'avez rien trouvé dans les journaux CF, veuillez vérifier les journaux de l'Observateur d'événements. Il y aurait sûrement une référence à l'erreur. Avez-vous essayé "LimitRequestBody" d' Apache . Vous pouvez également spécifier la taille du fichier à la fin du serveur Web.
Anit Kumar
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.