BRULE Herman

BRULE Herman

Développeur de ultracopier: http://ultracopier-fr.first-world.info/

Home page: http://ultracopier-fr.first-world.info/

Jabber/GTalk: brule.herman@gmail.com

Posts by BRULE Herman

Création de mmorpg

0

Bonjour, voilà mon retour d’expérience comme joueur/administrateur système et GM de mmorpg, cet avis sera peut-être déjà acquis pour la plus part:

 
Point gameplay:
- Le jeu doit être amusant en solo comme un multi, pour ne pas abandonner si peu de personnes viennent
- Seulement recopier un gameplay ne sert à rien, leurs joueurs irons toujours à gameplay égale là où il y a d’autres joueurs. Inovez!
- Avoir un datapack/rates personnalisable, histoire que chaque personne y trouve son compte (histoire spécifique, augmentation des levels à son rythmes)
- Avoir des extensions de protocoles avec une bonne base, pour étendre le gameplay.

 
Partie performance:
- Beaucoup de dev font du: multiplayer online role-playing game (MORPG) pas du _Massively_ multiplayer online role-playing game (_M_MORPG), il prévoit pour 50 joueurs (pour eux c’est _Massively_, et se plante quand ils ont plus de joueurs)
- Ce qui en résulte, que le petit GM qui veut ouvrir son petit serveur le ferme rapidement car tous les mois il doit claquer des sommes folles en dédié (60€/mois pour avoir une machine correcte chez ovh).
- La personne qui veut mettre son serveur sur sa ligne ADSL ne peuvent en général pas. Car le débit est trop faible (personne ne fait de compression de la connexion tcp, ni ne prévois des options pour minimisé le débit), et à cause des pings. On peut pour la plupart des jeux, faire des protocoles d’auto-correction des latences qui permettent d’éviter que les pings n’ont trop d’importance. Pourtant, héberger chez soit, ou sur un trés petit hébergement est très utile pour démarrer.
- Calcule de complexité, rare sont ceux qui le font, cela ce pose surtout sur les joueurs qui se vois mutuellement, c’est en général: bande passant + cpu = nombre de joueur qui se vois mutuellement ^ 2

- Tout le monde se dit: on verra après pour les performances, hors une fois que tu as 1000 personnes en ligne et un serveur/client complet, personne n’a le courage de le refaire, surtout si il est crade. Résultat, tout le monde ralle car sa rame.

- Les pc ont une puissance qui augmente exponentiellement et le serveur sont exponentiellement plus lent (ce qui fait que depuis des années le nombre général maximum de joueurs reste fixe). Idiot vous direz. La plupart des serveurs ne supportent que <70 joueurs visibles mutuellement et 1000 connectés. Ce qui est très petit (j’ai fait sans problème 500 visibles et 100 000 connectés).

- Pour un petit nombre de joueur (<20), un simple mono coeur atom/arm, quelque centaine de mega de mémoire, une connexion adsl doivent suffire et pour les larges échelles (>10 000), un bon serveur (quad core, 8Go de mémoire, 1000Mbps) doit aussi suffire.

 
J’ai déjà vu:
- L’utilisation de tous les coeurs en multi-thread avec tellement de mutex qui se gène mutuellement. Cela fait des temps système énorme car sur certain cpu il n’y a pas d’optimisation hardware des mutex. Et qu’un seul cpu était utilisé en gros au final. (Je parle de l2jfree comparé au serveur propriétaire).
- Des serveur qui prennent 10% du cpu à vide sans aucun joueur…(minecraft, l2jfree, …), soit des fois c’est utile (timer et autre), mais pas avec 10% du cpu!
- Blockage, les joueurs s’en fiches que vous utilisez vos 56 coeurs si ça rame, ils veulent que ça ne rame jamais. Le plus efficace est donc de travailler en event, d’isoler les complexités exponentielles et les accés db/disk dans un thread. Idem pour les parties lentes. Dans le multi-thread avec event, essayer de libérer les boucles d’event+thread critique d’un maximum de choses pour gagner en latence.
- Ne sauvegardez pas en continu dans la base de données, faites le à la déconnexion des joueurs, pour les données continues (tel que les déplacements), à intervalle régulier. Bien sûr, les choses ponctuels peuvent être backupé en instantané (mais dans un thread à part).

 

 

