Bonjour,

Je ne sais si cette question est bien placée cette section alors désolé si ce n'est le cas.

Est-il normal que la fonction imap_open et consort soient "très tres" lentes?

Comparer au temps de lecture via un lecteur standart et le temps que j'obtiens en utilisant imap_open ca n'a rien à voir.

Cette lenteur est-elle due à php?
Au protocole IMAP liée aux fonctions php?
Est-ce un problème déja discuté?

Je tiens à préciser que ma class gère autant l'IMAP que le POP et que seul IMAP me pose ce problème. Mes tests passent via les serveur Gmail/La poste. Récupérer les headers, le nom
des boites, lire du body texte /html va encore mais récupérer une Pièce attachée romp la
connexion et ce "justement" à cause de ce délai. Je pourrais allonger le temps de connexion mais ca ne serait que sauter ce problème pour retomber dessus dans le futur.

Si quelqu'un peut s'aventurer à répondre j'apprécirai bien, merci à vous @+

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

et tu penses honnêtement que c'est ce que fait un client mail qui connecte un serveur imap?

c'est pas magique quand tu prends un piece jointe, ton script la télécharge, un client mail il ne fait que ce qu'il a besoin à l'instant T, cad il récuperes les headers, les titres, puis quand le user clique sur un mail, il télécharge le body, puis si y'a une piece jointe et que le user clicque dessus, il la télécharge.

ce n'est pas un probleme de perf de php ou de l'extension imap, mais un probleme de conception que tu as.

Salut Nagol, salut les gens,

Mon problème est (je le répète) : Temps minimum entre l'exécution de imap_open et la réception sur mon pc en protocol imap ~15 secondes. J'ajoute que ce n'est le cas qu'en IMAP avec imap_open. En pop c'est nikel et sur d'autres webmail (ex: gmail/laposte etc...) impécable. imap_open sur mon pc semble se reposer.... Ce qui m'amène à poser cette question.

$box = imap_open($server, $this -> _propertyUser[_user], $this -> _propertyUser[_passwd]);
.
.
.
imap_close($box);

et tu penses honnêtement que c'est ce que fait un client mail qui connecte un serveur imap?

Oulah, je pensais avoir été clair mais non, semble t'il lol alors toutes mes excuses
Et oui, c'est effectivement ce que fait un client Imap. ...et ce que fait ma class.

c'est pas magique quand tu prends un piece jointe, ton script la télécharge, un client mail il ne fait que ce qu'il a besoin à l'instant T, cad il récuperes les headers, les titres, puis quand le user clique sur un mail, il télécharge le body, puis si y'a une piece jointe et que le user clicque dessus, il la télécharge.

D'ou l'intéret d'Imap contrairement à pop par exemple.

Structure de ma class: -je squizz ici les moults tests-

>Connection du serveur imap et position dans la boxName désirée,
>Comptage des messages,
>lecture des entêtes,
>Position sur mail numéro 1 (ou uID selectionné) et affichage du body texte uniquement,
>Loading des pièces jointes par demande du user.
>close_imap.

suivant requete du user:

> position dans une boite nommée,
> position sur le mail voulu et lecture du texte,
> Rapatriement des pièces attachées.

Je pensais avoir indiqué que je ne faisais pas de load global, surement une erreur de ma part

ce n'est pas un probleme de perf de php ou de l'extension imap, mais un probleme de conception que tu as.

Vu mes propos, plus haut, je veux bien te donner raison, mais quelle erreur est possible entre open & close... s'entend et afin d'éviter toute méprise, je tiens à préciser que j'ai volontairement squizzé tout le code entre ses 2 fonctions pour tester et cibler au mieux le problème en local. C'est à ce niveau que le blocage se trouve.

Si quelqu'un a une solution à ce problème merci de poursuivre ce topic,

Bon code à tous @+

PS: Nagol, no offense de ma part. A vouloir trop bien décrire mon problème j'ai surement du donner des infos inutiles ou forçant la méprise, dsl

Bonjour les gens et navré d'abuser de votre temps,

Je n'arrive pas à comprendre pourquoi ce délai de latence et franchement, j'avoue
que ca m'énerve.

Je me suis décidé, ce jour, à prendre par bras le corps ce problème en installant Mercury
et voici le résultat:

> Aucun délai, réponse du serveur immédiate.

J'en conclus que c'est ma connexion (ADSL) qui merde mais en ce cas, et la je ne comprends pas du tout, pourquoi lors de connexion POP (par exemple) cette latence n'est pas présente? Mes DL sont normaux etc... Même quand je me log avec Pegasus sous proto IMAP sur gmail/laposte, etc : aucun problème. Si quelqu'un pouvait m'offir une réponse ou un embryon de réponse, je lui en serait reconnaissant.

