A propos du cache texture de SecondLife - Partie 2
Publié le 8 Juin 2008
Pour ceux qui n'ont pas eu la patience de lire la partie 1 jusqu'au bout :
- Linden Lab a fait un sac de noeud pour rendre difficile le "vol de texture" via le cache. (securité par l'obscurité)
- Ce sac de noeud impacte très peu sur les performances, totalement negligeable.
- Un maximum de temps est perdue dans la decompression jpeg2000 et c'est deja optimisé a mort.
A quoi sert le cache ?
Le cache permet de stocker des textures sur le disque dur, plutot que de les retelecharger a chaque fois.
Un gain de temps, de bande passante, et de ressource CPU pour les serveurs SecondLife.
Pourquoi faut il le vider regulierement ?
Il ne faut pas le faire regulierement !
Pourquoi faut il le vider, parfois ?
Parce qu'il peut etre corrompu pour diverses raisons.
Qui sont ?
- un plantage pur et simple de l'application pile au moment ou elle etait en train d'editer le cache. Ce qui rend le fichier "inconcistant". A savoir : ce qu'il y a ecris dans le fichier A ne correpond pas a ce qu'on est sencé trouver dans le fichier B. Ou alors l'application n'a pas eu le temps d'ecrire la totalité du fichier entete par exemple, et au redemarrage l'application est toute embrouillée parce ce qu'il lui manque des informations pour utiliser le cache. 2 raisons parmis d'autres.
- Beaucoup plus frequent : l'application a "freezé" au moment ou elle etait en train de reorganiser le cache. Elle freeze justement parce qu'elle est en train de le reorganiser et qu'elle a besoin de stopper certaines operation pendant cette reorganisation. (typiquement : Empecher l'acces au cache pendant cette reorganisation).
Pourquoi reorganiser le cache :
C'est lié a sa taille. (il n'y a pas que la taille qui compte, mais ca aide ;) ).
Nous n'avons pas un espace disque illimité. Et afin que SecondLife ne remplisse pas l'integralité du disque dur
nous pouvons indiquer une taille maximale que nous voulons consacrer au cache.
Plus le cache est gros, plus l'operation "est ce que cette texture dont j'ai besoin est stockée sur mon disque ? ou dois-je la telecharger ?" prend du temps.
A chaque fois que SecondLife telecharge une texture, il la transforme en sac de noeud (voir partie 1) et la met en cache.
A ce moment la il en profite pour verifier la taille du cache. Si la taille excede la taille maximale qui lui est autorisé, il va faire un nettoyage de printemps en virant 10% des textures stockée.
Ce qui mene a un "leger freeze" de l'application. Car pendant le nettoyage, toutes les operations necessitant un acces au cache sont bloquées. Et comme secondlife est multithread ca n'arrange pas les choses (beaucoup plus difficile a coder, plus de bugs et de "bloquages" possible.
Bien sur, plus le cache est gros, plus le nettoyage est lent.
Je ne detaillerai pas le precessus du nettoyage car je ne suis pas absoluement certain de la methode employée. (visiblement les textures les plus anciennes sont supprimée du cache, d'ou le fait que la "date de stockage" fasse partie de l'index des textures (voir le post sur la structure de texture.entries)
Malheureusement, ce "freeze" qui peut etre plus ou moins long peut etre assimilé a un plantage de l'appli et elle est fermée violament par l'utilisateur. La reorganisation est laissée en plan, le cache est inutilisable ou, pire, mal utilisé (ce qui fait remplenter l'application et qu'on soit obligé de vider le cache).
D'ou l'interet de ne pas mettre un cache trop gros quand l'ordinateur est un peu faiblard.
A cela on pourrait rajouter que le FileSystem de Windows est une grosse merde qui rend les operations encore plus lentes. Il y a enormement de reécritures et les fichiers finissent horriblement fragmentés. (et c'est vraiment specifique a windows).
De plus windows n'apprecie pas trop quand il y a trop de fichier dans un meme repertoire. C'est pour cela que les fichiers de textures sont dispersée dans des sous-repertoire.
Il y aurai des solutions un peu plus optimales pour cacher ces textures rapidement, mais l'optimisation ne serait efficace qu'avec un OS utilisant un filesystem digne de ce nom (linux, macOS X, ...) alors que cela empirerai les choses sous Windows.
Il y a vraiment beaucoup de discussions sur SLDev a propos du cache, car c'est vraiment un point qui impacte fortement les performances. Etant donné que c'est la decompression du format jpeg2000 (les textures sont stockée dans ce format) qui prend le plus de temps, l'idée évoquée est d'utiliser un autre format, plus rapide. (les plus rapides etant les format sans compression tels que le TGA).
Vous pouvez trouver un bref resumé des discussions et propositions ici : http://wiki.secondlife.com/wiki/Talk:Texture_Cache
(au passage vous remarquerez que j'y ai pas mal participé, en particulier en évoquant et soutenant l'utilisation du format TGA).
En parallele avec la discussion sur le format d'image stockée, il y a aussi une discussion sur la facon dont les fichiers sont indexés/stockés. Une source de problemes venant du "nettoyage" de la base de stockage des textures, il est evoqué l'idée d'utiliser une autre facon d'organiser le stockage des textures. Anfin d'eliminer, sinon diminuer, ce probleme de nettoyage/maintenance.
Fin de la partie 2, j'ai essayé de faire court, si si.
- Linden Lab a fait un sac de noeud pour rendre difficile le "vol de texture" via le cache. (securité par l'obscurité)
- Ce sac de noeud impacte très peu sur les performances, totalement negligeable.
- Un maximum de temps est perdue dans la decompression jpeg2000 et c'est deja optimisé a mort.
A quoi sert le cache ?
Le cache permet de stocker des textures sur le disque dur, plutot que de les retelecharger a chaque fois.
Un gain de temps, de bande passante, et de ressource CPU pour les serveurs SecondLife.
Pourquoi faut il le vider regulierement ?
Il ne faut pas le faire regulierement !
Pourquoi faut il le vider, parfois ?
Parce qu'il peut etre corrompu pour diverses raisons.
Qui sont ?
- un plantage pur et simple de l'application pile au moment ou elle etait en train d'editer le cache. Ce qui rend le fichier "inconcistant". A savoir : ce qu'il y a ecris dans le fichier A ne correpond pas a ce qu'on est sencé trouver dans le fichier B. Ou alors l'application n'a pas eu le temps d'ecrire la totalité du fichier entete par exemple, et au redemarrage l'application est toute embrouillée parce ce qu'il lui manque des informations pour utiliser le cache. 2 raisons parmis d'autres.
- Beaucoup plus frequent : l'application a "freezé" au moment ou elle etait en train de reorganiser le cache. Elle freeze justement parce qu'elle est en train de le reorganiser et qu'elle a besoin de stopper certaines operation pendant cette reorganisation. (typiquement : Empecher l'acces au cache pendant cette reorganisation).
Pourquoi reorganiser le cache :
C'est lié a sa taille. (il n'y a pas que la taille qui compte, mais ca aide ;) ).
Nous n'avons pas un espace disque illimité. Et afin que SecondLife ne remplisse pas l'integralité du disque dur
nous pouvons indiquer une taille maximale que nous voulons consacrer au cache.
Plus le cache est gros, plus l'operation "est ce que cette texture dont j'ai besoin est stockée sur mon disque ? ou dois-je la telecharger ?" prend du temps.
A chaque fois que SecondLife telecharge une texture, il la transforme en sac de noeud (voir partie 1) et la met en cache.
A ce moment la il en profite pour verifier la taille du cache. Si la taille excede la taille maximale qui lui est autorisé, il va faire un nettoyage de printemps en virant 10% des textures stockée.
Ce qui mene a un "leger freeze" de l'application. Car pendant le nettoyage, toutes les operations necessitant un acces au cache sont bloquées. Et comme secondlife est multithread ca n'arrange pas les choses (beaucoup plus difficile a coder, plus de bugs et de "bloquages" possible.
Bien sur, plus le cache est gros, plus le nettoyage est lent.
Je ne detaillerai pas le precessus du nettoyage car je ne suis pas absoluement certain de la methode employée. (visiblement les textures les plus anciennes sont supprimée du cache, d'ou le fait que la "date de stockage" fasse partie de l'index des textures (voir le post sur la structure de texture.entries)
Malheureusement, ce "freeze" qui peut etre plus ou moins long peut etre assimilé a un plantage de l'appli et elle est fermée violament par l'utilisateur. La reorganisation est laissée en plan, le cache est inutilisable ou, pire, mal utilisé (ce qui fait remplenter l'application et qu'on soit obligé de vider le cache).
D'ou l'interet de ne pas mettre un cache trop gros quand l'ordinateur est un peu faiblard.
A cela on pourrait rajouter que le FileSystem de Windows est une grosse merde qui rend les operations encore plus lentes. Il y a enormement de reécritures et les fichiers finissent horriblement fragmentés. (et c'est vraiment specifique a windows).
De plus windows n'apprecie pas trop quand il y a trop de fichier dans un meme repertoire. C'est pour cela que les fichiers de textures sont dispersée dans des sous-repertoire.
Il y aurai des solutions un peu plus optimales pour cacher ces textures rapidement, mais l'optimisation ne serait efficace qu'avec un OS utilisant un filesystem digne de ce nom (linux, macOS X, ...) alors que cela empirerai les choses sous Windows.
Il y a vraiment beaucoup de discussions sur SLDev a propos du cache, car c'est vraiment un point qui impacte fortement les performances. Etant donné que c'est la decompression du format jpeg2000 (les textures sont stockée dans ce format) qui prend le plus de temps, l'idée évoquée est d'utiliser un autre format, plus rapide. (les plus rapides etant les format sans compression tels que le TGA).
Vous pouvez trouver un bref resumé des discussions et propositions ici : http://wiki.secondlife.com/wiki/Talk:Texture_Cache
(au passage vous remarquerez que j'y ai pas mal participé, en particulier en évoquant et soutenant l'utilisation du format TGA).
En parallele avec la discussion sur le format d'image stockée, il y a aussi une discussion sur la facon dont les fichiers sont indexés/stockés. Une source de problemes venant du "nettoyage" de la base de stockage des textures, il est evoqué l'idée d'utiliser une autre facon d'organiser le stockage des textures. Anfin d'eliminer, sinon diminuer, ce probleme de nettoyage/maintenance.
Fin de la partie 2, j'ai essayé de faire court, si si.