Bonjour à toutes et tous,
Dolibarr 9.0.1, PHP7.3 et Nginx 1.14.2 sur une VM d’un serveur qui gaze à Roubaix…
Lien entre ici et là bas à 40 Mbps… Tout baigne…
Quelque soit la taille du fichier à déposer dans les [Fichiers Joints]…
Toujours 24 sec de process serveur après [Envoyer fichier…]
Le reste des fonctions Dolibarr est parfaitement rapide, tout gaze…
Si ça vous évoque quelque chose… merci d’avance 
Bien cordialement à toutes et tous…
@pm17 t’es un sacré trolleur 
@s_riviere
cette différence de performance ne provient pas de dolibarr, mais du serveur et/ou de la qualité de la connexion: il faut t’adresser à ceux qui gèrent ça.
Il existe des astuces pour mettre en cache des infos, mais ça n’est valable que dans certains cas. (surtout si nombreuses connexions simultanées, mais peut être pas que… jamais creusé le sujet)
(et j’ai expliqué hier soir à mes gamins la différence entre ping et bande-passante… je sais que c’est pas gagné )
Salut
Oui mais quelle taille de fichier, y a t il un antivirus ? Clamav ? Beaucoup d’interactions possibles !
@+
Merci pm17, mais hélas je suis nul au basket ))
C’est pas un pb de vitesse. C’est des fichiers de 15 Ko à 200 Ko au max (des factures d’achat). 15 Ko ou 200Ko toujours 24s pile (j’ai chronométré au dixième, pour rester dans le sport). Sur un lien à 40 Mbps, le serveur est au 1 Gbps et y’a un paquet de VM dessus qui gazent, des paquets de WP dessus, etc… non c’est pas ça…
Exact, c’est pas Dolibarr en cause. C’est une erreur de conf chez moi, c’est clair (ou une combinaison de versions dolibarr+php+…). Je demandais juste si quelqu’un avait eu un truc similaire… (je trouve ça rigolo 24s pile, j’ai jamais eu ça, c’est certainement lié à un timeout ou autre chose).
Y’a un clamav (merci pour l’idée !!! , j’ai stoppé le service, toujours 24s.
Je crois plus à une merdouille de conf nginx/php…
A vot’ bon cœur, sinon, faudra que je creuse… Ca doit être une vraie bonne bêtise comme d’ab…
Je me réponds à moi-même, grâce à une idée de Laurent (merci à lui) sur la ML…
Configuration / Sécurité / Fichiers (Envoyer fichier)
Chemin complet vers la commande antivirus : /usr/bin/clamscan
Supprimer /usr/bin/clamscan… (et laisser vide)
Temps de traitement abominable et… contant (par rapport à la taille)
Pour référence, le dernier message sur la ML…
============================================
Hi Laurent
> Check in setup - security if you have enabled an antispam tool executed after each upload and try to disable it if you have it.
I know you know you’re definitly the best but it’s worth repeating ))
Many thanks for pointing out the problem. I had already stopped the clamav service, but without thinking about a direct invocation from Dolibarr. I’m stupid
The next step should be why theses 24 s… To dig around that I made a little test :
With this 12K file : 20181121 - DBOOKER - SOW - manuels dolibarr.pdf
11:08-root@domu210:/srv/doc/erp1.soweb.io/admin/temp>/usr/bin/clamscan « 20181121 - DBOOKER - SOW - manuels dolibarr.pdf »
20181121 - DBOOKER - SOW - manuels dolibarr.pdf: OK
SCAN SUMMARY Known viruses: 6107219
Engine version: 0.100.2
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.03 MB
Data read: 0.01 MB (ratio 2.33:1)
Time: 22.591 sec (0 m 22 s)
So I retrieve (approx.) my 24 s…
Adding --debug shows all the clamscan (still slow) work against its signature database. I’ve searched the web with no results, except seeing many people complain about clamscan is now far more slower than in old days…
Tant mieux !
Mais c’était donc clamav comme je l’avait dit !
Vous aviez le scan activé lors de l’upload.
Arreter clamavd n’avait pas d’effet sur le clamscan mais sur la messagerie par exemple.
@+
C’est ça, vous aviez raison, j’étais stupide J’avais pas capté le clamscan lancé par Dolibarr… Arrêter le service n’avait aucun effet…
Bonjour,
Peut-être un peu tard pour répondre 
?
J’observe le même phénomène de lenteur avec clamscan (dolibarr 9.0.1 sur Centos). J’ai résolu le problème en utilisant clamdscan (pour autant que le service soit lancé ) avec comme option --fdpass, pour s’affranchir du problème de droit utilisateur du socket. Là, le temps de chargement redevient normal.
Merci Benoit,
J’ai repris le pb aujourd’hui, trouvé la même soluce que vous de mon coté et je me proposais dela mettre ici quand j’ai vu votre réponse… hi ! Ca mériterait d’être souligné en rouge 3 fois car, au vu des réponses sur le net, la plupart des gens sont plantés sur clamscan au lieu de clamdscan (plus --fdpass pour le socket)… Comme si clamscan ne pouvait pas utiliser par défaut clamscan-daemon si ce dernier est lancé… Il y a parfois des geeks très compliqués 
Merci en tout cas !
