Les effervescences de kerunix

Vous avez été nombreux a me contacter ce weekend (et ce lundi, j'viens de me lever :p ).
Et bien j'etais... pas loin, mais pas la :)

Pas une seule seconde je me suis soucié de secondlife et de l'avenir, et ca fait du bien.

J'ai joué (et terminé) a "FrontLine : fuel of war".
Ca se passe en 2024, y'a preque plus de petrole et le monde se bat autour des quelques puits restants.
On pensait que "ils" allaient trouvé des solutions, mais le monde etait bien trop occupé a survivre pour chercher des solutions alternatives au petrole. Famine, Terrorisme, plus de petrole pour se deplacer, ...
Un FPS bien bourrin avec le moteur Unreal Engine, des vehicules, des drones, beaucoup d'ennemis. On a une team de PNJ avec nous, ils sont pas très futé et faut pas trop compter sur eux, mais ca occupe parfois l'ennemi ("les rouges", alliance russie-chine).

Du bon defouloir.


J'ai enchainé sur "Supreme Commander : Gold", avec l'extension "Forged Alliance".
Celui la je l'ai pas fini ;)
Par rapport au premier supcom' que j'ai connu, ils ont revu l'interface et c'est *beaucoup* mieux. Surtout en dual screen ;)
Le jeu ne rame pas avec 500 unités par camp (et 4 camps) et ca fait plaisir d'avoir un jeu reellement optimisé multi-core.

Contrairement aux campagnes du premier supcom' il n'y a pas de lente evolution du niveau technologique, des le premier chaptitre tu peux te bastonner a coup de Nv3 et d'experimentaux. Et y'a plutot interet a le faire.

Le jeu avance par etape, avec un partie de la carte seulement au depart, pour la totalité de la carte a la fin. A chaque objectif accomplis le carte s'aggrandi.
Je suis plutot dans le genre ou je n'avance qu'a condition d'avoir une superiorité numerique et technologique écrasante. 90% de mes parties sont : "Defense monstrueuse" + "Artillerie a gogo". Et un gros rush massif pour eliminer les restes laissés par l'artillerie. Ce qui fait des partie de 3h par carte, ca marche uniquement contre l'IA qui n'est pas trop du genre a prendre des initiatives.
Par contre les aggrandissement ce carte (passage a un sous-chapitre suivant) sont du genre violent. Il vaut meiux sauvegarder avant de finaliser chaque objectif, car les surprises sont parfois ... de tailles (rush de robot experimentaux, attaque nucleaire, ...).

Autant avec le premier supcom je n'avais pas tout a fait retrouvé l'ambiance de "total anihilation", autant la on est en plein dedans. Du bonheur ;)

Je reviens un petit peu sur 010 Editor et le format de texture.entries.

