
Dans le domaine de l'informatique, la bande passante indique - par abus de langage - un débit d'informations. Le terme exact est le débit binaire.
L'origine du terme est une analogie avec la bande passante en électronique. La bande passante d'un cable mesurant le nombre maximal d'oscillations par seconde qu'un signal peut y prendre sans être trop atténué, si le signal est celui d'une liaison informatique comme une liaison série, le nombre d'oscillations va refléter le nombre d'informations que l'on peut transférer durant une seconde.
La bande passante peut concerner le débit d'un périphérique (tel qu'une mémoire, un disque dur, etc.) ou d'un medium de communication (réseau, bus, etc.) ou de manière générale n'importe quel débit d'information comme entre le processeur et la mémoire cache.
On mesure généralement cette bande passante en octets (byte en anglais) par seconde (o/s, ou en Anglais « Byte per second », B/s) ou en bits par secondes (bit/s ou bps), plus généralement utilisée par les fournisseurs d'accès internet pour donner le débit maximum d'un abonnement.


<?php
// Si les entêtes ne sont pas envoyés, et que la compression n'a pas commencée
if (!headers_sent() && ob_get_length() == 0)
{
// On vérifie la version de PHP
if (ini_get('output_handler') == 'ob_gzhandler' || version_compare(PHP_VERSION, '4.2.0') == -1)
$compression = false;
// On compresse !
else
ob_start('ob_gzhandler');
}
// Si on a pas réussi à compresser, il faut quand même envoyer les headers
if ($compression == false)
ob_start();
?>
html...


et ces images utilisent une grande partie de la bande passante.
| maxrider | Date inconnue |
| Premièrement: Tu ne fais aucune comparaison avec une page affichée classiquement au format PHP et une page compressée avec GZIP donc c'est bancale à mon gout ! Deuxièmement: la gestion des buffers via php est contraignante ! Perso j'essaye au maximum de m'en passer. Et puis compresser quelques Ko de données ça rime presque au ridicule. Si une page est mal écrite, elle aura du mal à se charger c'est sur. Pour les images tu ne donnes pas de format, il est bien d'utiliser du gif, du jpeg et du png. Le bmp est totalement à banir !!! |
|
| Worm | Date inconnue |
| Je ne vois pas de différence dans l'affichage d'une page compressée avec GZIP et une autre au format HTML. Lorsque j'ai utilisé la compression sur Tuto-Geek, je n'ai pas vu de différence, si ce n'est la diminution du poids de la page. Je vois pas en quoi la gestion des buffers est contraignante il suffit de bien faire attention de pas placer la bufferisation de sortie après une sortie html, rien de plus. Des erreurs peuvent apparaitre si elle est utilisée après session_start().Gagner ne serait-ce que 10Ko est au contraire bien utile ! Petit calcul : - Un site de 100Ko génère 100 visites/jour : 300Mo de bande passante/mois - La même chose, mais avec un site de 90Ko : 270Mo de bp/mois Il ne faut pas oublier que la compression gzip peut réduire le poids de la page de 70%. Merci, je n'avais pas pensé à préciser quel format d'image il était préférable d'utiliser ![]() |
|
| adorus | Date inconnue |
| L'avantage de la compression GZIP est d'épargner de la bande passante, ok.. Par contre, cela augmente l'utilisation du processeur.. ce qui en cas de fort trafic, diminue la rapidité du site. Dans mon cas, je peux donc vous dire que - à certains moments en tous cas - la compression ralentit la rapidité de l'affichage... Elle est d'ailleurs très difficile sur un site à gros volume (où alors il faut une super bonne machine, ce qui est plus cher que la bande passante..) |
|
| Worm | Date inconnue |
| Oui, c'est sûr qu'il faut bien analyser la situation avant d'utiliser la compression. Je vais rajouter cette petite précision, merci. | |
| Worm | Il y a 2 ans |
| Nouvelle adresse pour ShrinkSafe : http://shrinksafe.dojotoolkit.org/ |
|
Vous devez vous être connecté pour poster des commentaires