« Réunion du 21-01-2025 » : différence entre les versions
Apparence
(14 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 16 : | Ligne 16 : | ||
* OpenSimulator utilise des GUID (Identifiants Globaux Uniques) par défaut de Microsoft, qui sont souvent utilisés dans les applications Windows. Ces UUID sont généralement générés à l'aide d'une méthode statique qui crée un UUID de version 4, conforme à la norme RFC 4122. | * OpenSimulator utilise des GUID (Identifiants Globaux Uniques) par défaut de Microsoft, qui sont souvent utilisés dans les applications Windows. Ces UUID sont généralement générés à l'aide d'une méthode statique qui crée un UUID de version 4, conforme à la norme RFC 4122. | ||
* .NET 8 utilise des UUID de '''type 4''', ce qui est cohérent avec l'utilisation de GUID par défaut de Microsoft. | * .NET 8 utilise des UUID de '''type 4''', ce qui est cohérent avec l'utilisation de GUID par défaut de Microsoft. | ||
== UUID et Efficacité de Recherche | * '''En augmentant la taille du hash''', par exemple en utilisant SHA-512, on diminue la probabilité de collisions. En effet, une taille de hash plus grande offre un plus grand nombre de combinaisons possibles, ce qui réduit le risque de collisions. Cependant, cela impliquerait un recalcul, une consommation accrue de CPU et pourrait impacter les performances de lecture et d'écriture sur des disques déjà fortement sollicités | ||
== UUID et Efficacité de Recherche== | |||
* Certaines personnes pensent que les UUID réduisent les performances des bases de données en augmentant le temps de réponse des algorithmes de recherche. Ubit Umarov n'est pas forcément de cet avis, il pourrait y avoir d'autres facteurs qui entrent en jeu. Toutefois il évoque les UUID de type 7 et 8, qui pourraient avoir des modifications compatibles avec les bases de données. | * Certaines personnes pensent que les UUID réduisent les performances des bases de données en augmentant le temps de réponse des algorithmes de recherche. Ubit Umarov n'est pas forcément de cet avis, il pourrait y avoir d'autres facteurs qui entrent en jeu. Toutefois il évoque les UUID de type 7 et 8, qui pourraient avoir des modifications compatibles avec les bases de données. | ||
* En comparant les algorithmes de recherche passés à "bogo sort" et les algorithmes de recherche actuels à "bubble sort", Vincent Sylvester souligne que les recherches dans le passé étaient extrêmement inefficaces par rapport à celles d'aujourd'hui. Il mentionne que MySQL travaille à améliorer ses algorithmes de recherche alors que MariaDB se concentre sur l'efficacité de l'utilisation de la mémoire. | * En comparant les algorithmes de recherche passés à [https://fr.wikipedia.org/wiki/Tri_stupide '''"bogo sort"'''] et les algorithmes de recherche actuels à [https://fr.wikipedia.org/wiki/Tri_%C3%A0_bulles '''"bubble sort"'''], Vincent Sylvester souligne que les recherches dans le passé étaient extrêmement inefficaces par rapport à celles d'aujourd'hui. Il mentionne que [[Lexique_des_réunions#MySQL |'''MySQL''']] travaille à améliorer ses '''algorithmes de recherche''' alors que [[Lexique_des_réunions#MariaDB |'''MariaDB''']] se concentre sur l'efficacité de l'utilisation de '''la mémoire'''. | ||
== Cache == | |||
* '''La mise en cache des assets''' stocke temporairement des ressources (comme des textures) pour un accès rapide dans OpenSimulator. | |||
* En pratique, la mise en cache basée sur le hachage est assez courante, tout comme l'utilisation des uuids. Mais dans OpenSim, la '''quantité de données exploitées est massive''' par rapport à la plupart des autres systèmes, au point que certains systèmes de fichiers auront du mal à tenir un journal. La mise en cache est une excellente idée pour les assets, mais sa mise en œuvre est encore plus compliquée que le hachage, à cause des '''changements fréquents dans les données'''. | |||
* '''Les disques modernes''' (comme [https://fr.wikipedia.org/wiki/NVM_Express NVMe]) ont des caches internes qui améliorent la vitesse d'accès. | |||
* Vincent Sylvester a utilisé un [https://fr.wikipedia.org/wiki/R%C3%A9seau_de_diffusion_de_contenu '''Réseau de Distribution de Contenu '''(CDN) ] qui distribue des données à partir de plusieurs serveurs situés à différents endroits pour rapprocher les données des utilisateurs et réduire le temps de chargement. Mais la gestion des mises à jour peut être compliquée et cela ne diminue pas vraiment la charge sur la copie principale des assets, car ceux-ci sont souvent uniques et peu nombreux. | |||
* Il a configuré les caches pour qu'ils durent plusieurs heures ou jours, mais il n'a observé qu'une seule requête, ce qui indique qu'il n'y a pas suffisamment de duplications pour justifier un meilleur taux de cache. | |||
* Il pense que le taux de réussite pourrait être meilleur si les requêtes venaient directement des viewers, mais cela pourrait causer des problèmes avec les textures dynamiques, ce qui n'est pas souhaitable. | |||
* Le temps que '''le viewer''' prend pour traiter les données peut être un facteur limitant, plus que la capacité du serveur. | |||
= Infos= | = Infos= | ||
== Développement d'une application pour Zoom == | == Développement d'une application pour Zoom == | ||
* | === Question === | ||
* Jagga Meredith essaie de développer une application [https://fr.wikipedia.org/wiki/Zoom_Video_Communications '''Zoom]'''. Il ne sait pas comment configurer l'authentification OAuth nécessaire pour cela. | |||
* [https://fr.wikipedia.org/wiki/OAuth '''L'authentification OAuth'''] est un protocole standard qui permet à une application d'accéder à des ressources d'un utilisateur sur un autre service sans avoir à partager les identifiants de l'utilisateur (comme le mot de passe). | |||
* Jagga Meredith ne trouve pas Zoom comme un choix disponible pour configurer l'authentification. | |||
=== Réponses=== | |||
* Google fournit un schéma d'url spécial avec un email, un émetteur et une clé secrète. L'application demande ensuite la validation de ce point d'accès. | |||
* Gmail pose certains problèmes, des mises à jour de sécurité peuvent affecter la compatibilité avec certains clients de messagerie tiers, comme [https://fr.wikipedia.org/wiki/Mozilla_Thunderbird '''Thunderbird '''] | |||
= Source= | = Source= | ||
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-01-21 | http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-01-21 |
Dernière version du 7 février 2025 à 11:38
Avertissement
Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉 |
Base de données
Stockage des assets
- Sur sa grille, Vincent Sylvester utilise un système basé sur SRAS (Simply Ruby Assets Service) qui ressemble à FS Assets. SRAS stocke les assets sur le disque, effectue la compression et la déduplication des assets identiques. Ce type de système stocke les assets sous forme de fichiers via leur hachage, de sorte que plusieurs uuids d'assets peuvent faire référence aux mêmes données s'il s'agit de la même chose. La déduplication permet de réduire les besoins en stockage et d'augmenter la vitesse de la recherche.
- La déduplication peut parfois permettre d'économiser 30 à 40 % d'espace disque. Bien que son efficacité ne soit pas toujours aussi grande qu'on pourrait le penser, elle reste préférable à un stockage direct de tous les fichiers dans la base de données.
Nettoyage des assets
- Vincent Sylvester a écrit une routine pour récupérer le hash d'un asset, vérifier s'il existe dans la base de données et s'il n'existe pas il le retire des assets. Ainsi il a pu supprimer environ 43000 notecards soit 210 Mo. Il a également ajusté un script pour qu'il limite le taux de spam de notecards à 60 par jour. Cela prend un certain temps à lire étant donné le nombre de fichiers, environ 7 millions.
- Il a aussi supprimé des scripts qui génèrent des notecards toutes les 5 minutes. Il estime qu'ils ne méritent pas d'exister.
Le hachage
- Les hashes, comme SHA-256, sont presque uniques, mais il existe des cas de collisions d'UUID, c'est-à-dire que le hachage de deux objets peut renvoyer le même UUID. Dans l'ensemble, la probabilité est suffisamment faible pour que les problèmes ne soient pas catastrophiques, mais ils sont possibles.
- La compression sans perte est un processus qui réduit la taille des données sans perdre d'informations. Pour que cela fonctionne correctement, il faut des algorithmes robustes qui peuvent gérer les données de manière efficace.
- Les UUID basés sur le temps utilisent des éléments comme l'horodatage pour générer des identifiants. Les collisions uuid basées sur le temps devraient être minimales.
- OpenSimulator utilise des GUID (Identifiants Globaux Uniques) par défaut de Microsoft, qui sont souvent utilisés dans les applications Windows. Ces UUID sont généralement générés à l'aide d'une méthode statique qui crée un UUID de version 4, conforme à la norme RFC 4122.
- .NET 8 utilise des UUID de type 4, ce qui est cohérent avec l'utilisation de GUID par défaut de Microsoft.
- En augmentant la taille du hash, par exemple en utilisant SHA-512, on diminue la probabilité de collisions. En effet, une taille de hash plus grande offre un plus grand nombre de combinaisons possibles, ce qui réduit le risque de collisions. Cependant, cela impliquerait un recalcul, une consommation accrue de CPU et pourrait impacter les performances de lecture et d'écriture sur des disques déjà fortement sollicités
UUID et Efficacité de Recherche
- Certaines personnes pensent que les UUID réduisent les performances des bases de données en augmentant le temps de réponse des algorithmes de recherche. Ubit Umarov n'est pas forcément de cet avis, il pourrait y avoir d'autres facteurs qui entrent en jeu. Toutefois il évoque les UUID de type 7 et 8, qui pourraient avoir des modifications compatibles avec les bases de données.
- En comparant les algorithmes de recherche passés à "bogo sort" et les algorithmes de recherche actuels à "bubble sort", Vincent Sylvester souligne que les recherches dans le passé étaient extrêmement inefficaces par rapport à celles d'aujourd'hui. Il mentionne que MySQL travaille à améliorer ses algorithmes de recherche alors que MariaDB se concentre sur l'efficacité de l'utilisation de la mémoire.
Cache
- La mise en cache des assets stocke temporairement des ressources (comme des textures) pour un accès rapide dans OpenSimulator.
- En pratique, la mise en cache basée sur le hachage est assez courante, tout comme l'utilisation des uuids. Mais dans OpenSim, la quantité de données exploitées est massive par rapport à la plupart des autres systèmes, au point que certains systèmes de fichiers auront du mal à tenir un journal. La mise en cache est une excellente idée pour les assets, mais sa mise en œuvre est encore plus compliquée que le hachage, à cause des changements fréquents dans les données.
- Les disques modernes (comme NVMe) ont des caches internes qui améliorent la vitesse d'accès.
- Vincent Sylvester a utilisé un Réseau de Distribution de Contenu (CDN) qui distribue des données à partir de plusieurs serveurs situés à différents endroits pour rapprocher les données des utilisateurs et réduire le temps de chargement. Mais la gestion des mises à jour peut être compliquée et cela ne diminue pas vraiment la charge sur la copie principale des assets, car ceux-ci sont souvent uniques et peu nombreux.
- Il a configuré les caches pour qu'ils durent plusieurs heures ou jours, mais il n'a observé qu'une seule requête, ce qui indique qu'il n'y a pas suffisamment de duplications pour justifier un meilleur taux de cache.
- Il pense que le taux de réussite pourrait être meilleur si les requêtes venaient directement des viewers, mais cela pourrait causer des problèmes avec les textures dynamiques, ce qui n'est pas souhaitable.
- Le temps que le viewer prend pour traiter les données peut être un facteur limitant, plus que la capacité du serveur.
Infos
Développement d'une application pour Zoom
Question
- Jagga Meredith essaie de développer une application Zoom. Il ne sait pas comment configurer l'authentification OAuth nécessaire pour cela.
- L'authentification OAuth est un protocole standard qui permet à une application d'accéder à des ressources d'un utilisateur sur un autre service sans avoir à partager les identifiants de l'utilisateur (comme le mot de passe).
- Jagga Meredith ne trouve pas Zoom comme un choix disponible pour configurer l'authentification.
Réponses
- Google fournit un schéma d'url spécial avec un email, un émetteur et une clé secrète. L'application demande ensuite la validation de ce point d'accès.
- Gmail pose certains problèmes, des mises à jour de sécurité peuvent affecter la compatibilité avec certains clients de messagerie tiers, comme Thunderbird
Source
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-01-21