Donc pour tout le monde (hébergeur, celui qui paye le dédié, les joueurs avec compte payant pour payer le dédié), il est indispensable de soigner certain point tel que les performances, le protocole (ça permet aussi de faire d’autres implémentations), la sécurité, la prévention de bug (personne n’aime quand tout le serveur crash et ça re-roll avec les données d’il y as 1h).
Je ne conseille à personne de faire le noob et de se lancer dans un jeu sans avoir déjà une bonne expérience en programmation (et avec un projet clair et réaliste). Les joueurs font partie des utilisateurs les plus exigeants et ce segment est là où il y a le plus de concurrence. Cela se traduit par déjà un grand projet public ou une solide motivation + y jouer même tout seul.

 

 

Les graphismes (je ne suis pas graphiste, mais j’ai quand même un peu d’expérience, manga, pixel art):
- Il ne faut pas les bâcler, car comme moi, beaucoup de joueurs regardent ça pour trier les bons jeux des petits jeux de merde. Donc très important pour avoir de nouveaux joueurs, bien plus que pour les logiciels. Il vaut mieux en avoir peu et bien, que beaucoup et mal. (J’aime bien mars space shooter pour ça)
- Les graphismes personnalisables dans le datapack sont importants.

 

 

Les fonctionnalités des bases importantes:
- Toujours prévoir l’envoie du pass en hash (sécurité), beaucoup utilise le même passe partout (dons les visites qu’il visites)
- L’update du datapack (voir client) dans le protocole, c’est assez crade d’avoir un updater à côté de son jeu
- Datapack par serveur, pour avoir des données par serveur et charger soit en fixe (pour les données les – dynamiques) soit à chaud (pour les données les + dynamiques). Important pour la concurrence et minimiser les données transmises et ne pas charger tout le temps les données dynamiques identiques (ratio read/write correcte pour la partie dynamique).
- Définir le nombre max de joueurs en ligne et en db (définir sur 16Bits, 32Bits ou 64bits), et bien proportionner/optimiser son serveur/client.
- Ne pas exclure de joueurs (multi-platforme, ou au moins support sous wine). C’est toujours frustrant (surtout quand on a acheté le jeu), de passer sous windows pour jouer (ou d’être privé du jeu si on a pas windows ;) ).

- Visibilité correcte, faite en sorte que le joueur voit toujours une proportion correcte de l’écran (zoom adaptatif, …). Quitte à réduire la distance de visibilité si le nombre de joueur est trop grand. Et à ne rien afficher si les calcules à faire sont exagérés (le joueurs préfèrent ne rien voir, que de tout voir et que ça lag tellement qu’ils ne peuvent pas jouer). N’oubliez pas de mettre des hystérésis pour éviter de lag/prendre trop de bande passante près de la limite du serveur.

Fin de ultracopier 0.3

0

Bonjour, je suis heureux de vous annoncer que j’ai fini ultracopier 0.3 pour la partie fonctionnalités. Et oui, les dernières qu’il manquais dons certaine depuis les 1ere version (checksum, list de copy, …) sont faites. Tout ça grace à sa modularisation.

Je doit encore chercher et corriger les bugs, nettoyer un peu tout, faire la doc, et peu être un peu continuer cette branche. Le prochaine branche 0.4 sera sur Qt5, et il y as pas mal de chose à refaire, mais ça devrai être assez rapide.

(Lire la suite…)

Checksum et buffer sous Ultracopier 0.3

0

Bonjour, j’ai commencé rapidement à mettre en place le buffer et le checksum sous Ultracopier 0.3. Le checksum vas me demander plus de travail, car j’ai fait toutes les variantes.

J’ai aussi commencer à implémenter les filtres. Ma vie professionnel me prends beaucoup de mon temps libre, donc j’ai hélas pas beaucoup de temps pour faire avancer ultracopier.

Grace au projet pokecraft, je commence à maîtriser les listes indexés (type QHash, QSet, …), ce qui me permet de faire plus d’optimisation qu’avant (+500% sur le moteurs d’options je pense). Grace à Qt5 les signaux/slots seront + rapide, ce qui permettra d’avoir plus de performance sur les petits fichiers, et la préallocation d’un buffer char* permettra d’avoir plus de performance sur les gros fichiers.

Pokecraft

0

