[Adictiz] 2011 montée en charge avec php

Montée en charge avec PHPCas Paf le chien

Présentation

• Stéphane DESSEIN

• Développeur PHP• Administrateur Système.

• Chez Adictiz de septembre 2008 à octobre 2009

• Développeur d’application Facebook indépendant (2009-2011)

• Retour chez Adictiz depuis mars 2011.

Sommaire

• Paf le chien, le concept

• Paf le chien V1 et V2 dans un gestionnaire de contenus

• Paf le chien V3 : Application Facebook dédiée• Application ‘’ExtraLight’’• Intérêt du FBML

• Evolutions de Paf• Nouvelles versions• Jeu de gestion

• Etude d’un cas : Paf Deluxe / Adictiz Framework

• Changements d’architectures serveurs• Multiplication des machines• Vers une virtualisation complète.

Paf le chien - le jeu

Paf le chien V1 : Stratosphère

• Mini plateforme de jeux sur facebook

• Jeu intégré dans gestionnaire de contenu

• 1 opération :• Associé à une marque• 1 ou plusieurs jeux• 1 ou plusieurs cadeaux• Classements (général, amis, etc.. )

• Inscriptions• Op-tins / pubs

• Résultat : 6000 Users / 2 semaines : aucune surcharge.

1 Serveur :Moyenne Gamme

4 CPU / 2 Ghz4 GB Ram500 Go Disk / Raid 1

Paf le chien V2 : Stratosphère devient Paf le chien

• Toujours dans le gestionnaire de contenus

• 1 opération créée• Pas de cadeaux• Classements• Optins/pubs • Etc…

• Résultat : • 400 users simultannées• => Surchage serveur !

Infra identique :

1 Serveur :Moyenne Gamme

4 CPU / 2 Ghz4 GB Ram500 Go Disk / Raid 1

Paf le chien V2 : Analyse

• Gestionnaire de contenu trop lourd ?

• L’état des lieux:

• 25 requêtes SQL à chaque chargement de page

• 10-15 requêtes SQL à chaque partie

• 3-4 appels API Facebook / page• Données utilisateurs (nom/prénom, photo)• Liste d’amis• Autres données… (si ajouté application etc..)

Paf le chien V3 : Application dédiée FBML

Projet PHP très simple :

3 fichiers :

-index.php- homepage- Page des classments

-score.php- Script appelé par le jeu

pour envoyer le score au serveur

- jeu.swf- Le jeux en question

Base de donnée ultra light

2 tables :-Score

- Fbuid- score

-score_log- Fbuid- score,- Date- Ip

Création d’une nouvelle application dédiée


• Application PHP très légère

• Homepage :

• Classements• 2 requêtes SQL • Listing fbuid et score • Comptage pour pagination

• + Appel API facebook pour listing Amis

Chargement Applicationindex.php

Enregistrement scorescore.php

Chargement Jeux flash

Affichage classementclassement.php


• Intérêt énorme du FBML

• Facebook comme proxy


• FBML, balises spéciales interprétés par facebook.• Plus la peine de stocker les informations sur les utilisateurs :• => On stocke uniquement le fbuid

• Exemple : • <fb:name uid=4 /> deviendra : Mark Zuckerberg

• <fb:pic uid=4 /> deviendra :


• Bilan :• Coût :

• 3 développeurs• Durée : 6 h de développement

• Résultat : • 400 connexion simultanés

• 6 000 connexion simultanés

Serveur Surchargé !

Apache/PHPMySQL


• Optimisation / Fine tunning Serveur

• Apache / PHP : • Accepter plus de connexions• Réduction du keep-alive• Accélérateur : eAccelerator.

• MySQL• Paramétrage mémoire

• Gain : • 6 000 connexions => 10 000 connexions

• Serveur surchargé !


• Nouvelle architecture Serveur• Séparation Web et Base de donnée

• Résultat :

12 000 connexions 25 000 connexions.


• Problème de sécurité.

Facebook Servers

12

34 5

6

1 : arrivée sur l’application2-3: requête de Facebook vers nos serveur et vice-versa4 : Facebook a parsé le FBML, la page est rendu à l’utilisateur5 : Jeu flash chargé chez l’utilisateur avec en flashvar, le fbuid6 : Envoi du score directement sur nos serveurs

2 paramètres : Fbuid et score


• Sécurisation via authentification facebook.

Facebook Servers

123

4 5

6

6 : Envoi du score directement sur nos serveurs2 paramètres : clé d’authentification Facebook et score

7 : vérification de la clé d’authentification Facebook8 : réception du Fbuid de façon sécurisée.

7

8


• Résultat :

• Chute de performance • Appel API Facebook : ~ 1 sec

• Process Apache Occupés à rien faire.

• Explosion mémoire serveur.

