j'ai fais un petit essai comme ca.
j'ai fait un appel ajax a un script PHP qui ne fait strictement rien.
et la surprise:
64ms !!!
alors evidement il y a le temps de l'appel et du transfert (car je ne suis
pas en local) des données (meme si mon script ne fait rien) mais 64ms ca
parait beaucoup non ?
evidement on va me répondre que ca dépend de mon serveur, mais c'est quand
meme in bi-opteron.
Est-ce que quelqu'un pourrait faire le test chez lui et me dire ce qu'il en
est.
PS : pour timer j'utilise le tres excellent firebug !!!
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
John GALLET
Bonjour,
j'ai fais un petit essai comme ca. j'ai fait un appel ajax a un script PHP qui ne fait strictement rien. et la surprise: 64ms !!!
Mouais. Rien d'alarmant pour le moment. Tu parlerais d'une requête sql on pourrait regarder, mais une requête http... Et sachant que l'OS qui mesure n'est pas temps réel, il faudra lisser sur un bon millier d'appels et prendre le médian pour que ça cause. En laissant le temps aux sockets de se fermer et en désactivant le keep alive.
alors evidement il y a le temps de l'appel et du transfert (car je ne suis pas en local) des données (meme si mon script ne fait rien) mais 64ms ca parait beaucoup non ?
Pas nécessairement. Il faut faire une requête DNS si on n'a pas l'IP associée dans le cache, ouvrir une socket vers la machine distante en traversant tous les équipements réseau physique ou logiques (firewalls logiques style ip_tables, proxy parfois), donner la main sur le microprocesseur au process qui a reçu la requête en gérant l'IO sur le fichier demandé, parser le fichier, exécuter son contenu, renvoyer les headers http automatiquement ajoutés par le serveur s'ils ne sont pas surchargés, envoyer le résultat du script. Et on ne sait pas exactement quand le compteur s'arrête (réception d'octets spécifiques, fermeture socket ?).
evidement on va me répondre que ca dépend de mon serveur, mais c'est quand meme in bi-opteron.
Vu le temps d'exécution du script, avec un 486 ça répondrait à peu près aussi rapidement si tu n'as pas eut besoin de forker un process juste pour répondre. En revanche, ça dépend de la charge machine (load).
Est-ce que quelqu'un pourrait faire le test chez lui et me dire ce qu'il en est. Si tu donnes le code js contenant l'url pourquoi pas.
PS : pour timer j'utilise le tres excellent firebug !!! Ah non, moi j'ai lynx comme navigateur ;-)
Blague à part: si tu veux comparer des chiffres qui te permettent de savoir qui prend du temps:
1) appeler une page http statique sans ajax 2) appeler une page http statique avec ajax 3) appeler une page php sans ajax 4) appeler une page php avec ajax
D'abord avec une requête DNS (attention au cache), puis sans requête DNS (ip en dur).
Si ton script php est vraiment vide <?php echo '<HTML></HTML>'; ?> par exemple ça devrait être assez similaire. Il est difficile sans autres tests et valeurs vraiment différentes d'incriminer PHP ou l'implémentation ajax de ton navigateur ou le réseau ou apache ou le Dieu Root. Tu peux aussi avoir des gags liés au dialogue avec le navigateur (i.e. flush intempestifs). Bref, ce genre de choses est plus compliqué que ça en a l'air (marrant, ça me rappelle quelque chose sur les allers-retours inutiles de données...)
a++; JG
Bonjour,
j'ai fais un petit essai comme ca.
j'ai fait un appel ajax a un script PHP qui ne fait strictement rien.
et la surprise:
64ms !!!
Mouais. Rien d'alarmant pour le moment. Tu parlerais d'une requête sql on
pourrait regarder, mais une requête http... Et sachant que l'OS qui mesure
n'est pas temps réel, il faudra lisser sur un bon millier d'appels et
prendre le médian pour que ça cause. En laissant le temps aux sockets de
se fermer et en désactivant le keep alive.
alors evidement il y a le temps de l'appel et du transfert (car je ne suis
pas en local) des données (meme si mon script ne fait rien) mais 64ms ca
parait beaucoup non ?
Pas nécessairement. Il faut faire une requête DNS si on n'a pas l'IP
associée dans le cache, ouvrir une socket vers la machine distante en
traversant tous les équipements réseau physique ou logiques (firewalls
logiques style ip_tables, proxy parfois), donner la main sur le
microprocesseur au process qui a reçu la requête en gérant l'IO sur le
fichier demandé, parser le fichier, exécuter son contenu, renvoyer les
headers http automatiquement ajoutés par le serveur s'ils ne sont pas
surchargés, envoyer le résultat du script. Et on ne sait pas exactement
quand le compteur s'arrête (réception d'octets spécifiques, fermeture
socket ?).
evidement on va me répondre que ca dépend de mon serveur, mais c'est quand
meme in bi-opteron.
Vu le temps d'exécution du script, avec un 486 ça répondrait à peu près
aussi rapidement si tu n'as pas eut besoin de forker un process juste pour
répondre. En revanche, ça dépend de la charge machine (load).
Est-ce que quelqu'un pourrait faire le test chez lui et me dire ce qu'il en
est.
Si tu donnes le code js contenant l'url pourquoi pas.
PS : pour timer j'utilise le tres excellent firebug !!!
Ah non, moi j'ai lynx comme navigateur ;-)
Blague à part: si tu veux comparer des chiffres qui te permettent de
savoir qui prend du temps:
1) appeler une page http statique sans ajax
2) appeler une page http statique avec ajax
3) appeler une page php sans ajax
4) appeler une page php avec ajax
D'abord avec une requête DNS (attention au cache), puis sans requête DNS
(ip en dur).
Si ton script php est vraiment vide <?php echo '<HTML></HTML>'; ?> par
exemple ça devrait être assez similaire. Il est difficile sans autres
tests et valeurs vraiment différentes d'incriminer PHP ou l'implémentation
ajax de ton navigateur ou le réseau ou apache ou le Dieu Root. Tu peux
aussi avoir des gags liés au dialogue avec le navigateur (i.e. flush
intempestifs). Bref, ce genre de choses est plus compliqué que ça en a
l'air (marrant, ça me rappelle quelque chose sur les allers-retours
inutiles de données...)
j'ai fais un petit essai comme ca. j'ai fait un appel ajax a un script PHP qui ne fait strictement rien. et la surprise: 64ms !!!
Mouais. Rien d'alarmant pour le moment. Tu parlerais d'une requête sql on pourrait regarder, mais une requête http... Et sachant que l'OS qui mesure n'est pas temps réel, il faudra lisser sur un bon millier d'appels et prendre le médian pour que ça cause. En laissant le temps aux sockets de se fermer et en désactivant le keep alive.
alors evidement il y a le temps de l'appel et du transfert (car je ne suis pas en local) des données (meme si mon script ne fait rien) mais 64ms ca parait beaucoup non ?
Pas nécessairement. Il faut faire une requête DNS si on n'a pas l'IP associée dans le cache, ouvrir une socket vers la machine distante en traversant tous les équipements réseau physique ou logiques (firewalls logiques style ip_tables, proxy parfois), donner la main sur le microprocesseur au process qui a reçu la requête en gérant l'IO sur le fichier demandé, parser le fichier, exécuter son contenu, renvoyer les headers http automatiquement ajoutés par le serveur s'ils ne sont pas surchargés, envoyer le résultat du script. Et on ne sait pas exactement quand le compteur s'arrête (réception d'octets spécifiques, fermeture socket ?).
evidement on va me répondre que ca dépend de mon serveur, mais c'est quand meme in bi-opteron.
Vu le temps d'exécution du script, avec un 486 ça répondrait à peu près aussi rapidement si tu n'as pas eut besoin de forker un process juste pour répondre. En revanche, ça dépend de la charge machine (load).
Est-ce que quelqu'un pourrait faire le test chez lui et me dire ce qu'il en est. Si tu donnes le code js contenant l'url pourquoi pas.
PS : pour timer j'utilise le tres excellent firebug !!! Ah non, moi j'ai lynx comme navigateur ;-)
Blague à part: si tu veux comparer des chiffres qui te permettent de savoir qui prend du temps:
1) appeler une page http statique sans ajax 2) appeler une page http statique avec ajax 3) appeler une page php sans ajax 4) appeler une page php avec ajax
D'abord avec une requête DNS (attention au cache), puis sans requête DNS (ip en dur).
Si ton script php est vraiment vide <?php echo '<HTML></HTML>'; ?> par exemple ça devrait être assez similaire. Il est difficile sans autres tests et valeurs vraiment différentes d'incriminer PHP ou l'implémentation ajax de ton navigateur ou le réseau ou apache ou le Dieu Root. Tu peux aussi avoir des gags liés au dialogue avec le navigateur (i.e. flush intempestifs). Bref, ce genre de choses est plus compliqué que ça en a l'air (marrant, ça me rappelle quelque chose sur les allers-retours inutiles de données...)
a++; JG
Mickael Wolff
Salut.
j'ai fais un petit essai comme ca. j'ai fait un appel ajax a un script PHP qui ne fait strictement rien. et la surprise: 64ms !!!
Et je parie qu'un ping met une quarantaine de secondes à être retourné.
alors evidement il y a le temps de l'appel et du transfert (car je ne suis pas en local) des données (meme si mon script ne fait rien) mais 64ms ca parait beaucoup non ?
Non. Sauf si c'est en local, là je m'inquiéterais.
evidement on va me répondre que ca dépend de mon serveur, mais c'est quand meme in bi-opteron.
Je croyais que seul les gogo de la bulle Internet se faisaient avoir par le marketing d'Intel, qui affirmait qu'acheter un Pentium III (ou IV ?) accélérait l'Internet.
PS : pour timer j'utilise le tres excellent firebug !!!
C'est vrai que c'est un outil intéressant. Mais très franchement, les temps qu'il donne sont à relativiser les uns par rapport aux autres, car il introduit évidement des erreurs de mesure.
j'ai fais un petit essai comme ca.
j'ai fait un appel ajax a un script PHP qui ne fait strictement rien.
et la surprise:
64ms !!!
Et je parie qu'un ping met une quarantaine de secondes à être retourné.
alors evidement il y a le temps de l'appel et du transfert (car je ne suis
pas en local) des données (meme si mon script ne fait rien) mais 64ms ca
parait beaucoup non ?
Non. Sauf si c'est en local, là je m'inquiéterais.
evidement on va me répondre que ca dépend de mon serveur, mais c'est quand
meme in bi-opteron.
Je croyais que seul les gogo de la bulle Internet se faisaient avoir
par le marketing d'Intel, qui affirmait qu'acheter un Pentium III (ou IV
?) accélérait l'Internet.
PS : pour timer j'utilise le tres excellent firebug !!!
C'est vrai que c'est un outil intéressant. Mais très franchement, les
temps qu'il donne sont à relativiser les uns par rapport aux autres, car
il introduit évidement des erreurs de mesure.
j'ai fais un petit essai comme ca. j'ai fait un appel ajax a un script PHP qui ne fait strictement rien. et la surprise: 64ms !!!
Et je parie qu'un ping met une quarantaine de secondes à être retourné.
alors evidement il y a le temps de l'appel et du transfert (car je ne suis pas en local) des données (meme si mon script ne fait rien) mais 64ms ca parait beaucoup non ?
Non. Sauf si c'est en local, là je m'inquiéterais.
evidement on va me répondre que ca dépend de mon serveur, mais c'est quand meme in bi-opteron.
Je croyais que seul les gogo de la bulle Internet se faisaient avoir par le marketing d'Intel, qui affirmait qu'acheter un Pentium III (ou IV ?) accélérait l'Internet.
PS : pour timer j'utilise le tres excellent firebug !!!
C'est vrai que c'est un outil intéressant. Mais très franchement, les temps qu'il donne sont à relativiser les uns par rapport aux autres, car il introduit évidement des erreurs de mesure.