Début du projet pokecraft, qui est à la fois un jeu et un mmorpg.

Déjà dés le debut il fait à certain endroit 10x à 100x plus rapide que les autres jeux, il as un protocol asyncrone qui lui permet de ne jamais être ralenti par les lentences (internet ou serveur). Il permet aussi de viré toutes les communications qui ce base sur l’aléatoire, et il as une très petite empreinte mémoire/cpu/réseau.

Il est basé sur Qt, et sur les events. Le serveur sépare chaque groupe de tache dans un thread pour ne pas faire ramer les autres groupe de taches (une lenteur du chat ne ralenti pas le calcule des maps et inversement)

Coté gameplay c’est un mix pokemon pour le RPG, tour par tour, lineage pour le mmorpg, X3 pour le commerce et la production de bien, et minecraft pour le crafting.

Le client temporaire est fait avec QGV, mais il vas étre refait en QML2. Le server vas être refait en Qt5.

J’en profite pour soufler un peu d’ultracopier, j’ai pas mal bosser dessus, et je reprendrai quand j’en aurai marre de pokecraft. Et ça me permettra de jouer/mapper/dessiner un peu quand le client marchera.

Optimisation prestashop en 2012

Bonjour, pour ultracopier j’ai ouvert ma boutique en ligne, avec prestashop 1.5 (Version Beta en développement):

http://ultracopier-shop.first-world.info/ pour vendre Ultracopier ultimate

Suite à ça je me suis attaqué aux performances, voila les conclusions:

  1. Le CCC cache conseillé par prestashop est à désactiver +40% de performance, -20% de temps de chargement (voir Theoretical_css_grouping_on_site_web pour plus de détails)
    • Raison: Car le CCC cache compresse le contenu de la page en échange d’énorme temps cpu (car il doit lire la syntaxe des fichiers), hors cela oblige de passer tout les fichiers par du php (perte de perf + blocage lors des accés concurrents), le gain en taille brute dans le thémes par défaut est mois de 10%. De plus grouper tout les js permet une meilleure compression, mais oblige à charger tout le groupe à chaque fois, donc on télécharge 150Ko à chaque page différentes au lieu de télécharger 2Ko des seuls fichiers js qui sont spécifique à la page (mauvaise utilisation du cache navigateur)
    • Example: Visite sur la page home, la catégorie, le produit, le payement: Avec CCC 4x150Ko=600Ko de chargé, sans CCC 148Ko+2Ko*4=156Ko
    • Solution: Compresser manuellement les fichiers, la compression html devrai étre avant la mise en cache, pour en pas recalculer la même chose à chaque fois. Il ne faut pas voir le gain sur une page, mais dans la navigation générale du site.
  2. Les statistiques dans prestashop sont à désactiver -50% de temps de chargement
    • Raison: Tout les logiciels de statistiques prennent du temps de calcule, dans le cas de prestashop, ces temps sont ajouté au temps de la page, dans un outils comme google analitics ou piwik, ces temps sont mis en arriére plan car il sont appellé aprés le changement de la page en arriére plan. De plus, il font des écritures constantes, ce qui anule la plus part des caches dans le systéme et dans mysql.
    • Solution: Temporaire: désactivé les stats dans prestashop et activé des stat google analitic ou piwik, Finale: désyncroniser les taches annexe tel que le tracking visiteur pour ne pas ralentir le corps de page
  3. Les caches dans prestashop sont à activer partiellement +30% de performance
    • Caches:
      • Smarty: cache + Compile cache if templates are updated, activé ça diminue les performances
      • Optional features: désativé ça n’augemente pas les performances, ça les diminues. Laissez les actifs.
      • CCC (Combine, Compress and Cache): Désactivé, voir le point 1), par contre la minimisation du js/css devrai être quand même faite, et prestashop la font de façon correcte (compression puis accès à un fichier statique).
      • Apache optimization: Désactivé (à réglé proprement sur apache pour avoir tout les sites du serveur bien réglé, et ne pas faire 2x la même chose), déjà fait chez les bons hébergeurs. Il mettent Etag à none, hors désactivé le module est mieux, mais à cause du non chargement du module la directive fait une erreur 500
      • Media servers (use only with CCC): à activer, cela permet sur supprimé 2Ko par fichiers et en upload! (pas de cookie, vu le nombre de fichiers c’est intéréssant de l’activé sans CCC, ça fait 50% de la taille de l’upload), par contre il ne met pas tout les medias sur les serveurs de médias.
      • Caching: -40% de performance si activé, quelque soit l’endroit où est le cache (File system, ram disk, memcached, APC, …)
    • Raison: Les caches sont pire que sans cache si il sont mal géré ou buggé, ici c’est le cas
    • Solution: Corrigé proprement les caches, leurs syncronisation et implication.

