UPLOAD html sur 1and1 (mutualisé)

Bonjour,
Mon problème concerne, sur un hébergement mutualisé chez 1and1, l'upload HTML, donc par un visiteur, à partir d'une page. Au départ le contexte était velu (Symfony3, BlueImp JQuery File Upload, AJAX/XMLHttpRequest, traitements tordus coté serveur) ce qui m'avait d'abord fait chercher ailleurs. J'en suis arrivé à identifier le problème à partir d'un code minimal, un simple formulaire:

page d'essai

Contexte des tests: Chrome/Firefox/Edge, ADSL montant 0,9Mbits/s immuable, descendant ~5Mbits/s avec variations dans la journée. Localement un serveur de tests (avec ISPConfig 3) configuré au plus proche de celui de production, mais connecté en gigabit.

Je voudrais pouvoir envoyer des images JPG issues de RAW, de poids de l'ordre de 20Mo, voire plus, limite placée à 50Mo. Un fichier de l'ordre de 1Mo suffit pour faire apparaître le problème, même s'il n'est pas encore vraiment gênant. Au plus simple, j'observe la barre d'état du navigateur et la fenêtre "réseau" du débugueur (F12). Je vois:
- Une phase A, envoi de la requête et donc du fichier, qui dure exactement ce qu'elle doit durer en fonction de mon débit montant. L'affichage du pourcentage de 0 à 100 est correct.
- Une phase B, qualifiée "Attente" ou "Waiting (TTFB)", qui est trop longue. Globalement, elle est proportionnelle à la taille du fichier. Avec une composante constante visible sur les petites valeurs. Plutôt instable, et ayant tendance à augmenter plus pour les grosses images. Par exemple pour ~4.5Mo, A durera ~45" et B de l'ordre de 20". Pour 20Mo, A sera à 3min1/2 et B autant voire un peu plus.
J'ai fait certaines vérifications sur la version complète, si je stoppe ou rafraîchis la page pendant la phase B, le processus se finalise (le contrôleur copie le fichier et met à jour la BdD). J'ai également vérifié que le site n'avait la main (entrée dans le contrôleur) qu'à la fin de B.

J'ai par ailleurs fait des essais d'upload sur des sites existants, je peux tout à fait mesurer les phases A et B. Sur le site de démo du plugin JQFU, la phase B est visible, mais très courte, 1.2" pour 12.5" pour A, pas pu voir pour de plus grosses valeurs, la taille étant limitée coté client. Sur CJoint, pas de de phase B significative. A noter que la démo utilise Apache, et CJoint NGINX.
Mon interprêtation, maintenant: ici par exemple je lis:

Citation:

---

The default behavior of file uploads in what still is the standard stack for web applications – Apache and PHP – is pretty straight-forward. The web server reads the incoming POST request, buffering the uploaded file onto the disk, and passes the request on to the PHP backend which, in turn, reads the request and saves the file again to its temporary directory. Sounds like too much overhead, doesn't it?

---