Merci et encore désolé de polluer le fofo par cette question

Si ca peut aider dans la compréhension du soucis voici ma plateforme dédiée:

XP
Apache
php (5.2),
MySql,
SSL & IMAP actif
ZoneAlarme

Je vous laisse espérant une réponse, bon codage à vous @+

bien déja, si tu veux adopter une approche empirique ca serait bien d'avoir ce meme test avec un linux plutot qu'un windows, parceque je suspecte fortement que ton zonealarm ai quelquechose à voir avec ça. ensuite en fonction des résultats tu pourrais tenter de faire imap_open/imap_close sans rien d'autre au milieu, voir si ca ne pose pas de probleme, et comparer avec un fsockopen/fclose dans le cas ou tu aurais le meme résultat, tu peux déja mettre hors de cause php et te pencher sur un probleme d'ordre réseau.

Re les gens, Salut Nagol,

bien déja, si tu veux adopter une approche empirique ca serait bien d'avoir ce meme test avec un linux plutot qu'un windows, parceque je suspecte fortement que ton zonealarm ai quelquechose à voir avec ça.

Arf, si ZA en est la cause... ca me gavrait pas mal lol
En tout cas 1ere piste que je compte suivre.

ensuite en fonction des résultats tu pourrais tenter de faire imap_open/imap_close sans rien d'autre au milieu, voir si ca ne pose pas de probleme, et comparer avec un fsockopen/fclose dans le cas ou tu aurais le meme résultat, tu peux déja mettre hors de cause php et te pencher sur un probleme d'ordre réseau.

Ah, ca j'ai fait:

[...]
s'entend et afin d'éviter toute méprise, je tiens à préciser que j'ai volontairement squizzé tout le code entre ses 2 fonctions pour tester et cibler au mieux le problème en local. C'est à ce niveau que le blocage se trouve.

Pour Linux c'est une idée que je retiens itou mais ce serait sauter pour retomber, sur ce problème. Pour les sccks: Déja utilsé et pas de soucis niveau temps (j'aurai pu le préciser, autant pour moi).

Bon je replonge au fond de ma grotte. Je te remercie grandement pour les pistes.
Sympa de ta part, @

Tu peux abuser de la fonction microtime() pour tester.

Salut les gens, Salut Sékiltoyai,

Tu peux abuser de la fonction microtime() pour tester.

Vi, vi, j'utilise déja cette fonction dans mes class mais dans le cas qui m'interresse:
le délai se comptant en secondes (~15 dans le meilleur des cas) celle-ci s'avert peu utile.

Merci pour le post en tout cas

@+ les gens.

en cherchant un peu j'ai vu que certaines personnes avait eu des soucis similaires au tien, et qu'ils les avaient résolu en changeant le dns par une ip, donc tentes ça aussi pour voir si ca change quelquechose.

Re les gens, Salut Nagol,

en cherchant un peu j'ai vu que certaines personnes avait eu des soucis similaires au tien, et qu'ils les avaient résolu en changeant le dns par une ip, donc tentes ça aussi pour voir si ca change quelquechose.

...J'avoue que je fais plus que noter les pistes: je les essaie lol

° ZoneAlarm : Négatif. Je l'ai déconnecté mais problème identique.
° IP vs Nom : Négatif. J'accède au serveur mais toujours avec "beaucoup" de délai.

$access = imap_open("{74.125.79.111:993/imap/ssl/novalidate-cert}", "LOGIN", "PASSWD");
imap_close($access);

Donne le même temps de latence que:

$access = imap_open("{imap/gmail.com:993/imap/ssl/novalidate-cert}", "LOGIN", "PASSWD");
imap_close($access);

Ah, info supplémentaire que j'ai oublié d'indiquer une chose qui peut, peut-être, inciter à la
réflexion. Le ping que j'ai fais vers gmail donne ceci:

Minimum: 61ms, Maximum: 69ms , Moyenne 64ms. et 0 Perte.
Quand je vois un délai avec imap_open de 15 à 20 secondes...

J'ai pas re-re-testé avec d'autres serveurs IMAP mais, bon, vu que ca donnerait le même résultat...

Ca me laisserait penser à un problème uniquement ciblé proto IMAP Pourtant avec Pegasus
je rapatrie mes mails de cette façon... Autant IMAP que POP, et ce, sans soucis.