Ou je vais compliquer les choses... pour les rendres plus simple d'utilisation ;)
(L'informaticien est en grand faineant, mais il est capable de deployer une grande quantité d'energie afin de faire faire a l'ordinateur le maximum de boulot possible, et le minimum pour lui).


On va faire en sorte que la structure de textures.entries soit un peu plus lisible, voir utilisable a d'autres fins.
En particulier a propos de l'UUID.
Une UUID comme on la connait est sous cette forme : "a822ff2b-ff02-461d-b45d-dcd10a2de0c2"

C'est un ensemble d'octets au format en hexadecimal, separé par des "-" a certains endroits (pour des raisons qui m'echappent).

Hors, avec l'exemple de la partie 1, 010 Editor affiche une serie de chiffres decimaux qui n'ont aucun interets.
LLUUID stocke l'UUID, est le resultat presenté ne ressemble en rien a une UUID, mais a un tableau de 16 elements au format decimal.
Logique, c'est ce qu'on lui a demandé de faire.

Pour rappel, on a defini LLUID de cette facon : typedef ubyte LLUUID[16];
Et... c'est tres bien comme ca. il n'existe pas de type "chaine de caracteres en hexadecimal  separé par des tirets de temps en temps". C'est juste une histoire de format de presentation, pas de format de données.


Il est possible de dire a 010 Editor : "A chaque fois que tu va lire cette donnée, tu vas faire le travail que je vais te demander et qui est decrit dans une fonction que je vais te decrire".

Dans la partie 1 on a declaré et utilisé directement les structures. pour des raisons de simplicité.
Cette fois, de la meme maniere qu'on a créé le type "LLUID" (tableau de 16 ubyte) on va creer un type de structure, auquel on va rajouter un mot clé pour dire a 010 ce qu'il faudra faire a chaque fois qu'il lira ce type.

typedef ubyte LLUUID[16];

typedef struct
{
    float mVersion;
    uint32 mEntries;
} EntriesHeader;

typedef struct
{
    LLUUID mID;
    int32 mSize;
    time_t mTime;
} EntriesBody <read=ReadEntriesBody>;


A chaque lecture de EntriesBody, 010 Editor va executer la fonction "ReadEntriesBody".
Que l'on declare ici :

string ReadEntriesBody( EntriesBody &body)
{
    string s;
 SPrintf(s,"%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x",body.mID[0],body.mID[1],body.mID[2],body.mID[3],body.mID[4],body.mID[5],body.mID[6],body.mID[7],body.mID[8],body.mID[9],body.mID[10],body.mID[11],body.mID[12],body.mID[13],body.mID[14],body.mID[15]);
    return s;
}


La fonction Sprintf permet d'afficher un texte dans un format specifié.
Pour resumer :
"%02x" veut dire "affiche la donnée te correpondant (body.mID[0] pour la premier %02x, et ainsi de suite) au format hexadimal, sur 2 caracteres".
La syntaxe des regles de formatage pour Sprintf est un standard decrit partout sur le web (c'est la meme regle que le bon vieux "printf" du langage C (ou autre langages)).

On a declaré nos nouveaux, type, reste a les utiliser, on rajoute a la fin :
EntriesHeader header;
EntriesBody body[header.mEntries];   

Et voila. On se retrouve avec 010 Editor qui nous affiche les UUID au format qu'on connais. (et qui se trouve etre aussi le format du nom de fichier que l'ont peut trouver dans les reperoites de texture du cache secondlife).

cafééééééééééééééé !

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.

Pour ceux qui ont eu la patience de lire l'article precedent jusqu'au bout, il se seront peut etre demandé : "Ok, c'est bien joli tout ca, mais elle est ou la texture dans tout ca ?"

Et bien elle n'y est pas. Enfin, pas la en tout cas.
Ce fichier texture.entries est un fichier très simple, petit (assez petit pour etre stocké en permanence en memoire pendant l'execution de SL) et donc... rapide a utiliser.

Dans secondlife la vitesse d'execution est importante, ca rame deja assez comme ca non ?
Ce fichier est simplement un index qui est tenu a jour par le logiciel pour repondre rapidement a : "Est ce que la texture que je dois afficher sur ce prims est stocké dans mon cache, ou est ce que je dois la telecharger depuis les serveurs de secondlife ?".
Avoir un index des fichiers present dans le cache est donc tres utile et doit etre rapide.
Et avoir un fichier du type de celui du precedent article EST rapide, simple, leger, donc efficace :)


Mais au final ? Ou est la texture ?
C'est ... compliqué.
Linden Lab aurait put appliquer la methode suivante :
- un fichier qui indexe les textures cachées sur votre disque dur.
- un ou plusieurs repertoires contenant les dites textures.

Mais du coup les fichiers seront des textures directement lisible, editables avec photoshop et pouvant etre reuploader dans SL. Et ca va pas du tout du tout ! Parce que les fameuses textures qui sont stockées sur votre disque dur, dans le cache, ne sont pas forcements (et meme pratiquement jamais) des textures sur lequelles vous avez les droits de copie/modification/transfert. Hors, s'il y a un moyen de les recuperer puis les reuploader, vous vous retrouvez avec des textures full perm, a votre nom, dans votre inventaire. Horreur, scandale, abomination, vol de contenu, emeute et 5000eme mort annoncée de SL et son economie.

Vous connaissez la musique je suppose ? ;)
A propos de musique justement, Les majors de l'industrie du film et du disque depensent des millions, peut etre même des milliards afin de tenter de proteger les contenus. Sans succes, c'est peine perdue. Et bien c'est pareil dans secondlife. Quelle que soit la methode il y aura toujours moyen de "voler des textures", en utilisant le cache, ou par d'autres moyens (comme les recuprer dans la memoire video de la carte graphique par exemple).

Ce que font les majors, et ce que fait secondlife, c'est "la securité par l'obscurité". Autrement dit il font en sorte que le contenu a proteger soit stocké d'une facon qui rend compliqué le "vol". Par la cryptographie ou par d'autres moyens.

Linden Lab n'utilise pas la cryptographie car c'est lent et consommateur de precieuses ressources CPU. (on en a jamais trop avec SL).

A la place, ils stockent les textures d'une facon un peu bizzare... que je ne detaillerai bien evidemment pas.
Grosso modo il y a un fichier contenant les 600 premiers octets (a quelques details près ;) ) de toutes les textures stockées. Tous entassés les un derrieres les autres. (s'il y a 100 textures, ca fait un fichier de 600*100bytes (a quelques details pres, encore))

Une serie de fichier dont le nom est l'UUID de la texture, et qui contient la texture elle-meme *moins* les 600 premiers bytes (a quelques details près) qui sont, eux, stocké dans le gros fichier cité juste au dessus.

Un ficher permetant de savoir a quel endroit du gros fichier se trouvent les 600bytes qui interessent. Car il n'est pas possible de retrouver l'UUID de la texture directement dans le premier fichier, simplement parce que ca serait "trop simple" de les recuperer. Sans ce 3eme fichier, le 1er fichier est un gros tas de n*600bytes completement inutilisables.

C'est pour cela que quand on ouvre le ficher de texture directement dans photoshop, il n'arrive pas a l'ouvrir, car il manque (a quelques details pres) les 600 premiers bytes du fichier, qui se trouvent etres les plus importants car il contiennent les "entetes" qui permet a photoshop de decoder le format j2c puis de l'affichier.

Ce n'est pas si difficile que ca que d'assembler tout ca, et de finir avec une texture utilisable. Et d'avoir au final reussi a "voler" une texture. Ca demande de savoir programmer, de prendre le temps de defaire les sacs de noeuds que Linden Lab a mis en place pour rendre la chose plus difficile et de ... vouloir le faire.

Et, visiblement (et j'en suis heureux), ce qui peuvent le faire ne veulent pas perdre du temps a voler des textures.
Et ceux qui voudraient bien, n'en n'ont pas le talent (ca c'est pas une surprise) ;)

Au final, est ce que ce sac de noeud ne ralenti pas le systeme de cache ?
Un peu, tres peu, car la plus grosse partie du temps n'est pas dans la recherche/assemblage de la texture, mais dans le format de compression utilisé. Le format j2c est tres pratique, très bien, mais... lent a decompresser. Et c'est cette decompression qui prend la majorité du temps.
Aucun interet a rendre la recherche/assemblage du fichier 2x fois plus rapide si 99% du temps est passé dans la decompression du format j2c. Il faudrait plutot optimiser la decompression, mais la... C'est deja optimisé a mort.

J'ai trouvé un editeur hexa sympa : "010 Editor".

Il permet en particulier de creer des templates et des scripts dans un langage assez similaire au C pour la lecture et l'edition de fichiers binaires. Il n'est ni libre ni gratuit et fonctionne sous windows, mais rien n'est parfait dans ce bas monde ;)

A titre d'exemple j'ai fait 2 templates pour lire le fichier texture.entries.
La structure du fichier est la suivante :
- l'entete du fichier qui fait 8 octets : la version du fichier + le nombre d'entrée dans le fichier. (pas de "magic number")
- le corps du fichier composé d'un tableau de 24 octets : UUID de la texture + taille de l'image + date

L'UUID fait 128bits, comme il n'existe pas de type de base de 128 bits, je decide de creer un type perso de 16x8bits. J'aurai pu faire 4x32, mais il y a une bonne raison pour ne pas le faire (plus tard) ;)

typedef ubyte LLUUID[16];

Les premiers 32 bits du fichier donnent la version de la structure du fichier. Un nombre a virgule flottante (float).
Les 32 bits suivants representent le nombre d'entrées dans le corps du fichier ou, d'une facon plus pratique, combien de fois on va trouver dans le corps du fichier le tableau : UUID+taille+date. Ce nombre est un nombre entier non-signé de 32 bits (uint32).


Pour faire ca propre je definis la structure de l'entete du fichier dans une... structure ;)

struct FileHeader
{
    float mVersion;
    uint32 mEntries;
} monEntete;


Le corps du fichier est un poil plus complexe, mais très peu.
De la meme maniere on va definir une structure pour donner un sens aux 24 octets suivant.
A la difference près que cette structure sera repetée un certains nombre de fois, ce certain nombre etant tres exactement celui indiqué par "mEntries".
Ce qui donne un tableau de structure de "mEntries" elements.

La structure est la suivante :
- 128 bits representant l'UUID de la texture (de type LLUUID qu'on a defini au debut)
- la taille de l'image, un nombre entier sur 32 bits (int32)
- la date a laquelle la texture a été inserée dans le fichier. Cette date est representée par un entier de 32 bits representant le nobmre de secondes ecoulée depuis le 1er Janvier 1970. Ca parrait bizzare mais cette methode  de representation de date est tres pratique, prend peu de place et est tres utilisée. Tellement utilisée qu'elle a son propre type predefini : time_t. En indiquant time_t le logiciel saura que cet entier de 32 bits represente une date et nous affichera la date dans un format "lisible" plutot que d'afficher betement le nombre de secondes ecoulée entre 1/1/1970 et la date de creation de la texture en question.

C'est parti :

struct FileBody
{
    LLUUID mID;
    int32 mSize;
    time_t mTime;
} mesElements[monEntete.mEntries];

la derniere ligne indique que "mesElements" est un tableau composé de "mEntries" elements. Et qu'on peut trouver ce nombre "mEntries" dans "monEntete".
Par exemple, si mEntries = 100. On aura un tableau de 100 Elements. Soit 100 fois les 24 octets de "FileBody".

Ensuite... bein c'est fini. On lance tout ca dans 010 Editor et il nous affiche une jolie fenetre dans un format humainement lisible, plutot qu'un ensemble insipide de 0 et de 1.

Bonjour,

j'ai pris la décision toute personnelle de me retirer du programme "community gateway" et du devant de la scène de la communauté francophone. Ce n'est pas tant Linden Lab que toute une série de comportements et d'évènements qui m'ont fait prendre cette décision.

Je vais faire mon possible pour conserver tout ce qu'on a créé ces 2 dernières années. Essayer de voir avec les owner francophones et autres "grands acteurs" ( ) s'il est possible de parvenir a un accord pour conserver les principales sims. Dans le cas contraire, si on n'arrive pas a s'entendre, les sims seront vendues au détail sur le marché des sims de 2nd main. Un repreneur unique de toutes les sims serait bien sur une situation idéale.

Perso, je vais retourner aux sources : scripting, coding, et administration systeme. (conception de logiciel, de serveurs, et la Francogrid).

Tout cela ne sera pas fait dans l'urgence, donc inutile de paniquer pour ceux qui ont du terrain chez moi.

Je ne m'abaisserai pas a designer des coupables ou a regler mon linge sale en public, ni a me la jouer "après moi la fin du monde". Ce n'est pas le plaisir sadique de le faire qui me manque, mais ca ne desservirai personne, et surtout pas moi. Je suis simplement fatigué de jouer les don-quichotte et j'en suis le seul responsable. Je m'en vais retourner a des activités lucratives et bien plus reposante.

Je reste dans secondlife, mais en simple resident.

Merci tous ceux qui ont rendu ce monde possible et vivant pendant les 2 plus longues et difficiles années de ma vie.
Merci à tous ... et mort aux cons. 

... et au dela !


Beau comme ma 10ème opensim.

Oui, je me suis lancé dans opensim... surtout pour l'interet technique.
C'est en Alpha version, mais utilisable.

Opensim, ce n'est pas un seul serveur, mais plusieurs serveurs.
UserServer, GridServer, AssetServer, SimServer, InventoryServer, ScriptServer, MessagingServer.

Chacun ayant sa fonction, et sa base de donnée.
On peut tout faire tourner sur un seul serveur ("standalone"), c'est bien pour des mini-grillé privée ou bien faire tourner ca en mode "grille" pour gerer... des centaine... milliers... centaines de milliers de sim !!

J'aime bien commencer petit ... mais toujours voir grand ;)
Pour le coté grille, je me suis installé sur la francogrid et je collabore avec eux pour penser a une architecture de grille capable de gerer des milliers de sim.

Pour resumer de facon simple, il y a 2 type d'approches :
- Un serveur "gros cul" super bourrin genre octocore 16GB de RAM, etc ...
- L'approche "google", une quantité astronomiqe de miniserveurs pas cher.


Pour le serveur "gros cul", le matos coute horriblement cher.
Au debut il sera largement sous-utilisé, perte d'argent.
Apres... il risque de ne pas etre assez puissant... il faut le changer vers quelque chose de plus puissant... en considerant que ca existe !!

L'approche "google", c'est plein de serveur pas cher, et on rajoute des serveurs en fonction de la charge.
Ca demande la realisation d'outils speciaux, on ne manage pas aussi facilement un gros serveur que des milliers de petits. Mais ca... c'est mon metier ;)

Et donc j'ai adopté l'approche "google". Qui a de multiple autres avantages amis je ne vais pas me lancer dans des explications barbares : trop long, trop compliqué et ... Secret Industriel ;)

