Optimisation des sites web Kohana pour la vitesse et Evolutivité

StackOverflow https://stackoverflow.com/questions/1260134

Question

Un site que je construit avec Kohana a claqué avec une énorme quantité de trafic hier, me faisant prendre un peu de recul et d'évaluer certains de la conception. Je suis curieux de savoir ce que sont des techniques standard pour l'optimisation des applications basées sur Kohana?

Je suis intéressé par l'analyse comparative aussi bien. Ai-je besoin de Benchmark::start() d'installation et Benchmark::stop() pour chaque contrôleur méthode afin de voir les délais d'exécution pour toutes les pages, ou suis-je en mesure d'appliquer l'analyse comparative à l'échelle mondiale et rapidement?

Je vais utiliser la bibliothèque cache plus dans le temps à venir, mais je suis ouvert à d'autres suggestions que je suis sûr qu'il ya beaucoup je peux le faire, je suis tout simplement pas au courant pour le moment.

Était-ce utile?

La solution

Ce que je vais dire dans cette réponse est non spécifique à Kohana, et peut probablement demander à un bon nombre de projets PHP.

Voici quelques points qui me viennent à l'esprit quand on parle de performance, d'évolutivité, PHP, ...
Je l'ai utilisé beaucoup de ces idées tout en travaillant sur plusieurs projets - et ils aidé; ils pourraient probablement aider ici aussi.


Tout d'abord, en matière de performances, il y a de nombreux aspects / questions qui sont à considérer :

  • configuration du serveur (à la fois Apache, PHP, MySQL, autres daemons possibles, et le système) ; vous pourriez obtenir plus d'aide à ce sujet sur ServerFault , je suppose,
  • code PHP,
  • requêtes de base de données,
  • Utilisation ou non votre serveur web?
  • Pouvez-vous utiliser tout type de mécanisme de mise en cache? Ou avez-vous besoin toujours plus que jusqu'à ce jour les données sur le site?

L'utilisation d'un proxy inverse

