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.