Je me concentre d'abord sur la partie "serveur de sim". La grille etant fonctionnelle, supportant largement la charge pour l'instant, et va de toute facon radicalement changé d'architecture dans le futur, pas la peine de se prendre la tete sur un truc qui sera obsolete dans 6 mois. Cela dit il faut y penser des maintenant, car on sait a quoi ca va ressembler dans le futur.


Grosso-modo, un serveur de sim a besoin de quoi :
- Beaucoup de RAM, en quantité assez fixe par sim.
- Un serveur sql
- Tres peu d'espace disque (tout est sur le serveur sql)
- Du cpu... de facon variable.

Une sim peut utiliser 5% du cpu comme elle peut en utiliser 100%, beaucoup de facteurs entre en jeu.
L'idée est d'avoir x sim par serveur, et de faire evoluer dynamiquement le nombre de sim par serveur selon la charge. Un serveur peut tres bien supporter 10 sims qui foutent rien (a condition d'avoir assez de ram), comme ne pas arriver a supporter une seul sim. Et... ca peut changer au fil des jours, on meme de la journée !

Voir : http://88.191.75.142/SLstat/

Il faut voir gros, et eliminer l'inutile pour reduire les couts au maximum.
A commencer par l'espace disque par sim...

Tous les serveur de sim vont utiliser une baie iSCSI pour le stockage... 1Go de disque par sim c'est largement suffisant, alors pourquoi depenser dans des disques qui font au minimum dans les 80Go.  Economie d'energie, economie de matos, ... d'argent. L'idée c'est bien sur de proposer des sims les moins chere possible ;)

Peu de ram par serveur en general, car le cpu sera a fond bien avant qu'il y ai assez de sim pour bouffer toute la ram dispo.
Cas particulier : Quelques serveurs avec beaucoup de RAM pour gerer des sims qui n'ont pas besoin de CPU. (water sim, etc)


pour les bases SQL de chaques sim (et non pas de la grille, ou de l'inventaire, juste celles des sims).
Une quantité de serveur sql "moyens" avec un systeme de replication et de proxy-cache.

Autrement dit : chaque sim va interroger 2 front-end (redondance), qui vont se charger de faire les requetes et de fournir le resultat au serveur de sim. Qu'il y ai 1, 2, 5000 serveurs sql derriere n'est pas le probleme des sims.
Ca permet un load-balancing dynamique et de faire evoluer l'architecture en fonction de la charge... pas besoin d'un serveur enorme et couteux, ni de se perdre dans des optimisations fastidieuses... Et si un serveur sql plante, ca ne pose strictement aucun probleme grace a la replication. Qu'on tourne avec 50 ou 49 petits serveurs sql ne changera pas grand chose... 2% ... Qu'on tourne avec 2 ou 1 gros serveur ... pose un gros probleme (50% !! )
(autrement dit : plus un serveur est gros, plus dure est la chute)

Configuration dynamique... il faut des outils simple pour migrer une sim d'un serveur a l'autre.
Une grande partie est resolue en externalisant la base de donnée.
Si un serveur plante... on relance les sims sur un autre serveur... aucun probleme de donnée perdue... puisque les données ne sont pas sur le serveur qui a planté.

Actuellement, j'ai 9 sims sur 2 serveurs. Et je peux en rajouter d'autres ... normal, y'a personne :))
Au fur et a mesure que la charge augmentera, il suffira de rajouter des serveurs pour avoir moins de serveurs par sim.

Grosso modo : pour le meme prix, il est possible de faire tourner 10 sims peu chargée.... ou une seule sim chargée ;)

Pourquoi je raconte tout ca ?
Les grandes lignes de l'architecture mise en place n'est pas vraiment secrete...
Les outils et les details le sont, et sur ce point je n'ai rien dit ;)
Les competances pour mettre tout ca en place... m'appartiennent ;)


Donc... d'ici peu, je pourrai proposer l'hebergement de sims sur opensim (francogrid ou grille privée).
A (beaucoup?) moins de 30.000L$ par sim .
Comparés aux 100.000L$ chez LL ;)

Et meme mieux, avec ce systeme dynamique... Un forfait ou vous payez "a la charge".
Par exemple, pour le meme prix : "10 sim peu chargée" ou "1 sim chargée".
Et louer des "unité de charge" supplementaire au fur et a mesure que la charge de chaque sim augmente.

C'est pas beau ca ?

Entre 2 posts serieux, on trouve parfois des perles, ca viens de JOL, et ca sera classé dans la catégorie "exercice de style".
J'suis fan, merci pour ce post !!

J'ai trouvé ca au hasard, j'suis fan :

« Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux, ils en diraient bien davantage. » [ Sacha Guitry ]