Reprise du message précédent :

Page HFR : 100Ko
Page sncf.fr : 130ko
Page accueil Elysée.fr : 135ko
Page Google.com : 10Ko
Page yahoo.fr : 132 Ko
http://fr.wikipedia.org/wiki/W3C : 103 ko
http://www.w3.org/ : 73Ko
 
Je voudrais bien savoir où tu as trouvé tes 10ko de moyenne
 

Pour les pages web heureusement que la compression est utilisée (mod Gzip) ca permet de passer l'ensemble d'une page (texte, html, css, js) à 50% de la taille originelle. Et c'est un plus non négligeable.
 
Edit : burned x10

Sachant que pour tout ce qui est contenu statique ou non généré à la volée, il est possible de compresser à la génération et de servir directement le contenu compressé, pour un coût processeur nul.

 
+1
Le chiffre de 10k en moyenne, il sent bon les années 90

Cette valeur n'est pas calculée sur des pages d'accueil, mais sur un ensemble de pages crawlées sur plusieurs grand sites commerciaux, et ne tient compte que de l'HTML sans les images/JS/CSS.
 
Je pense que tu peux avoir un chiffre plus significatif si tu utilise IE et que tu jette un coup d'oeil dans son répertoire cache.
 
De mon expérience personnelle, les pages de plus de 50Ko font râler les internautes. Celà évolue tant que les internautes passent vers des connexions ADSL2.

 
C'est donc du flan absolu sans aucun intérêt. Merci de le confirmer.

Donc on récapitule :  
Avec les images et tout le contenu :
Page HFR : 100Ko
Page sncf.fr : 130ko
Page accueil Elysée.fr : 135ko
Page Google.com : 10Ko
Page yahoo.fr : 132 Ko
http://fr.wikipedia.org/wiki/W3C : 103 ko
http://www.w3.org/ : 73Ko  
 
 
purement texte :
page HFR : 56Ko
Page sncf.fr : 25Ko
Page accueil Elysée.fr : 34ko
Page Google.com : 1,6Ko
Page yahoo.fr : 40 Ko
http://fr.wikipedia.org/wiki/W3C : 80 ko
http://www.w3.org/ : 41Ko  
 
NAN je ne vois toujours pas où tu trouves tes 10ko

Non, c'est pas du flan, c'est à rapporter dans ce contexte: 50% des internautes abandonnent au bout de 15 secondes, et il faut télécharger en moyenne 10Ko pour voir commencer à s'afficher la page. Un algo de compression utile aux internautes devra compresser/décompresser 10Ko en moins de 15 secondes. Ce n'est, de plus, qu'un exemple relatif à l'internet.
 
Maintenant si vous avez des chiffres plus précis, je suis preneur, parceque le <<50% en 15 secondes>> date des années 2000, et 10Ko concerne des sites commerciaux qui sont en général plus légers que des sites d'information ou autres forums.

http://www.cdiscount.com/informati [...] x=discount : 645Ko
http://fnac.com/ : 185 Ko
http://www.ldlc.com/ : 222Ko
Page d'article IKEA : 310ko
http://amazon.fr/ : 153Ko
 
Essaye encore

la compression via le système de fichier est généralement contre-productive: les seeks deviennent rapidement extrêmement couteux, si le fichier est destiné a être projeté en mémoire la souplesse apportée par la projection est tuée... bref il vaux mieux faire du cas par cas.

     Tu es très patient! Dans les années 80, les concepteurs de programmes estimaient qu'au bout de trois secondes d'inactivité, les utilisateurs perdaient leur sang froid!
     En fait pour charger 10k avec un modem à 56Kb/s, il faut environ 2 à 3 secondes (56 * 1024 / 8 = 7168. 7,16 Ko/s en théorie). En théorie, avec l'ADSL 512Kb/s, on peut charger 196Ko pendant ces mêmes 3 secondes.  
     Celà me semble confimer que les pages actuelles font plus de 10K car elles mettent bien 1 à deux secondes pour s'afficher.

