Discussion :

[Xunil]

Bonsoir,

J'ai encore une petite question, au sujet des tableaux, y'a t-il une taille limite à partir duquel leur lecture peut se faire sentir dans un script ?

C'est pour les sujets lus et non lus d'un forum par un membre, seuls des numériques y seront stockés.

A long terme, cet array sera de taille de plus en plus conséquente, de plus je fait une requête avec un implode de ce tableau.

Avec par exemple un tableau de 4000/5000 valeurs numériques, est-ce que ça fait beaucoup ?

Il peut y avoir des conséquences visibles sur la vitesse d'exécution de ma page ?

[Skreo]

Je pense pas que ce soit vraiment la taille du tableau qui ai un impact sur la lenteur d'un script, mais plutôt le traitement qu'on effectue dessus.
Si tu fais 400 array_search dessus, c'est sûr que ça va ralentir

[Xunil]

A part un implode et un in_array, il n'y aura pas d'autres opérations d'effectuées dessus.

le in_array, dans l'affichage de la liste des sujets, et l'implode seulement dans la recherche des derniers messages postés et non lus.

[Mister Nono]

Il faut aussi tenir compte de l'empreinte mémoire (nombre enregistrement * taille de chaque enregistrement par exemple) de la structure de données et de la quantité mémoire disponible de ton serveur.

[Sékiltoyai]

Oui, et faire gaffe de ne jamais dépasser la limite de RAM autorisée pour chaque script par PHP (je crois que c'est 8Mo en général)...

[viviboss]

....Et puis pour la lenteur, tu va surout te situer effectivement sur les performances du serveur....
Pour l'envoie de tes 5000 résultats (imaginons qu'un gars ne se soit pas connecté à ton forum durant un certains temps, il risque d'y avoir beaucoup d'enregistrements à renvoyer !!!!), cela prendra quand même pas mal de bande passante, en plus des perfs serveur....

Donc tu pourras utiliser la compression dynamique des pages, pour diminuer la bande passante utilisé....(ob_start('obzhandler')).

Pour les perfs serveurs, cela dépend pas mal de ton type d'hébergement (mutualisé, dédié, machine à toi.....)

[Xunil]

Il faut aussi tenir compte de l'empreinte mémoire (nombre enregistrement * taille de chaque enregistrement par exemple) de la structure de données et de la quantité mémoire disponible de ton serveur.

Je ne connais pas grand chose à ce niveau, comment fait-on pour déterminer la taille en octets d'un array() ou d'une chaine ?
J'ai pas trouvé de fonction native de php pour faire ça, y'en a une ?

Oui, et faire gaffe de ne jamais dépasser la limite de RAM autorisée pour chaque script par PHP (je crois que c'est 8Mo en général)...

Ah 8mo, ça laisse quand même de la marge, je pense pas que j'arriverais à 8mo de données dans un array, enfin du moins je pense pas

....Et puis pour la lenteur, tu va surout te situer effectivement sur les performances du serveur....
Pour l'envoie de tes 5000 résultats (imaginons qu'un gars ne se soit pas connecté à ton forum durant un certains temps, il risque d'y avoir beaucoup d'enregistrements à renvoyer !!!!), cela prendra quand même pas mal de bande passante, en plus des perfs serveur....

Donc tu pourras utiliser la compression dynamique des pages, pour diminuer la bande passante utilisé....(ob_start('obzhandler')).

Pour les perfs serveurs, cela dépend pas mal de ton type d'hébergement (mutualisé, dédié, machine à toi.....)

Bah pour le serveur, ce sera un mutualisé, mais pourquoi utiliser ob_start, j'ai pas bien compris.
La requête qui ira chercher les id dans la table se fera avec mysql_unbuffered_query, et le tout sera stocké dans un array.

Merci de vos réponses.

[viviboss]

ob_start te permettrait de compresser la page renvoyé en GZIP

[Xunil]

Tu peux approfondir s'il te plaît, ou du moins m'expliquer plus en détail, je comprend pas trop a quoi cela pourrait bien me servir.

[viviboss]

Imagine que tu renvoie une page avec 5000 enregistrements. Ca demande beaucoup de bande passante pour envoyer tous ca, alors tu peu compresser la page envoyé à ton visiteur (pour peu que son navigateur soit compatible GZIP.... Mais à priori y a pas trop de souci.....) pour qu'elle apparaisse plus rapidement : la compression va prendre un peu de ressources serveur, et la décompression de la page un peu de ressource client, mzis la bande passante reste sauve....

Il faut juste que tu mettes en tête de tes scripts, (du moins celui qui renvoie la page que tu veux compresser) ob_start('obzhandler'), et PHP s'ocupe du reste (même pas besoins de fermer l'ob_start.....), c'est plutot cool, non ?

Exemple : mon site est 100% compressé

[Xunil]

Ah ok, je comprend mieux, mais moi j'en ai pas besoin, puisque je n'afficherais jamais le contenu de cet array, bon j'ai peut-être pas tout bien saisi

Exemple : mon site est 100% compressé

Ah oui

J'ai jamais utilisé ob_start autrement que pour faire un redirection après envoi de html au navigateur, donc je connais pas trop.

Je savais pas que c'est le navigateur qui décompressait les pages envoyées.
Donc en fait l'avantage de compresser, c'est de limiter le coût de la bande passante, c'est ça ?

Merci de ta réponse

[viviboss]

C'est exactement ça.

Je pensais que tes 5000 entrés tu voulais les envoyés à ton client Je me suis quelque peux fourvoyé....

Bref, tu sais un truc nouveau, c'est déjà bien : mon honneur est sauf !!!!

PS : pour voir si tu peux compresser, il faut que tu vois le PHP.ini de ton serveur, à la section obzhandler..... Le jour ou tu voudra l'utiliser !!! (c'est comme tout : il ne faut pas non plus abuser des bonnes choses )

[Xunil]

Oui, ton honneur est sauf

Merci beaucoup de ton explication, et de m'avoir fait connaitre ob_gzhandler
Je vais essayer de m'en servir sur mes pages qui sont assez conséquentes.

Bon pour déterminer la taille d'un array, j'ai enregistré dans un fichier, avec :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$tab = range(0, 50000);
file_put_contents('./obs.txt', implode('', $tab));

J'obtiens 239ko, ça semble à peu près correct, vu quand même 50000 valeurs, ça sera sans doute jamais le cas.