Je suppose (rien de plus, je suis une buse en architecture de gros serveur) que ma requête arrive sur une machine qui l'enregistre localement, c'est la phase A. Ensuite, c'est sur le LAN constituant l'hébergement que vont voyager le fichier et la requête (agrémentée du path d'arrivée du fichier), pour arriver sur la machine qui m'héberge, c'est 99,9..% de la phase B. Ce que je ne comprends pas, c'est le débit de cette opération, sans doute de l'ordre du Mbits/s.
Avec juste 10Mbits/s, ça passerait, en l'état, c'est très difficile à gérer, il faudrait refaire l'interface pour parer aux manipulations intempestives pendant la phase de silence, et même, avec 27Mo, j'ai eu une 504, c'est pas glop.
J'ai contacté l'assistance 1and1, sans trop insister, il m'a été gentiment suggéré que "le contrat était honoré". Normalement c'est passé au niveau "équipes techniques", je verrai bien. Ce que j'espère en exposant le problème, c'est de l'information pour décider. Les questions:
- L'hypothèse d'un réseau local très lent est-elle plausible ?
- Le débit particulier Socket->tranche peut-il être volontairement bridé, en cohérence par ailleurs avec les débits montants chez les clients ?
- Ou alors est-ce que je dois penser qu'il s'agit d'un problème global (système sous-dimensionné) ? Ou particulier, une "panne" concernant certains hébergements ?
- Si ce n'est pas trop compliqué, j'aimerais connaître le comportement (les temps A et B) pour un fichier de l'ordre de 2Mo, avec d'autres débits montants.
- C'est très compliqué, mais si quelqu'un pouvait tester ces temps sur un autre hébergement, ce serait la fête.
Merci d'avoir lu, bonne fin de journée...

Salut,

Y'a beaucoup de choses dans ce que tu dis, peut-être un peu trop pour que j'ai compris l'essentiel. Si tu as des problèmes d'upload sur un mutualisé tu peux essayer ce module d'upload.

En complément des informations disponibles en temps réel, la technique d'upload utilisée permet de surpasser les limitations serveur "upload_max_filesize", "post_max_size" et "max_file_uploads" sur les mutualisés professionnels type ovh, 1&1 etc. C'est la solution indiquée si ton problème se pose pour l'upload de gros fichiers et que tu veux surpasser ces limites.

C'est prêt à l'emploi donc tu pourras faire les premiers tests en quelques minutes, suffit de dézipper le dossier et de le mettre sur le serveur. Ce dossier comprend une quinzaine d'exemples directement fonctionnels et un mode d'emploi complet. Il y a aussi un tuto en ligne.

Merci,
Votre module est très bien distribué, j'ai effectivement pu le tester en quelques minutes. Il ne règle pas mon souci, à ceci près que ça met en lumière le fait que "sur-slicer" (chunks petits) améliore l'ergonomie, et peut-être la fiabilité. Je dois pouvoir paramétrer ça dans le plugin que j'utilise.
En ce qui concerne l'exposé confus du problème, la raison en est que je ne voulais pas donner comme certain mon diagnostic, mais exposer les symptomes (comme on devrait le faire chez le toubib). Ce diagnostyic est simplement que le temporaire que vous récupérez après un UPLOAD est lui-même issu par copie d'un temporaire-système auquel il n'est pas possible d'accéder. Et tout se passe comme si le transfert temporaire-système -> temporaire-utilisateur était long.
Avec votre module, pour un fichier de 20Mo, on constate trois POST, et un temps d'attente inopportun à la fin de chacun. La totalisation est cohérente avec le POST unique pour le même fichier.
Je vais faire des tests avec des chunks tout petit, peut-être 1Mo.
Je vous souhaite une bonne journée.

Citation:

---

Envoyé par Pierre Maurette

Avec votre module, pour un fichier de 20Mo, on constate trois POST, et un temps d'attente inopportun à la fin de chacun. La totalisation est cohérente avec le POST unique pour le même fichier.

---

C'est normal qu'il y ait trois post pour un fichier de 20 Mo puisque la taille par défaut des fragments est de 8Mo dans mes exemples. Tu peux modifier cette valeur comme tu veux avec un minimum de 1Mo.

Le temps d'attente est probablement dû à l'option de configuration javascript "config.ajaxTimeOut" qui est fixée par défaut à 500 millisecondes. C'est le délai entre deux requêtes ajax qui sert principalement pour les tests en local afin de ne pas surcharger l'ordinateur (et éviter de donner le coup de grâce d'un disque dur en cours d'agonie) avec des requêtes incessantes dans des cas extrêmes, par exemple pour de l'upload multiple dans des formulaires multiples et le tout simultanément. Tu peux régler la valeur de cette option et éventuellement la mettre à zéro quand tu configures la classe javascript en faisant :

Code:

---

1 2 3

var up = new UploadAjaxABCI('#form_base',destination_ajax,'#reponse_upload'); up.config.ajaxTimeOut = 0; $(function(){up.Start()});

---

EDIT : J'ai toujours pas compris où était ton problème exactement. L'upload ne fonctionne pas ? ou trouves-tu qu'il met trop de temps ? Si tu as des erreurs 504, effectivement tu peux essayer de diminuer la taille des fragments.

Bonjour,
Pour l'instant j'ai décidé de "faire avec". Mon code existant me permettant très simplement de paramétrer le "chunkage" et la taille des chunks, j'ai testé avec 1Mo (!!), le résultat est assez convaincant.

Pour ce qui est de "mon problème", je ne sais pas comment être plus explicite que dans mon second message.
J'ai posé votre module sur mon hébergement:
http://maurette.fr/test_upload/Uploa...adAjaxABCI.php
Essayez d'envoyer via "Upload 1" (ou "Upload 6") d'abord un fichier de 5Mo, par exemple à partir de Chrome + Developer Tools - onglet "Network". Tout va bien se passer pendant un temps qui dépend de votre vitesse montante (chez moi 45s pour 0.9mbps), affichage du pourcentage, du temps restant, de la barre de progression. Puis ça va se bloquer, pendant un temps qui à mon avis ne dépend que de l'hébergement, à peu près 15s actuellement, et pendant lequel tout est figé. Sur ce temps d'attente, seules quelques ms à la fin sont normalement explicables (vous connaissez le code à l'arrivée, et j'ai fait des tests montrant que le site n'a pas la main avant la toute fin de ce délai). Ensuite, les choses reprennent normalement.
Avec un fichier de 20Mo, vous verrez passer les trois chunks, avec un temps d'attente à la fin de chacun, 32.5s pour 8Mo pour les deux premiers. Accessoirement, vous pouvez constater qu'à la fin du premier chunk, le temps restant affiché est recalculé, c'est logique.
Je vois deux explications possibles: soit un réseau local peu performant, soit une limitation volontaire des performances en upload. Dans les deux cas, je peux exprimer le délai comme la somme d'une quasi-constante (traitement, réponse) souvent négligeable et d'un délai traduit par un (faux) débit. Ce débit diminuerait lorsque la taille des données (fichier, chunk) augmenterait. Je vais faire quelques mesures. La question se pose également de savoir si, dans le cas d'un upload "chunké", l'envoi n+1 démarre avant la fin du délai n.

Salut,

C'est bien d'avoir mis mon module en ligne, ç'a m'a permis de comparer avec des choses comparables. Donc oui l'upload se passe normalement, mais c'est le traitement côté serveur qui rame grave. Par comparaison sur un serveur ovh (offre perso) le temps de traitement côté serveur pour des fragments de 8Mo est de l'ordre de 3 à 4 secondes. Sur ton serveur j'ai eu minimum 45 secondes parfois plus d'une minute et parfois même le serveur plante. Cela doit donc venir de l'activité/encombrement de ton serveur.

Et en plus comme tu as essayé avec différentes solutions d'upload, on ne peut pas mettre le code en cause. La seule chose que tu puisse faire est de diminuer la taille des fragments vers le minimum. Cela dit chez ovh il semble que les quatre secondes de traitement soient à peu près constantes que ce soit pour des fragments de 4, 8 ou 16 Mo. Enfin bon, oui ton serveur chez 1&1 a de très mauvaises performances (on peut difficilement faire pire) et malheureusement avec un mutualisé, à part te plaindre auprès de ton hébergeur je ne vois pas de solution pour résoudre ce problème. Tu as quelle offre chez 1&1 ?