Non, vraiment je ne comprends pas. Le problème est bien au niveau du transit des datas, donc de la connexion mais utilsant, par ailleurs, SMTP et POP qui, eux ne merdoient pas...
Rah, j'aime pas ne pas comprendre lol
Bon, bref, je crois que j'ai assez monopolisé le fofo. Je laisse ouvert le topic, au cas ou. Si vous avez une idée: hésitez pas et de mon côté si la solution pointe son nez je vous la posterai.
J'ai, pour mes tests, installé Mercury ca contourne le problême et me permet d'avancer en
...attendant

Merci encore pour tes posts Nagol et bon code @+

ah non, on abandonne pas, c'est naze de pas piger et ton soucis est intéressant.

tentes aussi sans ssl stp et poses des timers individuels pour le open et le close.

check le cas de ce monsieur et testes son code pour voir

http://www.phpfreaks.com/forums/index.p ... 628.0.html

Salut Nagol, Salut les gens,

ah non, on abandonne pas, c'est naze de pas piger et ton soucis est intéressant.
tentes aussi sans ssl stp et poses des timers individuels pour le open et le close.

T'inquiete pas si je mets de côté, je n'abandonne pas

Pour les accès non protégés c'est idem. Le délai est équivalent par imap_open dès l'instant ou je
tente en proto imap.

check le cas de ce monsieur et testes son code pour voir
http://www.phpfreaks.com/forums/index.p ... 628.0.html

Merci pour le lien, je viens de tester le résultat suit. Quand je parle de délai infernal...

$dMicroTime = microtime();

$hSock = fsockopen("imap.gmail.com", 993, $errno, $errstr, 30);
if (!$hSock) die("...!");

$dMicroTime_1 = microtime()-$dMicroTime;

$dMicroTime = microtime();
$dMicroTime_2 = microtime()-$dMicroTime;

$hBox = imap_open("{imap.gmail.com:993/imap/ssl/novalidate-cert}INBOX", $login, $passwd);
if (!$hBox) die("...!");

imap_close($hBox);

echo "Test 1 : ".$dMicroTime_1."<br />";
echo "Test 2 : ".$dMicroTime_2."<br />";

Les timers results donnent ceci:

Test 1 : 0.074622
Test 2 : 1.8E-5

Donc effectivement en access sock c'est immédiat mais dès que j'utilise imap_open ce devient du vrai n'importe quoi... Pour le MC (bien qu'inutile avec un délai si long je me suis amusé à l'intégrer)
...juste pour le fait de dire lol

Bon, je dois déco, je reviens plus tard merci encore de percéverer... et m'inciter à le faire,

Bon code à tous, @+ les gens

reste encore plusieurs voix à explorer, linux/windows ca en est ou?

sinon faut checker les version de php... php4 vs php5

reste encore plusieurs voix à explorer, linux/windows ca en est ou?
sinon faut checker les version de php... php4 vs php5

Salut,

° Yep mais ma plate-forme est vieille et juste XP. L'installe de Linux sur celle-ci est pas prévue/voir impossible. ...tout de même et pour aller dans ton sens j'héberge mon site sur Linux et la: no soucis. Aucun délai, connection normale.

° Mon site d'hébergement est php 5... inutile de faire co-éxister php4/5 sur mon serveur...
'fin, il me semble

Bref, ne pas comprendre ce problème est un brin chiant lol

Je récapitule ca permetra déja d'y voir plus clair:

Le soucis n'éxiste qu'avec la fonction:
imap_open en proto IMAP port 993 ou 143, sur Plate-forme XP, Apache, PHP 5.2 et IMAP d'actif

Sans problème en revanche:
sous imap_open en protocole POP quelque soit le port 110/995
non plus avec sockopen et quelque soit le proto et le port.

Je me demande si une micro-déconnection pendant l'exécution d'imap_open ne pourrait pas
être responsable de ca.

Tel que je vois (imagine) la chose:

[*] imap_open envoie sa demande de connection mais s'il y a micro-déco, il renvoie une requete, mais comme... [Désolé je phantasme un peu mais c'est dans l'idée] Réussi enfin à se connecter et reste bloqué à la réception etc... Mais comme micro-déco la reconnection assure quand même le transport mais dans un délai excessif.

Me vient une idée, j'en parle après l'avoir essayé @+

[*] paragraphe pas très clair, désolé

EDIT:

Même soucis, encore un coup dans l'eau. Je viens de jouer avec les options et l'argument n-retries.
ca me renvoit toujours la main dans un délai inacceptable. Autrement dit: ma "brillante" téhorie semble inéxacte (n-retries semble le confirmer, j'ai tenté 0, 1 et 2) donc mon ébauche de soluce est un pur échec lol

@+ je reviens un peu plus tard