+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 3 PremièrePremière 123 DernièreDernière
  1. #21
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 724
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 724
    Points : 29 576
    Points
    29 576

    Par défaut

    Ce débat n'a pas lieu d'être, car il ne s'agit pas du tout d'améliorer les performances de ZF sur une machine en Développement mais plutôt en Production...

    de ne pas trop faire dévier le sujet.

  2. #22
    Membre expérimenté
    Avatar de Alexandre T
    Profil pro
    Inscrit en
    mai 2002
    Messages
    1 027
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : mai 2002
    Messages : 1 027
    Points : 1 588
    Points
    1 588

    Par défaut

    Pour revenir sur le FrameWork en lui même, il faut quand même reconnaître qu'il est lourd en mode MVC. Mais cela est du au modèle MVC en lui-même. J'ai testé Symphony hier soir, CakePHP et ZF en refaisant des tests. Déjà l'optimisation du BootStrap est essentielle. J'ai trouvé CakePHP plus performant, Symphony aussi.

    Mais à mon goût, Symphony n'a pas la fluidité de ZendFramework ni son adaptabilité. Je le connais mal, donc veuillez m'excuser si je raconte des sornettes, mais je trouve le modèle plus figé.

    CakePHP est moins utilisé, la communauté est moins forte, et cela a beaucoup d'importance à mes yeux. Il est plus rapide, mais à première vue, il est moins abouti.

    J'hésite sur bien des solutions. Full ZF ou Cake+ZF ou Symphony+ZF . Je pense partir sur la première solution car en analysant le code source des applications, on remarque déjà que Zend développe pour être rapide. Il y a bien des exemples en ce sens. Le plus visible est la connexion paresseuse. Si dans le BootStrap, vous ne faites pas l'erreur d'appeler la connexion directement, alors les performances augmente Par exemple, dans un forum, toutes les pages de messages (Votre message a bien été enregistré, cliquez ici, etc..., etc..., ) n'établiront pas de connexion.

    Il est évident qu'un hello World ira toujours plus vite avec un echo qu'avec un FrameWork !
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    <?php echo 'hello World'; ?>
    Je ne veux pas partir en Troll, mais ca veut dire quoi 3000 acces in the same time. Cet angliscisme me fait penser à ses commerciaux de SSII qui viennent me vendre leur boite à grand coup de "Business Intelligence" et de "IQ" ou de "Benchmark goals". (Pour information : Business Intelligence = espionnage commercial).

    Je dis cela car votre serveur pour répondre à 3000 requêtes HTTP par seconde, il est clairement sous-dimensionné et sa description ne me fait pas du tout pensé à un serveur de production, mais à un puissant PC de bureautique (mais pas de développement) connecté à un serveur de fichier. Déjà pour les machines de développement nous ne choisissons pas de processeur monocoeur ; surtout avec Apache, un serveur web multithread, ce serait dommage de payer si cher un P4 3Ghz pour si peu. Éloigner les disques entraine une perte de performance à moins de sécuriser et de blinder (au sens de protection contre les interférences) le réseau et d'établir tous les accès disque en UDP et non pas en TCP.

    Ce que je veux dire n'apparait pas constructif, et semble être une méchante critique sans fondements. Je suis embêté ce n'est pas ce que je veux. Je reformule alors : Pour optimiser les performances, il faut agir sur plusieurs facteurs :
    La connexion au réseau Internet du serveur (Fibre optique ou plusieurs lignes dédiés
    La connexion au serveur de base de données (une carte réseau dédié avec un accès direct, en utilisant pourquoi pas un câble direct entre les deux machines)
    Le serveur en lui même (multiproc, multicore, voire en cluster mais bon pour 3500r/s c'est pas encore nécessaire)
    Le système d'exploitation et là je pars sur du Linux (Debian et non pas Ubuntu, ni même Ubuntu server) voire du VMWare ESX dont les performances m'ont surprise malgré la couche supplémentaire qu'il génrère !
    Le serveur Web, Apache et sa configuration est importante (je conseil l'excellent livre Apache au collection Oreilly qui vous apprends à l'utiliser en commençant avec un fichier de configuration vierge !)
    Le langage de traitement PHP (à optimiser aussi) les purs et durs le recompile (là ca dépasse de loin mes compétences)
    le système de cache !
    la modélisation de la base de données est super importante.
    Et enfin la façon de développer.

    D'expérience, quand j'auditais des entreprises, voilà comment je fonctionnais :
    1- La BDD, c'est là que je me focalisais car j'arrivais en deux trois jours à multiplier les performances par 1000 (lisez les derniers cours de SQLPro, il y a des exemples flingrants et je parle pas du consultant beta qui multiplie les index )
    2- Je me porte sur le réseau et sa connexion à la BDD
    3- Sur la façon de développer, là, au contraire, il ne faut pas privilégier les performances. Il faut privilégier la maintenabilité du code ! Une fois le code fonctionnel, alors oui, on peut optimiser les quelques actions qui rament. Car cela coûte bien plus cher au client, comme à la SSII et à un éditeur de logiciel, de maintenir une application au code obscur que de maintenir un code hiérarchisé (et donc un développement via un framework)
    4- Sur le serveur et sa connexion au serveur de fichier (franchement évitez de déporter les fichiers pour une appli web).
    5- Sur le serveur en lui-même

    Mais généralement, les performances gagnées par les points 1, 2 (parfois 4) satisfaisaient mes clients. Optimiser le point 3 quand on n'utilise pas un framework c'est très long, trop long au tarif journalier d'un auditeur. La solution consiste à bien paramétrer le cache, mais là je passais le relai à un regretté collègue extrêmement compétent.

    En clair, l'utilisation d'un FrameWork fait gagner du temps de développement et du temps de maintenabilité au prix des performances. Ces performances sont vite comblée par un serveur plus puissant. Et même un serveur 10.000 euros plus cher est amorti dès qu'il vous fait gagner seulement 20 jours/hommes en développement.
    Alexandre T.

    PHP5/MySQL5 Codes prêts à l'emploi
    30 projets avec codes sources complets pour créer diaporamas photos, chat, arbre généalogique, statistiques de visites, création de graphiques, moteur de recherche, Sudoku etc...

    Mes articles

  3. #23
    Rédacteur
    Avatar de doctorrock
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    mai 2006
    Messages
    603
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2006
    Messages : 603
    Points : 2 837
    Points
    2 837

    Par défaut

    Je confirme, il faut absolument optimiser la BDD, c'est à dire la connexion physique et l'utilisation logique (nombre de connexions maxi, nombre de threads qui traitent ça ).

    Coté MySQL, il existe des caches de requêtes, des hooks sur les requêtes les moins performantes, différents types d'index et de moteurs de stockages ( très importants ), sans compter le proxy et tout le tralala

    Coté applicatif, Zend_Db_Profiler peut être utlisé pour mettre en place un cache de requêtes ou de résultats (avec Zend_Cache)
    .: Expert contributeur certifié PHP/ZF :.
    Mes articles - Twitter - GitHub

  4. #24
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2007
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : mai 2007
    Messages : 13
    Points : 13
    Points
    13

    Par défaut

    Nous avons, dans le cadre d'un projet, effectuer des tests de performances et des benchmarks sur Zend Framework.

    Je me permets de vous publier l'article que j'ai rédigé, dont la source sont ces tests.

    Il est apparu que ZF était lourd, très lourd, à telle point que sur une application non optimisée et un serveur pas optimisé, il devenait le goulet d'étranglement à la place de la base de données. Ce fut un constat assez étonnant.

    Toutefois après pas mal de modification sur l'infrastructure, on a pu trouver une configuration machine et applicative qui tiennent la route même sur des sites nécessitants de supporter une charge importante.

    Je me permets donc de poster l'adresse vers cet article en espérant que cela pourra vous intéressé et je réponds volontier à vos remarques et questions :

    http://www.wowww.ch/index.php?post/2...-et-benchmarks

  5. #25
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 724
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 724
    Points : 29 576
    Points
    29 576

    Par défaut

    @Dvyne : Je ne crois pas avoir vu le code source de l'application utilisée pour le stress test, est-il possible de le diffuser ? Cela me semble fondamental pour la validité de l'article (qui serait édifiant si ce code source était rendu public).

  6. #26
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2007
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : mai 2007
    Messages : 13
    Points : 13
    Points
    13

    Par défaut

    Ca va malheureusement pas être possible du tout. C'est un projet client, pas du tout OpenSource ou quoi que ce soit de ce genre.

    Toutefois, sans publier le code, je peux ajouter un chapitre pour décrire l'applications ou alors y ajouter une trace modules Zend et fonction php utilisées. Genre un profiling XDebug...

    Je vais voir ce qui est possible de faire.

    Toutefois, je pense pas qu'il faut se focaliser sur le code. L'optimisation de ce dernier n'apportera pas les 25, 50 ou 100% d'amélioration qui ont été obtenus via les modifications serveur réalisées.

    Je qualifie l'optimisation du code de moyenne et décrit l'application comme étant de type backoffice. Mais l'optimisation côté serveur, sur une application plus lourde, conduira aux mêmes conclusions.

    Bien entendu, je comprends l'intérêt de savoir ce qui est "plus lourd" que l'application utilisée afin de déterminer précisément le nombre de connexions concurrentes nécessaire sur un nouveau projet.

    Je vais voir si un profiling XDebug suffit à déterminer ça.

  7. #27
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    février 2004
    Messages
    13 724
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : février 2004
    Messages : 13 724
    Points : 29 576
    Points
    29 576

    Par défaut

    Je crois que tu as répondu à l'une de mes questions : il y a des accès base de données, donc des échanges TCP/IP. Est-ce que tu as mesuré ces échanges, sais-tu quel impact ils ont sur les résultats du benchmark ?

  8. #28
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 040
    Points
    2 040

    Par défaut

    Citation Envoyé par Yogui Voir le message
    Je crois que tu as répondu à l'une de mes questions : il y a des accès base de données, donc des échanges TCP/IP. Est-ce que tu as mesuré ces échanges, sais-tu quel impact ils ont sur les résultats du benchmark ?
    J'ai un doute :

    Citation Envoyé par Tiré de l'article, à la fin
    Une remarque importante toute fois, dès 200 connexions parallèles, le besoin de sortir MySQL du serveur se fait sentir. Il est donc possible que ces résultats soient encore améliorés si le serveur sert uniquement les requêtes web.

  9. #29
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2007
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : mai 2007
    Messages : 13
    Points : 13
    Points
    13

    Par défaut

    MySQL se trouve effectivement sur le serveur cible. Donc pas d'échange TCP/IP bien que je ne sache pas réellement comment "localhost" est géré dans ces cas là. Toutefois, je vois mal comment les accès TCP/IP peuvent interférer de manière marquée sur les benchmarks.

    Mais oui, l'application a des accès DB, des contrôles de droits, la récupération de données dans la dite DB, du traitement de données pour l'affichage, etc... Il utilise Zend_View, Z_Layout, Z_Date, Z_Pagination, des plugins, des helpers, Z_Db, Z_Table, etc, etc...

  10. #30
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 040
    Points
    2 040

    Par défaut

    Citation Envoyé par Dvyne Voir le message
    MySQL se trouve effectivement sur le serveur cible. Donc pas d'échange TCP/IP bien que je ne sache pas réellement comment "localhost" est géré dans ces cas là. Toutefois, je vois mal comment les accès TCP/IP peuvent interférer de manière marquée sur les benchmarks.
    C'est une bonne question... On peut supposer que de facto les temps de réponses sont augmentés, de manière linéaire.
    Après il faudrait pouvoir déterminer si cette augmentation évolue en fonction du nombre de clients ( => de requetes), et comment elle évoluerait.
    Ou si cela ne change pas vraiment et reste stable.

    J'imagine que cette évolution dépendrait du type de lien entre les machines, à savoir le débit, la qualité du matériel ect.
    Mais il y à sûrement d'autres variables ?

  11. #31
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2007
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : mai 2007
    Messages : 13
    Points : 13
    Points
    13

    Par défaut

    Mais on s'éloigne du sujet. Ces paramètres sont indépendants du framework utilisés.

  12. #32
    Membre expérimenté

    Profil pro
    Inscrit en
    janvier 2005
    Messages
    1 278
    Détails du profil
    Informations personnelles :
    Localisation : France, Gironde (Aquitaine)

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 278
    Points : 1 640
    Points
    1 640

    Par défaut

    Citation Envoyé par Dvyne Voir le message
    Il utilise Zend_View, Z_Layout, Z_Date, Z_Pagination, des plugins, des helpers, Z_Db, Z_Table, etc, etc...
    N'oublions pas que Zend_Date est un très gros consommateur de ressources.

  13. #33
    Membre à l'essai
    Profil pro
    Inscrit en
    mai 2007
    Messages
    13
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations forums :
    Inscription : mai 2007
    Messages : 13
    Points : 13
    Points
    13

    Par défaut

    Zend_Date, en fait, consomme beaucoup de mémoire tout comme Zend_Locale, Zend_Currency, etc... car elles sont visiblement très mal optimisées à ce niveau. Toutes les "locales" sont chargées en mémoire alors que dans la plupart des cas on en utilisera qu'une. Mais au final, ça a très peu d'impact sur la consommation processeur qui est le plus gros problème du ZF.

    Bien entendu, on évitera de faire des nouvelles instances de ces classes en boucle. Et si nécessaire, on préfèrera plutôt la bonnes vieilles méthodes mktime(), date(), strtotime(), etc...

    En fait, j'ai l'impression, mais ça reste une impression, que c'est la gestion des classes de PHP5 qui est consommatrice et particulièrement l'utilisation des méthodes magiques telle que __get et __set.

    Sur une application standard on peut voir le nombre des appels à ces méthodes grimper en flèche. Par exemple, l'utilisation de Zend_Config_Ini et des branchements récursifs tel que $config->maCategorie->maVariable génère rapidement des centaines d'appels à ces méthodes magiques.

    Une telle analyse sur une application peut être réalisée très facilement à l'aide d'un profil XDebug. On y découvrira quelques surprises de taille.

    Peut être vaut-il mieux utiliser le bon vieux tableau, si ça peut sauver 5 à 10% des ressources ?

    Pour faire une petite parenthèse, CodeIgniter est codé entièrement en PHP4. D'où le gain de performances ? J'en sais rien...

  14. #34
    Nouveau Candidat au Club
    Profil pro
    Inscrit en
    février 2010
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2010
    Messages : 1
    Points : 1
    Points
    1

    Par défaut

    Pour ma part les performances de zf ont étés le seul critère de reproche que j'ai jamais pu lui faire, ce qui ne m'a pas empêcher de le déployer pour plusieurs sites internet mais jamais à fort sollicitation.


    ___________
    Mon site : Serrurier

  15. #35
    Membre chevronné
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2007
    Messages : 1 448
    Points : 2 040
    Points
    2 040

    Par défaut

    Plus simplement, a défaut d'être performant en DEV. Quels stratégie de scaling, et d'optimisation sont disponible avec ZF pour la PROD ?

    Je pense bien qu'il y à quelques API pour discuter avec memcache apc ect. Mais quid de l'intégration avec les composants du fw ?
    Est ce compliqué à implémenter ?
    Est ce magique ?

    Enfin, sur l'autoloading, c'est un plaie en php.
    Mais c'est le côté script qui entre en contradiction avec l'aspect fw amha.
    Par rapport à cela il est imaginable de réaliser des optimisations très très efficaces, dont les développeurs ZF sont forts capable je n'en doute pas.

    Cependant, sont ils prêt à intégrer cette différenciation (DEV / PROD) et les optimisations / agencements qui vont bien dans leurs fw ? En ont ils simplement envie ?

    Ou bien, nous laisseront ils dans des situations comme celle de FB qui en vient (pour un problème terriblement plus crucial, et compliqué, certes) à compiler son application pour la mise en PRODUCTION.

  16. #36
    Membre à l'essai
    Inscrit en
    février 2008
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 13
    Points : 15
    Points
    15

    Par défaut

    Bonjour,

    J'ai fait personnellement une librairie basée sur Zend Framework pour accélerer le développement de mes applications et j'ai donc naturellement vérifié ce que ça donnait en perf.

    La librairie utilise un cache en APC (via Zend_Cache) elle même pour ne pas recharger les opérations les plus couteuses (chargement des fichiers de configuration, chargement des traductions, etc.). Quand APC est désactivé le cache utilisé est du type File dans Zend, ce qui bien sur pénalise doublement les performances

    Processeurs : PC Intel Dual-Core 2,2Ghz avec 2M de cache
    Mémoire : 3Go
    OS : Debian

    J'ai testé avec la commande suivante : ab -n 100 -c 10 -k

    Avec le module APC activé et cache APC : 51 requêtes / secondes
    Avec le module APC activé et cache FILE : 44 requêtes / secondes
    Avec le module APC activé et sans cache : 42 requêtes / secondes
    Sans le module APC avec le cache FILE : 19 requêtes par secondes
    Sans le module APC avec le sans cache : 17 requêtes par secondes

    Il s'agit de chiffre sans base de données

  17. #37
    Membre à l'essai
    Inscrit en
    février 2008
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : février 2008
    Messages : 13
    Points : 15
    Points
    15

    Par défaut

    Bon à priori en mettant optionnel certains paramètres et en ajoutant des optimisations à droit à gauche, j'ai bien monté.

    Zend Framework out of the box : 214 requêtes / secondes
    Ma surcouche : 167 requêtes / secondes

    Si on réactive la sécurité (via Zend_Acl sur les controller) les traductions et Smarty : 125 requêtes / secondes

    Smarty a lui tout seul a un coût très élevé je trouve.

  18. #38
    Membre à l'essai
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    25
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 25
    Points : 14
    Points
    14

    Par défaut

    Bonjour,
    puisque je vois que vous parlez de performance dans ce topic, je me permet de vous poser cette question :
    Dans la documentation du Zend Framework, il est précisé que "Les enveloppes de flux de vue dégradent les performances".

    Lien vers la page de documentation

    Pourriez-vous m'expliquez en quoi les enveloppes de flux dégradent les performances ? (Pour ma part, mis à part les "replace" fait par le biais d'expression régulière, je ne vois pas ce qui pourrait dégrader les performances, mais je n'ai pas idée non plus du coût des preg_replace() utilisé)

    J'ai dans l'idée d'utiliser cette enveloppe de flux pour utiliser les short_open_tag quelque soit l'environnement. Mais si la dégradation des performances est trop importante, je préfère laisser tomber. Auriez-vous une idée de l'ordre de grandeur avec laquelle les performances sont affectées ?

    Par avance merci pour votre réponse.

  19. #39
    Rédacteur

    Avatar de gege2061
    Femme Profil pro
    Administrateur de base de données
    Inscrit en
    juin 2004
    Messages
    5 842
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 33
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : juin 2004
    Messages : 5 842
    Points : 11 314
    Points
    11 314

    Par défaut

    Bonjour,

    Citation Envoyé par doudou34 Voir le message
    Pourriez-vous m'expliquez en quoi les enveloppes de flux dégradent les performances ? (Pour ma part, mis à part les "replace" fait par le biais d'expression régulière, je ne vois pas ce qui pourrait dégrader les performances, mais je n'ai pas idée non plus du coût des preg_replace() utilisé)
    C'est simple :

    Sans enveloppe de flux :
    • Inclusion du fichier


    Avec enveloppe de flux :
    • Chargement complet du fichier en mémoire,
    • Remplacement des balises <?=,
    • Remplacement des balises <?,
    • Inclusion du contenu


    Le contenu fichier est parcouru trois fois dans son intégralité. A tester, sur des petits fichiers de template ça ne doit pas être gênant.

  20. #40
    Membre à l'essai
    Profil pro
    Inscrit en
    janvier 2005
    Messages
    25
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2005
    Messages : 25
    Points : 14
    Points
    14

    Par défaut

    Ok, merci, c'est bien ce que je me doutais...
    Au delà la performance, le gros risque à utiliser cette fonctionnalité est d'éclater la mémoire du serveur.

    Qu'est-il conseiller au sujet des short_open_tag ?
    Mon hébergeur les autorise, mais étant perfectionniste, j'ai pu lire qu'il était déconseillé de ne pas les utiliser pour ne pas "casser" la portabilité d'un site. Apparemment tout les hébergeurs n'activeraient pas les short_open_tag.
    Qu'en pensez vous ?
    (Désolez d'enchainer sur cette question qui du coup est un peu hors sujet)

Discussions similaires

  1. Les frameworks de persistance (ORM) sont-ils dangereux pour les performances ?
    Par SQLpro dans le forum Débats sur le développement - Le Best Of
    Réponses: 205
    Dernier message: 04/02/2017, 16h43
  2. Réponses: 13
    Dernier message: 07/06/2012, 19h09
  3. Réponses: 16
    Dernier message: 04/07/2008, 08h54
  4. Framework : performance & protection
    Par kinhelios dans le forum Visual C++
    Réponses: 1
    Dernier message: 12/07/2006, 23h40

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo