Meilleures pratiques pour l'optimisation de la LAMPE sites de vitesse?

Je veux savoir lors de la construction d'un site classique sur la pile LAMP comment l'optimiser pour le mieux possible les temps de chargement. Je suis en imaginant une DB typique piloté par site.

C'est un oeil de haut niveau et pourrait sans doute tirer en question et permettez-moi de le décomposer dans chaque couche de la pile.

L - Au niveau du système, (le programme d'installation et le système de fichier) pouvez-vous faire pour améliorer la vitesse? Une chose que je peux penser à est de la taille d'une image, peut de compression pour vous aider à optimiser quoi que ce soit?

A - Il doit y avoir une tonne de paramètres relatifs à la vitesse d'un site ici dans le serveur web. Pas mon fort. Probablement dépend beaucoup de comment de nombreux sites sont en cours d'exécution simultanément.

M - MySQL dans une base de données axée site, DB la performance est la clé. Est-il mieux de normalisation approche que j'ai.e, à l'aide de tableaux de lien? Les développeurs Web souvent juste faire simple monolithique tableaux ressemblant à 1FN et cela peut tuer la performance.

P - hormis améliorant les performances des paramètres comme la mise en cache, ce qui peut le programmeur faire pour affecter les performances à un niveau élevé? Je voudrais vraiment savoir si MVC approches de conception frappé performance plus rapide et sale. D'autres conseils simples comme ce sont des sessions plus vite que les cookies serait intéressant de savoir.

Évidemment, il faut descendre et sale dans les détails et trouver ce code est de vous ralentir. Aussi je me rends compte que de nombreux sites ont beaucoup de différentes caractéristiques de performance, mais imaginons qu'un site classique qui a plus de lectures écrit ensuite.

Je me demandais simplement si l'on peut compiler un tas de bonnes pratiques et de pleinement s'attendre à ce lien d'autres questions afin que nous puissions efficacement bilan d'une liste de contrôle.

Mon but est de voir si le même en plus des habituels problèmes de performances, nous pouvons voir quelques saugrenue des choses que vous ne pourriez pas penser de la récolte jusqu'à aller de pair avec des pratiques exemplaires pour le résumé.

Donc ma question est, si vous étiez à partir de zéro, comment feriez-vous sûr votre LAMPE de site a été rapide?

InformationsquelleAutor tkotitan | 2009-03-30
  1. 33

    Voici quelques personnels doivent-dos que j'ai toujours mis en place dans ma LAMPE applications.

    • Installer mod_deflate pour apache, et
      ne pas utiliser de PHP gzip gestionnaires.
      mod_deflate vous permettra de
      compresser le contenu statique, comme
      javascript/css/html statique, ainsi
      comme d'habitude dynamique PHP de sortie, et
      c'est une chose de moins à s'inquiéter
      dans votre code.

    • Être prudent avec .htaccess!
      L'activation .htaccess pour
      répertoires dans votre application signifie que
      Apache est de scanner le système de fichiers
      constamment à la recherche pour .htaccess
      les directives. Il est de loin préférable de mettre
      directives à l'intérieur de la principale
      ou de configuration d'un serveur virtuel
      configuration, où ils sont chargés
      une fois que. De tout temps, vous pouvez vous débarrasser d'un
      répertoire de niveau de l'accès au dossier par le déplacement
      dans un fichier de configuration principal,
      vous enregistrez temps d'accès au disque.

    • Préparer votre application de base de données
      la couche d'utiliser un gestionnaire de connexion
      d'une certaine sorte (j'utilise un Singleton pour
      la plupart des applications). Ce n'est pas très
      difficile à faire, et en réduisant le nombre
      de connexions de base de données de votre
      l'application s'ouvre permet d'économiser des ressources.

    • Si vous pensez que votre application
      voir une charge importante, memcached peut
      accomplir des miracles. Gardez cela à l'esprit
      alors que vous écrivez votre code... peut-être
      un jour, au lieu de créer des objets
      à la volée, vous serez l'obtention de leur
      de memcache. Un peu de prévoyance
      la mise sur pied indolore.

    • Une fois que votre application est en place et en cours d'exécution, définir
      MySQL est lent moment de la requête pour une petite
      nombre et de surveiller le slow query log
      avec diligence. Cela va vous montrer où
      votre problème requêtes sont venant de,
      et vous permettent d'optimiser votre
      les requêtes et les index avant qu'ils
      devenir un problème.

    • Pour des performances sérieuses bidouilleurs, vous
      voulez compiler PHP à partir des sources.
      Installation à partir d'un package installe un
      beaucoup de bibliothèques que vous avez peut-être jamais
      utiliser. Depuis PHP environnements sont
      chargé dans chaque instance d'une
      Apache thread, même un 5MO de mémoire
      la surcharge de bibliothèques supplémentaires rapidement
      devient 250 MO de mémoire perdue lors de l'
      il y a 50 Apache threads
      de l'existence. Je garde une liste de mes
      standard ./ligne de configuration que j'utilise quand
      PHP ici, et je trouve que c'
      convient à la plupart de mes applications. L'
      inconvénient est que si vous vous retrouvez
      besoin d'une bibliothèque, vous devez
      recompiler PHP pour l'obtenir. Analyser
      votre code et de le tester dans un devel
      environnement assurez-vous que vous avez
      tout ce dont vous avez besoin.

    • Rapetisser votre Javascript.

    • Être prêt à se déplacer du contenu statique,
      tels que des images et de la vidéo, à un
      non le serveur web dynamique. Écrivez votre
      le code de sorte que toutes les Url pour les images et les
      la vidéo sont facilement configuré pour pointer
      d'un autre serveur dans le futur. Un
      serveur web optimisé pour le statique
      le contenu peut facilement servir de dizaines ou même de
      des centaines de fois plus rapide qu'un
      dynamique serveur de contenu.

    C'est ce que je peux penser à du haut de ma tête. Googler autour de PHP meilleures pratiques trouverez beaucoup de conseils sur la façon d'écrire plus vite ou mieux un code (comme: echo est plus rapide que print).

    • Belle réponse. Je vous remercie.
    • +1 en général je suis d'accord, sauf pour le "package installe beaucoup de bibliothèques que vous pouvez ne jamais utiliser". Pas vrai du tout, dans n'importe quelle distro Linux PHP est divisé en php-common, apache2-mod_php, php-cli et quelques 30 php-que ce soit pour chaque lib. Vous n'installer/activer ceux dont vous avez besoin.
    • +1 Vraiment utile de répondre. De grandes idées.
    • +1 pour la réponse très complète.
    InformationsquelleAutor zombat
  2. 11

    D'abord, se rendre compte que la performance est un processus itératif. Vous n'avez pas de générer une application web en un seul passage, lancer, et de ne jamais travailler sur un nouveau. Au contraire, commencer petit, et de régler les problèmes de rendement que votre site se développe.

    Maintenant, sur les détails:

    1. Profil. Identifier vos blocages. C'est l'étape la plus importante. Vous devez vous concentrer vos efforts là où vous obtiendrez les meilleurs résultats. Vous devez avoir une sorte de solution de surveillance en place (comme les cactus ou munin), vous donnant de la visibilité sur ce qui se passe sur votre serveur(s)
    2. Cache, cache, cache. Vous trouverez probablement que la base de données d'accès est votre plus grand goulot d'étranglement sur le back-end, mais vous devriez vérifier cela sur votre propre. Heureusement, vous trouverez probablement que beaucoup de vos visiteurs pour un petit ensemble de ressources. Vous pouvez mettre en cache ces ressources dans quelque chose comme memcached, vous sauver de la base de données de frapper, et améliore le backend de performance.
    3. Comme d'autres l'ont mentionné ci-dessus, prendre un coup d'oeil à la YDN les règles de performance. Prendre la livre d'accompagnement. Cette vais vous aider, avec le front de rendement de fin d'
    4. Installer PHP APC, et assurez-vous qu'il est configuré avec assez de mémoire pour contenir tous vos compilé PHP bytecode. Nous avons récemment découvert que notre APC d'installation n'a pas assez de ram; en lui donnant assez de travailler à réduire nos temps de calcul en la moitié, et l'activité du disque de 10%
    5. Assurez-vous que vos tables de base de données sont correctement indexé. Cela va de pair avec la surveillance de la slow query log.

    Ci-dessus, vous obtiendrez de très loin. C'est-à-dire, même un assez db-lourds site devrait être en mesure de survivre à un frontpage digg sur un seul modestement-spec avais serveur si vous avez fait ci-dessus.

    Vous finirez par atteindre un point où la valeur par défaut de configuration d'apache ne sera pas toujours en mesure de suivre les demandes entrantes. Lorsque vous appuyez sur ce mur, il y a deux choses à faire:

    1. Comme ci-dessus, de profil. Surveiller votre serveur apache activité -- vous devriez avoir une idée du nombre de connexions actives à un moment donné, en plus du nombre maximum de connexions actives lorsque vous obtenez des rafales soudaines de trafic
    2. Configurer apache avec cela à l'esprit. Ce est le meilleur guide de configuration d'apache j'ai vu: Pratique mod_perl chapitre 11
    3. Prendre autant de charge arrêt d'apache que vous le pouvez. Apache est trop lourd-devoir de servir du contenu statique de manière efficace. Vous devriez être en utilisant un léger reverse proxy (comme squid) ou serveur web (lighttpd ou nginx) pour servir du contenu statique, et de prendre en charge le travail de la cuillère d'alimentation octets pour les clients lents. Cela laisse à Apache de faire ce qu'il fait de mieux: l'exécution de votre code. Encore une fois, le mod_perl livre fait un bon travail de expliquant cela.

    Une fois que vous êtes arrivé jusqu'ici, c'est en grande partie un problème de mise en cache plus, et de garder un œil sur votre base de données. Finalement, vous allez dépasser un serveur unique. Tout d'abord, vous aurez probablement ajouter plus avant la fin de boîtes, le tout soutenu par un seul serveur de base de données. Ensuite, vous allez devoir commencer à répandre votre base de données de charge autour de, probablement par la fragmentation. Pour avoir un bon aperçu de ce processus de croissance, voir ce livejournal présentation

    Pour un regard plus en profondeur à une grande partie de la ci-dessus, découvrez La Construction Évolutive De Sites Web, par Cal Henderson, de Flickr, de la gloire. Google a des parties du livre disponibles pour la prévisualisation

    InformationsquelleAutor Frank Farmer
  3. 3

    J'ai utilisé MysqlTuner pour l'analyse des performances sur mes serveurs mysql et sa donne un bon aperçu d'autres problèmes de googler, ainsi que de faire ses propres recommandations

    InformationsquelleAutor David Snabel-Caunt
  4. 2

    Une ressource que vous pourriez trouver utile est la YDN ensemble de règles de performance.

    InformationsquelleAutor VirtuosiMedia
  5. 2

    Ne pas oublier le fait que vos utilisateurs vont être des milliers de miles loin de votre serveur, et de télécharger des dizaines de fichiers de rendre une seule page. Que le temps de latence, et les frais généraux d'affichage de la page dans le navigateur peut être supérieure à la quantité de temps que vous passez dans la collecte de l'information, et la génération de la page.

    Voir les pages de Yahoo Developer Network sur Les meilleures Pratiques pour accélérer Votre Site Web, et la YSlow outil pour voir ce que la partie de téléchargement du site prend du temps.

    InformationsquelleAutor Alister Bulman
  6. 2

    Ne pas oublier de désactiver la fois pour votre système de fichiers!

    InformationsquelleAutor Zak
  7. 2

    Je vous recommande d'utiliser Jet Profiler for MySQL pour trouver toutes les mauvaises questions. J'ai utilisé avec succès sur un couple de mes sites. Vraiment utile, et beaucoup plus facile à digérer que le slow query log.

    InformationsquelleAutor Robert Nilsson
  8. 1

    Je vous recommande de commencer avec http://highscalability.com/

    Que pour vos suggestions:

    De Compression pour les images, certainement pas. Type de système de fichiers de s'écouler, oui, qui pourrait avoir un certain effet, mais minime. Mais en réalité, le mieux est d'utiliser de la mémoire reverse proxy, ou encore mieux, CA.

    Pour Apache fondamentalement charger uniquement les modules dont vous avez besoin. Ne chargez pas autre chose. Comme avec PHP, vous pouvez uniquement utiliser un fork de MPM, il est important de garder mince. Comme pour les paramètres optimaux, ainsi vous avez à affiner leur application spécifique, le matériel etc. Si vous avez assez de CPU, il est recommandé que vous utilisez mod_deflate. Plus le serveur peut envoyer des données au client, plus vite il peut commencer le traitement de la requête suivante.

    InformationsquelleAutor vartec