La première chose qui pourrait être vraiment utile utilise un proxy inverse , comme vernis , en face de votre serveur Web: laisser cache autant de choses que possible , de sorte que seules les demandes qui ont vraiment besoin de calculs PHP / MySQL (et , bien sûr, d'autres demandes, lorsqu'ils ne sont pas dans le cache du proxy) rendre à Apache / PHP / MySQL.

  • Tout d'abord, votre CSS / Javascript / Images - bien, tout ce qui est statique - probablement pas besoin d'être toujours servi par Apache
    • Donc, vous pouvez avoir le cache proxy inverse tous les.
    • Au service de ces fichiers statiques est pas grand pour Apache, mais moins il doit travailler pour ceux, plus il sera en mesure de le faire avec PHP.
    • Rappelez-vous:. Apache ne peut serveur un fini,, le nombre de demandes limitées à la fois
  • Ensuite, ont le proxy inverse servent autant de PHP pages que possible du cache: il y a probablement quelques pages qui ne changent pas souvent , et pourrait être servi de cache. Au lieu d'utiliser une cache en PHP, pourquoi ne pas laisser une autre, plus léger, serveur servent les (les chercher à partir du serveur PHP de temps en temps, ils sont toujours presque à jour) ?
    • Par exemple, si vous avez des flux RSS (Nous avons généralement tendance à oublier ceux qui, en essayant d'optimiser pour les performances) qui sont demandés très souvent , les avoir dans cache pendant deux ou trois minutes pourrait sauver des centaines / milliers de demande d'Apache + PHP + MySQL!
    • Même chose pour les pages les plus visitées de votre site, si elles ne changent pas pendant au moins deux minutes (exemple: page d'accueil) , alors, pas besoin de CPU déchets re-génération les chaque fois qu'un utilisateur en fait la demande.
  • Peut-être il y a une différence entre les pages servi pour les utilisateurs anonymes (la même page pour tous les utilisateurs anonymes) et pages servi pour les utilisateurs identifiés ( « Bonjour Mr X, vous avez de nouveaux messages » , par exemple) ?
    • Si oui, vous pouvez probablement configurer le proxy inverse pour mettre en cache la page qui est servi pour les utilisateurs anonymes (basé sur un cookie, comme le cookie de session, généralement)
    • Il va dire que Apache + PHP a moins à traiter. Seuls les utilisateurs identifiés - qui pourrait être seulement une petite partie de vos utilisateurs

A propos de en utilisant un reverse-proxy comme cache , pour une application PHP, vous pouvez, par exemple, jetez un oeil à résultats de référence Afficher 400% -700% d'augmentation des capacités de serveur avec APC et Squid Cache .
(Eh oui, ils utilisent Squid, et je parle de vernis - c'est juste une autre possibilité ^^ Varnish being plus récente, mais plus dédié à la mise en cache)

Si vous le faites assez bien, et réussi à arrêter re-générer trop de pages encore et encore, vous aurez peut-être même pas d'optimiser tout votre code ;-)
au moins, peut-être pas dans une sorte de ruée vers ... Et il est toujours préférable d'effectuer des optimisations lorsque vous n'êtes pas en trop presure ...


En tant que sidenote: vous dites dans l'OP:

  

Un site que je construit avec Kohana a été claqué avec   une énorme quantité de trafic hier,

Ceci est le genre de situation soudaine où un reverse-proxy peut littéralement sauver la journée , si votre site peut traiter de ne pas être à jour par la seconde:

  • l'installer, le configurer, laissez toujours - tous les jours normaux - run:
    • Configurer pour garder pas les pages PHP dans le cache; ou seulement pour une courte durée; De cette façon, vous avez toujours des données à jour affichées
  • Et, le jour où vous prenez un effet Slashdot ou digg:
    • Configurer le proxy inverse pour conserver les pages PHP dans le cache; ou pour une plus longue période de temps; peut-être vos pages ne seront pas à jour par la seconde, mais il permettra à votre site Web pour survivre digg effet!

A propos de cela, Comment puis-je détecter et survivre étant « Slashdot »? peut être une lecture intéressante.

Du côté des choses PHP:

Tout d'abord: utilisez-vous un version récente de PHP ? Il y a régulièrement des améliorations de la vitesse, avec les nouvelles versions ;-)
Par exemple, jetez un oeil à Indice de référence des succursales PHP 3.0 à 5.3-CVS .

Notez que les performances est une assez bonne raison d'utiliser PHP 5.3 ( Je l'ai fait quelques points de référence (en français) , et les résultats sont excellents) ...
Une autre bonne raison étant, bien sûr, que PHP 5.2 a atteint sa fin de vie, et il est plus maintenu!

Utilisez-vous cache opcode?

  • Je pense à APC - Alternative PHP Cache , par exemple ( PECL , manuel) , qui est la solution I » ve vu le plus utilisé - et qui est utilisé sur tous les serveurs sur lesquels j'ai travaillé.
  • Il peut vraiment réduire la charge CPU d'un serveur beaucoup, dans certains cas, (je l'ai vu la charge CPU sur certains serveurs vont de 80% à 40%, tout en installant APC et l'activer est opcode fonctionnalité -cache!)
  • Fondamentalement, l'exécution d'un script PHP va en deux étapes:
    • Compilation de la source de code PHP pour opcodes (sorte d'équivalent de bytecode JAVA)
    • L'exécution de ces opcodes
    • APC conserve ceux en mémoire, donc il y a moins de travail à faire à chaque fois un script PHP / fichier est exécuté:. Seulement chercher les opcodes de RAM, et de les exécuter
  • Vous pourriez avoir besoin de jeter un oeil à options de configuration , par la voie
    • il y a un peu de ceux-ci, et certains peuvent avoir un grand impact à la fois sur la vitesse / charge CPU / facilité d'utilisation pour vous
    • Par exemple, la désactivation [apc.stat](https://php.net/manual/en/apc.configuration.php#ini.apc.stat) peut être bon pour le système de charge; mais cela signifie des modifications apportées aux fichiers PHP ne seront pas prendre en compte, sauf si vous rincer l'ensemble opcode-cache; à ce sujet, pour plus de détails, voir par exemple stat () Ou non stat ()

Utiliser le cache pour les données

Autant que possible, il est préférable de éviter de faire la même chose et encore .

La principale chose que je pense à est, bien sûr, des requêtes SQL: plusieurs de vos pages ne probablement les mêmes requêtes, et les résultats de certains d'entre eux est sans doute presque toujours les mêmes ... Ce qui signifie que beaucoup de < em> « inutiles » requêtes faites à la base de données, qui doit passer du temps au service des mêmes données et encore.
Bien sûr, cela est vrai pour d'autres choses, comme des appels de services Web, l'extraction des informations provenant d'autres sites, calculs lourds, ...

Il pourrait être très intéressant pour vous d'identifier:

  • Quelles requêtes sont exécutées beaucoup de fois, revenant toujours les mêmes données
  • Quelles autres (lourd) Les calculs sont effectués beaucoup de temps, revenant toujours le même résultat

Et stocker ces données / résultats dans une sorte de cache, de sorte qu'ils sont plus faciles à obtenir - plus rapide - et vous ne devez pas aller à votre serveur SQL pour « rien ».

Grands mécanismes de mise en cache sont, par exemple:

  • APC : en plus de l'opcode-cache que je parlais tout à l'heure, il vous permet de stocker des données en mémoire,
  • et / ou memcached ( voir aussi ) , ce qui est très utile si vous avez littéralement beaucoup les données et / ou sont en utilisant plusieurs serveurs , comme il est distribué.
  • bien sûr, vous pouvez penser à des fichiers; et probablement beaucoup d'autres idées.

Je suis assez sûr que votre cadre est livré avec des choses liées à cache; vous savez probablement déjà que, comme vous le dites « je vais utiliser la bibliothèque cache plus dans le temps à venir » dans l'OP; -)

Profilage

Maintenant, une bonne chose à faire serait d'utiliser le Xdebug extension profil de votre application : elle permet souvent de trouver quelques faibles taches assez facilement - au moins, s'il y a une fonction qui prend beaucoup de temps

.

sont programmés de façon , il génère des fichiers de profilage qui peuvent être analysés avec des outils graphiques, tels que:

  • KCachegrind : mon préféré, mais ne fonctionne que sous Linux / KDE
  • Wincachegrind pour les fenêtres; il fait un peu moins de choses que KCacheGrind, malheureusement -. il ne montre pas callgraphs, généralement
  • Webgrind qui fonctionne sur un serveur web PHP, fonctionne partout - -., mais a probablement moins de fonctionnalités

Par exemple, voici des captures d'écran d'un couple de KCacheGrind:


(source: pascal-martin.fr )

(source: pascal-martin.fr )

(BTW, le graphe d'appels présenté sur la seconde capture d'écran est généralement quelque chose ne WinCacheGrind ni Webgrind peut faire, si je me souviens bien ^^)


(Merci pour le commentaire @Mikushi) Une autre possibilité que je ne l'ai pas beaucoup utilisé est le xhprof extension:. il contribue également à profilage, peut générer callgraphs - mais est plus léger que Xdebug, ce qui signifie que vous devriez être en mesure de l'installer sur un serveur de production

Vous devriez pouvoir l'utiliser alonside XHGui , qui sera aider à la visualisation des données.

Du côté SQL des choses:

Maintenant que nous avons parlé un peu de PHP, notez qu'il est plus que possible que votre goulot d'étranglement n'est pas le PHP côté des choses , mais la base de données un ...

Au moins deux ou trois choses, ici:

Pourtant, les deux choses les plus importantes sont:

  • Ne pas aller à la DB si vous n'avez pas besoin: cache autant que possible
  • Lorsque vous devez aller à la DB, utilisez des requêtes efficaces: les indices d'utilisation; et le profil!

Et maintenant?

Si vous lisez encore, quoi d'autre pourrait être optimisé?

Eh bien, il y a encore place pour des améliorations ... Un couple d'idées architecture orientée-pourrait être:

  • Passer à une architecture n-tier:
    • Placez MySQL sur un autre serveur (2 niveaux: un pour PHP, l'autre pour MySQL)
    • Utiliser plusieurs serveurs PHP (et équilibrer la charge des utilisateurs entre les)
    • Utilisez une autre machine pour les fichiers statiques, avec un serveur web léger, comme:
    • Utiliser plusieurs serveurs pour MySQL, plusieurs serveurs de PHP, et plusieurs proxies en inverse devant les
    • Bien sûr: installer nginx , qui est censé être grand quand il s'agit de sites PHP et haut volume; Je ne l'ai jamais utilisé moi-même, mais vous pouvez trouver des articles intéressants à ce sujet sur le net;

Eh bien, peut-être certaines de ces idées sont un peu exagéré dans votre situation ^^
Mais, encore ... Pourquoi ne pas étudier un peu, juste au cas où? ; -)

Qu'en est-Kohana?

Votre question initiale était d'optimiser une application qui utilise Kohana ... Eh bien, je l'ai posté quelques idées qui sont vraies pour toute application PHP ... Ce qui signifie qu'elles sont vraies pour Kohana trop ;-)
(Même si ce ne lui est spécifique ^^)

J'ai dit: cache d'utilisation; Kohana semble soutenir certains trucs de mise en cache (Vous avez parlé de vous-même, donc rien de nouveau ici ...)
S'il y a quelque chose qui peut être fait rapidement, essayer; -)

J'ai aussi dit que vous ne devriez pas faire tout ce qui est pas nécessaire; est-il quelque chose activé par défaut dans Kohana que vous n'avez pas besoin?
Surfer sur le net, il semble qu'il y ait au moins quelque chose sur le filtrage XSS; avez besoin que vous?

Pourtant, voici quelques liens qui pourraient être utiles:

Conclusion?

Et, pour conclure, une pensée simple:

  • Combien cela va-t-il coûter à votre entreprise de vous payer 5 jours? - étant donné qu'il est un laps de temps raisonnable pour faire de grandes optimisations
  • Combien cela va-t-il coûter votre entreprise à acheter (pour payer?) un second serveur, et son entretien?
  • Que faire si vous avez à plus grande échelle?
    • Combien ça coûte de passer 10 jours? plus? l'optimisation de chaque bit possible de votre application?
    • Et combien pour un couple plusieurs serveurs?

Je ne dis pas que vous ne devriez pas optimiser: vous devriez certainement!
Mais go pour l'optimisation « rapide » que vous obtiendrez de grandes récompenses d'abord: en utilisant une cache d'opcode peut vous aider à obtenir entre 10 et 50 pour cent de votre charge CPU du serveur ... Et il faut seulement quelques minutes pour mettre en place ;-) de l'autre côté, les dépenses 3 jours pour 2 pour cent ...

Oh, et, d'ailleurs: avant de faire quoi que ce soit: mettre des trucs de surveillance en place , vous savez quelles améliorations ont été apportées, et comment!
Sans surveillance, vous aurez aucune idée de l'effet de ce que vous avez fait ... Même si elle est une véritable optimisation ou non!

Par exemple, vous pouvez utiliser quelque chose comme RRDtool + < strong> cactus .
Et montrant votre patron quelques beaux graphismes avec une baisse CPU de charge de 40% est toujours grande, -)


Quoi qu'il en soit, et vraiment conclUde: amuser
(Oui, est amusant optimalisation!)
(Ergh, je ne pensais pas que je voulais écrire beaucoup ... L'espoir au moins certaines parties de ce sont utiles ... Et je ne faut pas oublier cette réponse: peut-être utile d'autres fois ... )

Autres conseils

Code de profil avec XDebug .

Utilisez beaucoup de mise en cache. Si vos pages sont relativement statiques inverse, alors proxy pourrait être la meilleure façon de le faire.

Kohana est hors de la boîte très très rapide, à l'exception de l'utilisation d'objets de base de données. Pour citer Zombor « Vous pouvez réduire l'utilisation de la mémoire en veillant à ce que vous utilisez l'objet de résultat de base de données au lieu de tableaux de résultats. » Cela fait une différence de performance HUGEE sur un site qui est claqué. Non seulement il ne se sert plus de mémoire, il ralentit l'exécution des scripts.

En outre - vous devez utiliser la mise en cache. Je préfère memcache et l'utiliser dans mes modèles comme ceci: 

public function get($e_id)
{
    $event_data = $this->cache->get('event_get_'.$e_id.Kohana::config('config.site_domain'));

    if ($event_data === NULL)
    {
        $this->db_slave
            ->select('e_id,e_name')
            ->from('Events')
            ->where('e_id', $e_id);

        $result = $this->db_slave->get();
        $event_data = ($result->count() ==1)? $result->current() : FALSE;

        $this->cache->set('event_get_'.$e_id.Kohana::config('config.site_domain'), $event_data, NULL, 300); // 5 minutes
    }

    return $event_data;
}

Cela permettra également d'augmenter considérablement les performances. Les deux techniques ci-dessus ont amélioré une performance sites de 80%.

Si vous avez donné un peu plus d'informations sur l'endroit où vous pensez que le goulot d'étranglement est, je suis sûr que nous pourrions donner de meilleures idées.

Consultez également YSlow (google) pour d'autres conseils de performance.

strictement liée à Kohana (vous avez probablement déjà fait, ou non):

En mode de production:

  1. Activer la mise en cache interne (cela ne cache le Kohana :: résultats find_file, mais cela peut effectivement aider beaucoup.
  2. Désactiver profileur

Juste mes 2 cents:)

Je suis totalement d'accord avec le XDebug et les réponses de mise en cache. Ne regardez pas dans la couche d'optimisation Kohana jusqu'à ce que vous avez identifié vos plus grands goulets d'étranglement de vitesse et l'échelle.

XDebug vous dira étiez vous passez le plus de temps et d'identifier les « points chauds » dans votre code. Conservez ces informations de profilage afin que vous puissiez base et mesurer les améliorations de performance.

problème Exemple et solution: Si vous trouvez que vous construisez des objets chers à partir de la base de données à chaque fois, qui ne changent pas vraiment souvent, alors vous pouvez les regarder en cache avec mécanisme memcached ou d'une autre. Tous ces correctifs de performance prennent du temps et ajouter de la complexité à votre système, alors assurez-vous de vos goulots d'étranglement avant de commencer à les fixer.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top