Prestashop est un bon utilitaire, cepandant: les performances ne sont pas là (wordpress qui est lent, est plus rapide), les caches font perdre en performance au lieux de faire un gain. Les conseilles sont faux et il n’explique pas ce que ça implique.

Voila des exemples de performance sur mon serveur:

  • WordPress: Requests per second:    425.22 [#/sec]
  • Prestashop: Requests per second:    33.99 [#/sec]
  • Site php pur sans aucun cache + bibliotéque php rapide + tout d’un site web (rewrite rules, …): Requests per second:    5127.05 [#/sec]
  • Site avec un cache html pur type http://www.calle-hardware.com/: Requests per second:    32954.36 [#/sec], ce genre de site est facilement fait, et n’oublige pas d’avoir des pages statiques mis en cache coté navigateur
Gestion de cache possible
Des meilleurs performances serai idée pour un meilleur confort de navigation. Pour minimiser les frais d’hébergement. Et pour maximiser le nombre de visiteurs lors d’aflux masif (newsletter, projet populaire, …).
Les ratios visites/achat sont en générale: beaucoup de vistes pour peu d’achat, soit beaucoup de lecture de page, pour peu de modification de page (si sont affiche par exemple l’état du stock, il change à chaque achat). En plus on ne peu utiliser aucun reverse proxy pour prestashop car il faudrai qu’il asyncronise les données dynamiques, cela permettrai aussi de faire un affichage réactif car ça afficherai directement la page, et les trackings des visiteurs, obtentions des données de session (panier, nom du visiteur, …) serai chargé en différé sans géné la navigation.
Gestion de la bande passante
Je note aussi que dans les pays riches les connexions sont rapide, alors + la compression gzip d’apache, la page html (avec html bien formaté) reviens à 5Ko, soit 0.001s en france (avec du 500Ko/s pratique soit 5Mega), et 0.1s en dans un pays pauvre telque la bolivie. Donc les temps de chargements de pages de plus de 30ms sont trés important en comparaison du temps de téléchargement de la page. Donc arrété d’essayer d’optimiser le poids de la page en dépis des performances. Surtout que le poids viens surtout des images.
Configuration de teste
Teste prestashop fait sur: http://ultracopier-shop.first-world.info
Commande pour tester les sites:
ab -k -r -c 100 -n 1000 http://www.site.com/en/
Les performances de php 5.2 avec apc sont les mêmes que php 5.4 sans apc (sauf que pour php 5.4 il y as moins de mémoire utilisé, donc ça évite de swapper et de ralentir le hdd pour la monté en charge).
Serveur ovh SP SSD, Intel Core i5-240016 Go DDR3, avec ramdisk (tmpfs), ext4 nobarrier, kernel 3.1.
La version de prestashop utilisé: 1.5.0.9 (Version Beta en développement).
Utilisation des ressources
Teste fait sur un serveur de production, réglé pour la production. Mysql avec cache et buffer. Cpu: 3.5% pour mysql, 80.5% pour php, 16% de temps système, 0% de temps wa -> hdd).
Pourquoi tant de temps systéme??? Que fait t’il pour faire autant d’appelle au noyau?
Les appelles systèmes sont lent car il faut faire le lien entre l’espace noyau et l’espace utilisateur, et en espace noyau, certaines ressources bloque la monté en charge car une seul thread peu y accéder.
La commande ab est lancé sur le même serveur pour ne pas avoir de limitation de bande passante, elle ne peu étre responsable des temps systéme vu qu’elle n’utilise pas intensivement la couche réseau (quelque dizaine de requetes secondes)
Profiling du prestashop

Détails de ce qui prends du temps:

Context::getContext()->shop = Shop::initialize(); 11ms
Shop::setContext(Shop::CONTEXT_SHOP, Context::getContext()->shop->id); 3ms devrai étre 0ms
Configuration::loadConfiguration(); 3ms
require_once(dirname(__FILE__).'/smarty.config.inc.php'); 13ms
Dispatcher::getInstance()->dispatch(); 76ms
Autre cumulé: 5ms

Temps rajouté par l’activation du cache:

50ms par l'activation du cache smarty, le temps est rajouté à Dispatcher::getInstance()->dispatch();
20ms par l'activation du cache normal dans settings.inc.php dans divers partie du code

Ultracopier avec MVC

Bonjour, la sortie des versions d’ultracopier est ralenti pour implémenter le système MVC (modèle vue contrôleur), pour avoir de gros gain de performance sur les trés large copie (+ de 2 000 000 fichiers à copier).

J’ai aussi refait les structures interne pour accéléré au maximum tout, mais j’ai mit un point d’honneur au niveau du choix de dev, à la réactivité de l’interface. Il y as de moins en moins de boucle, elle sont de plus en plus optimisé. J’ai groupé 2 gros calcule en 1, qui sont très lent lors de très très large liste. Je pense qu’après tout ça, ultracopier sera plus apte que n’importe quel logiciel à faire des large copie et des copie rapidement.

J’ai aussi perdu beaucoup de temps sur le support de mac avec Qt 4.8, l’astuce est de supprimé du .pro:

    QMAKE_MAC_SDK = /Developer/SDKs/MacOSX10.5.sdk
    QMAKE_MACOSX_DEPLOYMENT_TARGET = 10.5
Je doit faire aussi pour être complet, un contrôle des signaux moteur de copie <-> interface pour les optimisés.

UEFI me voila!

Bonjour, j’ai enfin mon matos EFI (ou UEFI), c’est avant tout pour la chaleur qu’il fait ici (bolivie), mais aussi pour maitrisé l’EFI pour le travail.

Résultat, seul le cd d’ubuntu 12.04 (voir certain moins récent) permette de booter en pur efi, j’ai marqué avec parted la partition de boot en fat32 comme « boot », et j’ai mit les bon fichiers partout, ca marche pas en efi (heureusement ça boot en bios). Comme linux support GPT en mode bios (comme c’est sur mon ancien pc), et en mode EFI, ça lance le boot.

En mode verbose, ça commence à lancé le noyau puis l’écran freeze, pour une raison ou une autre kms sur mon AMD 3650 llano (fusion donc), kms ce lance pas et produit un bug video qui freeze le mode console, lors du passage sur X j’ai un écran corrompu. Il doit avoir un moyen de tout faire marché vu que le livecd de kubuntu 12.04 marche.

Sur le materiel en lui même j’ai noté: Support du mode bios et du boot en mbr. Mise à jour depuis le bios (faut juste indiquer le fichier de bios sur une partition), j’ai pas mon wattmettre pour voir le mode économie d’énergie, et si il change vraiment quelque chose. Le reste des options est assez traditionnel. Je note que pour des fonctionnalité équivalente ou suppérieure, cette carte grace à l’éfi boot largement + rapidement (1s pour arrivé au boot loader), si en plus je peu booter en directe un noyau linux (comme le noyau 3.3 avec l’option efi stub), ca me permet d’étre sur mon bureau en 5s max. 1s bios, 1s noyau + init, 3s services + kde.

Ultracopier application stoppé

Bonjour, l’application ultracopier est stoppé car wine fait crasher gcc, et mes .bat sous windows ne marche pas, donc pas moyen de faire la moindre version automatisé. Coté linux et mac, j’attends toujours un QT 4.8 stable. Je n’est pas non plus beaucoup de temps à consacré à ultracopier ces derniérs temps.

Site d’ultracopier

Bonjour, j’ai commencer à refaire le site d’ultracopier.

J’aurai besoin d’aide sur le remake du site pour mettre un anglais correcte.

Je fait: forum (pour les discutions et repport de bug), wiki (pour les doc et guide), et le site principal (allégé et clarifié).

Bonne fete 2011

Bonjour, bonne fetes de fin d’années. Ultracopier 0.3 est sortie en version alpha, j’ai corrgé pas mal de truc qui m’ont été reporté, j’ai pas encore fait le script d’empacktage automatique.

2012 vas étre une grande année (Qt 5.0, waymand, openGL3 pour les drivers libres, …)

BRULE Herman's RSS Feed
Go to Top