• Serveur n’acceptant plus de connexion

• Chute d’acceptation de connexion à 15 000 !


• Nouvelle Infrastructure• Load Balancing (IP) sur 2 web frontaux

35 000 Connexions simultannéesServeurs webs chargés (process ‘’inactifs’’)


• Changement d’infrastructure.• Haute disponibilité du jeux

Envoi du score

Facebook Servers


• Résultat Final

• 60 000 Connexions simultannées max

• Plus de 500 Parties jouées / sec

• 200 nouveau joueurs / sec

Evolutions de Paf le Chien

• Pic de trafic passé, Paf le chien évolue !• Multiplication des versions• Gestions d’items / payants / gratuits etc..

Etude de cas : Paf Deluxe / Adictiz Framework

• Paf le Chien, devenu un véritable jeu de gestion.

Adictiz Framework

• Adictiz FrameWork est un outil permettant la distribution de n’importe quel jeu web sur n’importe quel site internet doté d’API

• 2 Enjeux:• Garder la même qualité de service entre 1 et 10 millions d’utilisateur

(temps de réponse, disponibilité)• Mieux connaître nos utilisateurs et leurs besoins (utilisateur unique

sur nos jeux)

Adictiz FrameWork

Jeu 1

Utilisateur

Utilisateur

Utilisateur

Utilisateur

Utilisateur

Utilisateur

Plateforme 1

Plateforme 2

FrameWork

Data

Data

Adictiz FrameWork – Zend Framework

Adi

ctiz

Fra

mew

ork

Adi

ctiz

MySQL

Jeu Flash

UtilisateursRéseaux sociaux

Vues

Controlleurs

Modèles

Abstraction du réseauTraitement des donnéesAbstraction du moteur de données

AMF

Framework Flash


• Contraintes Techniques :

• Stocker/récupérer toutes les informations utilisateurs (iFrame)

• Stocker toutes les transactions (achats d’items)

• Statistiques sur tout les éléments du jeu• Entrées/sorties utilisateurs• Achats/utilisations d’items• Achats de crédits etc..


• Conséquences :

• Enormément de requêtes SQL

• Ratio INSERT/SELECT trop élevé

• Trafic montant progressivement

• => Charge serveur MySQL monte en flèche !


• Optimisation pour alléger le serveur MySQL

• Exploitation des sessions :

Récupération donnés utilisateur Session PHP Fin de Partie

SELECT

INSERT / UPDATE

Jeu Flash Chargé coté Client


• Constat ?

• Serveur MySQL nettement allégé

• Charge mieux équilibrée entre PHP et MySQL


• Constat ?

• Trafic continuant à monter

• => Evolution de l’infrastructure

• Serveur de cache de fichiers statiques

• Module PHP memcache : partage des sessions entre les serveurs

• Module PHP APC : Cache de fichiers / Précompilateur / Cache de sessions Local

Changement d’infrastructure serveur

Base de données

Web / PHP

Web Cache Web Cache

LoadBalancer

LoadBalancer

Web / PHP

SSL (HTTPS)

Memcache

Fonctionnement des modules PHP : Memcache

• Memcache : Sessions PHP gérés sur un seul serveur • Partage des sessions entre plusieurs Serveur WEB• Performance => mémoire• Transparent : (configuré dans php.ini)

Web / PHP

PHP Session

Web / PHP

PHP Session

Web / PHP

PHP Session

Memcache

Fonctionnement des modules PHP : APC

• APC : Cache Opcode / Cache utilisé comme session local• Exemple sans APC :

Fonctionnement des modules PHP : APC

• Avec APC

Résultat :

Serveur PHP exécute 6 fois plus de requêtes.

Infrastructure de demain : Virtualisation

• Full Virtualisé pour évolutivité au maximum• Architecture Serveurs Web• Ajout de Serveur Web/PHP à la demande• Déploiement très rapide.• Sécurité : Snapshots, remonter VM sur autre architechture

Web / PHP Web / PHP Web / PHP

Virtualisation Base de données

Memcache

Infrastructure de demain : Virtualisation

• Architecture Base de données• Complètement virtualisée• 2 serveurs Masters en réplication Master/Master• Multiplication des slaves en cas de besoin

SQL Master 1R/W

SQL Master 2R/W

SQL Slaves – Read Only

L’avenir ? Le Cloud ?

• Gestion des montés en charge en Cloud ?• PHP supporté par de nombreuses plateformes

Contacts

Charles [email protected]

Stéphane DesseinDé[email protected] EuraTechnologies

165, avenue de Bretagne59000 Lille – FranceT/ +33 (0) 3 66 72 09 99E/ [email protected]

[Adictiz] 2011 montée en charge avec php

Documents

Transcript of [Adictiz] 2011 montée en charge avec php