pourtant c'était à la mode en 94-95-96 avec l'intégration de doubleSpace et DriveSpace dans DOS 6.22 et Windows 95.
 
Utile quand on installait windows 95 (75Mo minimum) sur les disques de 250Mo de l'époque.

je pense que y'a toujours moyen de limiter la casse, mais bon le nombre de machines sous Xp qui se mettaient à ramer parceque l'utilisateur avait dit "oui" au "truc qui nettoye le bureau périodiquement"  
et boum 80% du HD compressé, le moindre scan à la volée AV mettait 3 plombes..

Mais c'est encore un peu le cas, la compression existe bien sur les partitions NTFS

oui tout à fait c'est ça que je fais allusion.
après il faut voir comment elle est implémentée, si c'est compressé par blocs de 4Ko pour pas trop tuer les seeks.

Compresser à un bit ou moins c'est possible. Il faut juste être trèèèès patient.
 
En effet pour retrouver le fichier original il suffit d'énumérer tous les fichiers possibles (c'est un ensemble dénombrable heureusement..) et d'attendre que le fichier passe devant nos yeux (on peut prouver qu'il passera forcément, pas forcément de notre vivant ou celui de l'age de l'univers. mais sur des petits fichiers c'est jouable.).

 
Il existe un paquet d'algos extrèmement rapides, faudrait voir à arrêter un peu avec le problème de la perf de la compression.
Les principaux problèmes de perf dans les serveurs web aujourd'hui sont liés au cryptage, bien plus gourmand en ressources.  
Par exemple, un algo comme LZO, conçu pour une décompression rapide, est seulement 4x plus lent qu'une simple copie en mémoire lorsqu'il décompresse. Exemple parmi d'autres.
Sur ma bécane, un algo comme celui de 7zip compresse avec un débit de 1Mo/s en mode "ultra" et décompresse à hauteur de 6Mo/s. Pour les fichiers d'une taille d'environ 10ko, on a des temps de compression/décompression de l'ordre de la milliseconde, qui sont minimum 10 fois inférieurs à la latence du réseau dans le meilleur des cas.
 
Faut savoir comparer ce qui est comparable.
 
Note:
fnac.fr : 73,32 Ko (75 082 octets)
ldlc.com : 50,61 Ko (51 825 octets)
3suisses.fr : 7,19 Ko (7 364 octets) (sauf que... le contenu est inexploitable sans les images)
ticketnet.fr : 76,37 Ko (78 205 octets)
ooshop.fr : 1,14 Ko (1 165 octets) (une rare exception)
 

Pour l'amelioration du signal/bruit:
http://entland.homelinux.com/blog/ [...] -possible/
 
Donc, compresser n'a tjs pas grand sens pour un traitement local dans une optique de performance. Notons que cet article ne mesure pas le temps requis pour commencer à travailler (cf mmap).
 

Je ne vois pas le rapport avec la choucroute, parce que ce n'est certainement pas le CPU avec ses petits bras musclés qui va directement commuter le signal avec une interruption par cycle. Evidement les chips deportent une bonne partie du traitement.

Sous IIS c'est par défaut en tout cas

Donc c'est pas la majorité des serveurs HTTP

Oui, mais comment tu sais que c'est le bon fichier ?
 
 
Bon, sinon pour la compression sur internet zlib (et l'algo deflate) est très rapide (si on choisis de privilégier la vitesse sur le taux de compression, on dépasse sans PB les 20 MB/s sur un proc à 1ghz). A moins d'avoir une connection de l'ordre du 100 Mb/s avec un petit processeur on y gagne à compresser.
 
Et même les algorithmes au top, très lents, du genre PPMd, font sans problème 2 MB/s (soit 16 Mb/s, le double du débit maximal du net chez l'utilisateur moyen, même dégroupé).

Un autre exemple de compression qui est plus rapide que le raw : le JPG, mais aussi le MPEG.
 
Si on perd du temps à compresser/décompresser, on en gagne pourtant (même sur une machine ultra-rapide) à ne pas stocker les infos en RAW.
 
Exemple :
Un DVD, c'est une résolution de 720x576. A raison de 20 images par secondes et 24 bits de profondeur pour les couleurs, ça donne, pour une seconde de vidéo (je n'inclu pas le son dans les calculs, il est négligerable puisqu'il s'agit de 2,1 Mo/s d'informations si on est en 5.1 : c'est donc négligeable).
 
Vidéo en RAW :
720x576x3x20 = 24883200 octets/s, soit 24,9 Mo/s.
 
Vidéo en DVD (MPEG-2) :
une seconde de lecture correspond en moyenne à 4 Go / 7200 s = 596523 octets/s = 0,6 Mo/s.
 
Vidéo en DivX :
800 Mo / 7200 s = 116508 octets/s = 0,12 Mo/s.
 
OK.
Maintenant, un disque dur, ça a une vitesse moyenne de lecture de 40 à 60 Mo/s, rarement plus. Ce qui indique que par exemple, sans compression, ils serait absolument impossible de lire deux vidéo en même temps, alors qu'on peut parfaitement lire une dizaine de DivX en même temps.
Ensuite, niveau débit, 25 Mo/s, aucun lecteur de DVD ou de CD n'est capable de produire ça. Pour un disque externe, cela implique l'utilisation obligatoire de l'USB 2 ou du FireWire, avec toujours un risque important de lag. Alors que pourtant, les 0,11 Mo/s du DivX permettent la lecture d'un film à partir d'une disquette, sans aucun problème de vitesse.
 
Bref, la compression est aujourd'hui très utilisée, et reste obligatoire. Ca même les média rapides ne suivent pas par rapport aux volumes d'information gigantesques.
 
Ensuite, on parle de fibre optique. Sans aller jusqu'à la fibre optique, parlons simplement d'un réseau Gigabit en RJ45.
C'est ce que j'ai installé chez moi. Transférer un fichier volumineux d'un PC à l'autre, ça va bouffer autour de 150 Mbps, rarement plus. Pourquoi ? Parce que si les CPU derrière suivent sans problème le débit soutenu de 1 Gbps, il n'en reste pas moins qu'à l'écriture sur le disque, c'est la débandade : arrivé autour de 15 Mo/s on a déjà un bon débit.
A nouveau, on se rend compte qu'un média pourtant réputé comme rapide, comme le disque dur, s'avère totalement insuffisant pour un transfert de données volumineuses si on ne compresse pas.
 
Ah, oui, et je parlais de 15-20 Mo/s en écriture sur un disque. Certains disques sont plus rapides que d'autres, je suis bien d'accord. Mais on est tout de même en deça des 25 Mo/s nécessaires au stockage d'une vidéo au format RAW dans la résoution d'un DVD. Ainsi, la compression à la volée s'avère non seulement utile, mais indisensable : elle permet de stocker sans problème sur un disque un flux vidéo en temps réel, alors que la non compression est impossible... à cause du temps que ça prend !
 
Bref, je voulais juste remettre les choses au point au niveau de la compression : Elle n'est pas forcément plus lente que le stockage ou transfert d'informations en RAW, et est très courrament utilisée...
 
PS: au départ je parlais aussi du JPG. Créez une image en 10 000 x 10 000 sous photoshop. Enregistrez en BMP (300 Mo). Ca va mettre des plombes à enregistrer et recharger.
La même en JPG (Dans les 10 Mo, selon la complexité de l'image). Ca ne prendra plus que quelques secondes à charger et enregistrer. Pour la même raison : le HD arrive à saturation, et bouffer un peu de CPU pour effectuer la compression/décompression permet de réduire l'embouteillage provoqué par le HD.

j'y peut rien si les gens utilisent des serveurs de merde

Ben tu le compares avec le fichier original que t'as gardé dans un coin
 
   

Heuuu ok ouais

Pardon, mais un disque dur n'a jamais été de la mémoire rapide mais de la mémoire de masse. Vous avez p-e entendu parler de concepts novateurs tels que buffers & caches, latence et débit ou encore distribution d'I/O?
 
 

Pipeau. Si j'ai un disque crachant 50M/s, si je mmap le fichier de 300M je mettrais 6s pour toucher *toutes* les données. Point barre. Qque soit la partie du fichier à laquelle j'accede la latence est sensiblement la même, tandis que si le fichier est compressé il me faudra chercher le bon chunk, le lire en entier et le décompresser etc...
Encore une fois, la latence est tout aussi importante que le débit.

Ah ouais, et :
1/ Ton stream, tu me le sors d'où ? Si c'est pour limiter l'utilisation d'un PC à de la webcam haute résolution, désolé, mais je ne suis pas intéressé
2/ Un HD c'est peut-être avant tout de la mémoire de masse, mais il n'en reste pas moins que c'est aussi la mémoire de masse la plus rapide. Donc oui, c'est une mémoire rapide. Les données n'ont rien à foutre en RAM (réservée aux traîtements de l'information) ni dans les buffers (zones de transit).
 

Je suis content pour toi. Je pense que 99,999999999999999% des gens dans le monde ont des HD à moins de 20 Ktrm, ni ne font des array de RAID 0 avec 32 disques. La plupart des gens ont des disques ayant un mal de chien à livre plus vite que 40 Mo/s et enregistrant moins de deux fois moins vite. Anyway : entre 40 Mo/s et 50 Mo/s faut m'expliquer où est la différence flagrande. Pour peut que tu aies un traîtement en parallèle, dans tous les cas, tu arriveras à saturation des capacités de vélocité du disque avant si tu utilises un format RAW.
Ton truc c'est vraiment contredire pour contredire... Y'a même pas un argument.
 
PS: et pour photoshop, fait le test (tu peux même utiliser Paint.exe si tu veux, il saura aussi bien faire du BMP que du JPG)

 
Vous mélangez un peu tout. Que phototruc soit une pelle à merde n'a rien a voir avec le problème. Vous n'avez tjs pas compris la nuance entre débit et latence, les mesures de performance ne peuvent se résumer à l'un ou l'autre des parametres.

ben justement, je résume à rien du tout.
 
j'ai une information.
je veux pouvoir la créer, la modifier et l'afficher rapidement.
 
quel est le meilleur test que de prendre l'application finale pour voir comment elle se comporte ? c'est quand même ieux que de se dire "à ouais, avec la DDR 3200 j'ai 4 Go/s de bande passante en mémoire, donc je peux effectivement lire des flux à cette vitesse" (bah nan, c'est pas aussi simple )

Sinon, pour reprendre la différence entre débit et latence, pour reprendre ce que tu dis, en effet, en utilisant la compression, on augmente généralement la latence (mise à part de la bête compression RLE par exemple, qui n'influera pas ou presque sur la latence), pour obtenir par contre un débit généralement suppérieur : Si j'ai une archive qui tiens en 100 Mo et qu'elle représente 1 Go de données, autant j'aurai une latence certaine avant d'obtenir le premier octet de données, autant je pourrais, une fois la décompression lancée, un débit 10 fois suppérieur, à compter que le passage de 100 Mo à 1 Go ne sature pas plus le processeur que la lecture des données depuis le support utilisé.
 
Pour tout ce qui est application vidéo, audio, imagierie, ou transporté sur le net, le gain au niveau du débit est infiniment suppérieur à la latence. Il suffit de lire en streaming une vidéo compressée depuis internet pour s'en rendre compte : dès les premières frames reçues, on pourra lire la vidéo sans coupure jusqu'à la fin, alors qu'en RAW, ou le débit de données nécessaire à la restitution vidéo est suppérieure au débit de transfert, on pourra certes, peut-être (même pas sûr) commencer à lire plus tôt, mais avec des pauses tout le long de la lecture.
 
A noter aussi que pour l'histoire du SEEK, c'est plus ou moins vrai : A partir du moment où on utilise une compression utilisant un débit fixe (paramère par défaut du DivX, du MPEG ou du MP3 par exemple) on peut instantanément trouver à partir de quelle keyframe décompresser pour retrouver la partie à lire. Ainsi la latence reste très faible (par contre, pour les compression avec débit variable (ZIP, ou les sus-cités avec paramétrage spécifique), on doit en effet tout décompresser depuis le début afin de restituer un morceau. Dans ce cas, je suis d'accord la latence peut devenir inacceptable.

Précisez si vous parlez en théorie ou bien d'un DD de mr tout le monde ou d'une solution de stockage peu commune ou de RAM alors ...    
 

Y a pas à être d'accord ou pas, il est prouvé que c'est faux et impossible Et ça repose pas sur les 2-3 lois de la thermo qui un jour peut-être se révéleront incomplètes mais sur de la logique accessible à un athénien du 4ème siècle av. JC ...

étant donné que la discussion partait de la compression FS, elle est sans pertes. Et là les seeks deviennent plus problématiques.
 
Le streaming style MPx est à mont goût un mauvais exemple, car c'est un format de stockage final, et non un format de travail.
 
Je suis pas convaincu qu'un moteur SQL apprécierai que ses fichiers de données soient compressés à son insu.
 

 

L'exemple du SGBD est mauvais
 
Deux exemples :
- Les types "NUMERIC" ou "VARCHAR" sont deux types à taille variable. C'est à dire que tu indiques que tu vas stocker "jusqu'à X caractères", alors que la place effectivement utilisée peut être inférieure. Si tu crées un champ NUMBER(38) (nombre ayant jusqu'à 38 chiffres en représentation décimale) il peut parfaitement, sur le disque, ne prendre que 2 ou 3 octets, alors que le format total requière jusqu'à 126 bits (soit 16 octets). Idem pour un VARCHAR2(4000) d'Oracle par exemple, qui contient entre 1 et 4000 octets selon les informations stockées. L'utilisation de 1 octets quand nécessaire au lieu des 4000, c'est bel et bien une forme de compression, même si elle est plus que basique. Maintenant, niveau performances, c'est en effet catastrophique sans utilisation d'index, car le SGBD est alors incapable via SEEK de savoir où se trouve la X° ligne. Cependant, le gain d'espace permet de charger bien plus de lignes en mémoire, alors utilisée come cache, ce qui permet toutefois des performances globales meilleurs que le type CHAR ou un BIGINT utilisés à tord pour stocker des valeurs petites.
http://www.ss64.com/orasyntax/datatypes.html
- Le second exemple, plus simple, c'est le CODEPAGE. Par exemple, UTF-8, permet de représenter actuellement 95 221 caractères différents. Cela correspondrait, sans compression, à l'utilisation de 3 octets pour chaque caractères. Cependant, le norme utilise un système mixte entre le RLE et la compression Hoffman pour les stocker sur une taille variable allant de 1 à 4 octets par caractères. Les caractères stockés sur 1 octets étant généralement les plus répendu, par souci de rétro-compatibilité avec d'autres systèmes d'encodage, mais aussi de place. Ainsi, un fichier totalement écrit en US-ASCII est valide UTF-8.
Grace à ce système, on économise énormément de place sur le disque et en mémoire.
http://fr.wikipedia.org/wiki/UTF-8
http://fr.wikipedia.org/wiki/Unicode
 
Bref : les SGBD utilisent sciemment un système de compression, et on utilise "dans leur dos" un autre système de compression

ce que tu décris n'a rien à voir avec de la compression
 
et t'utilises pas de compression "dans leur dos" tant que tu autorises pas de compression au niveau du filesystem.
 
j'aimerai bien connaitre les perfs de SQL Server ou MySQL si tu va cocher la compression des bases au niveau NTFS. (c'est ça de la compression "dans leur dos" )

Bah faire de la comparaison de chaîne avec un LIKE sur un VARCHAR utilisant UTF-8 ça represente quand même un exploi au niveau de l'algo quand même.
Ces deux systèmes sont clairement des types de compression. Pas vraiment plus évolués que le RLE mais ils n'en reste pas moins de la compression

Et dire que dans les années 2000, les gens pensaient que la compression absolue était un mythe. Bien sûr de nos jours on atteint pas la compression absolue, mais on s'y approche de près.
 
Si l'on considère un disque dur standard, de 512To, celà représente certes 512To, mais c'est aussi et seulement 512To cases mémoire. Alors que si on considère 2^512To possibilités, celà devient incommensurable. Pourtant un simple calcul de statistique fait sur quelques millers de disques dur pris au hasard sur le supernet, montre que le nombre de possibilités réellement exploitées est extrèmement inférieur à 2^512To, et beaucoup plus de l'ordre de grandeur de 512To. Et c'est facile à se l'expliquer en regardant nos concitoyens: ils regardent tous les mêmes émissions de télé-vérité, écoutent tous la même musique hyperrock, regardent tous les mêmes films à SFX sortis dans le dernier mois.
 
Ce qui fait, au final, que très peu de disques sont nécessaires pour détenir les informations nécessaires pour 99% des humains.
Normalement, d'ici à 2045, le supernet devrait terminer de calculer le nombre optimal de bits sur lesquels on pourra enregistrer les informations necessaires à 99,97% de la population du système solaire. Le reste de ces informations sera mis à part bien sûr, et comme moins d'un milliard d'être humains seront concernés il leur sera toujours possible de bio-transformer un de leurs enfants en disque dur, pour garder ces informations tout en conservant l'entropie de l'univers. Enfin, ce sont les dernière prévisions du supernet, et pour l'instant il ne s'est jamais trompé dans ses calculs.
 
God save the supernet.
 
[retransmission de pensée d'un internaute, date de transmission 2042, date de réception 2006, mode compatibilité intenet]

 
pour moi ça a rien a voir avec de la compression. c'est de la structuration/gestion de collection, bref de l'algo/architecture logicielle, rien à voir. enfin c'est comme ça que je le sens.
 
 
 

 
Je suis entièrement d'accord.
 
D'ailleurs un chercheur qui a reçu y'a quelques temps la médaille Fields l'a bien dit:  
 
http://www4.tz-technologie.com/images/chiffres.mpg

Erf
 
Je voulais faire un petit bench et...
SQL Server plante si on essaie de créer une base de données dans un fichier compressé (ou alors il faut le flaguer comme "lecture seule" )

comme par hasard.
faudrait regarder le Platform SDK si les mappings mémoires (en lecture ET ecriture) échouent sur les fichiers compressés via le FS.

nargy > d'un autre côté, ce que tu dis (au début) est parfaitement vrai
mais à la base, c'est vieux comme le monde : une bête application client serveur repose sur ce principe : tout le monde pompe la même information qui est stockée à un seul endroit. un site web en est l'exemple le plus commun

ben vu qu'on peut lire, non, je pense que c'est juste une limitation qu'impose le moteur, car les devs ont estimé qu'il s'agissait d'une hérésie
 
ceci dit, j'aurais bien aimé faire le test pour voir
(d'un autre côté, vu mes disques ça n'aurait pas été concluant, puisque le gain lié au volume lu aurait été totalement anéanti par les CPU et la vitesse des HD : bi Piii 933 avec des disques U3W 10ktrm...)