2010-10-09 6 views
1

Je travaille donc sur un projet écrit en PHP à l'ancienne (sans OOP) sans réécriture complète dans un proche avenir. L'un de ses problèmes actuels est sa lenteur: la plus grande partie du temps est consacrée à plus de 100 fichiers en fonction de leur emplacement dans le processus de démarrage. Je me demandais si nous pouvions condenser cela (sur le déploiement, pas le développement bien sûr) en un seul fichier ou deux avec tout le texte require 'd juste construit. Cependant, comme il y a tellement de lignes de code qui sont aren Pas utilisé pour chaque page, je me demande si cela ne se retournerait pas.vitesse php avec les instructions if

À la base, je pense, il est une question de savoir si:

<?php 
    echo 'hello world!'; 
?> 

est plus vite que

<?php 
    if(FALSE) { 
     // thousands of lines of code here 
    } 
    echo 'hello world!'; 
?> 

Et si oui, combien plus lent?

(Aussi, si ce que je l'ai indiqué ci-dessus est une mauvaise idée pour d'autres raisons, s'il vous plaît laissez-moi savoir.)

+0

La réponse, comme d'habitude pour les questions de performance, est la suivante: Mesurez-le vous-même. Quoi qu'il en soit, ces derniers seront plus lents * dans une certaine mesure * parce que ces milliers de lignes doivent être analysées de toute façon. – delnan

Répondre

5

La différence entre les deux sera négligeable. Si la plupart du temps d'exécution est actuellement consacré à des fichiers, vous risquez de voir une amélioration significative en utilisant un cache de code d'opt. Comme APC, si ce n'est déjà fait.

Autre que cela - référence, découvrez exactement où les goulots d'étranglement sont.Dans mon expérience nécessite souvent la partie la plus lente d'une ancienne application PHP procédurale, mais même avec de nombreux fichiers inclus, je serais surpris si ceux-ci tous ajouté à une application «lente».

Edit: ok, un benchmark rapide et sale. J'ai créé trois scripts PHP 'hello world' comme l'exemple. Le premier (basic.php) faisait juste écho à la corde. La seconde (complex.php) incluait une instruction if false contenant ~ 5000 lignes de code PHP collées depuis une autre application. Le troisième (require.php) incluait la même instruction if mais nécessaire dans les ~ 5000 lignes de code d'un autre fichier. Le temps de génération de la page (mesuré par microtime()) entre basic.php et complex.php était d'environ ~ 0.000004 secondes, donc pas vraiment significatif. Des résultats plus complets de banc apache:

 
        without APC   with APC 
       req/sec avg (ms) req/sec avg (ms) 
basic.php:  7819.87  1.277 6960.49 1.437 
complex.php: 346.82  2.883  352.12 2.840 
require.php: 6819.24  1.446 5995.49 1.668 

APC fait pas beaucoup ici, mais en utilisant de la mémoire, mais il est susceptible d'être une autre image dans une application réelle du monde.

+0

Utiliser APC est un très bon point et devrait être le premier essai de l'OP, haut la main. Sans cache il y aura une différence notable entre les deux, parce que le code sera analysé dans tous les cas –

+0

Évidemment, la seconde sera plus lente mais je doute que ce soit d'une quantité significative. Je vais faire quelques repères. –

+0

Intéressant. La raison pour laquelle 'require.php' est beaucoup plus rapide est parce que' require' ne se passe pas réellement parce que c'est dans le bloc if, non? –

0

Gardez à l'esprit que PHP va analyser tout le code qu'il voit, même si ce n'est pas courir.

Il faudra encore beaucoup de temps pour traiter le fichier a et, par expérience, beaucoup de code consommera des quantités considérables de mémoire, même si elles ne sont pas exécutées.

La mise en cache des codes-options suggérée par @Tim devrait être votre première escale. Si cela est hors de question (par exemple en raison de limitations du serveur): Si les fonctions sont en quelque sorte séparables en catégories, une possibilité de rendre les choses un peu plus rapides et légères pourrait être d'utiliser les fonctions Autoloading de PHP dans des fichiers séparés en tant que méthodes de classes statiques.

function xyz() { ... } 

deviendrait

class generic_tools 
{ 
    public static function xyz() { ... } 
} 

et tout appel à xyz() est remplacé par generic_tools::xyz();

L'appel serait alors déclencher l'inclusion de (par exemple) generic_tools.class.phpsur demande, au lieu de tout immediatement. Cela nécessiterait de réécrire les appels de fonction aux appels de méthodes statiques, ce qui peut être facile ou un peu plus difficile (si les appels de fonction sont cuits dynamiquement ou quelque chose). Mais au-delà de cela, aucun refactoring ne serait nécessaire, car vous n'utilisez pas vraiment de mécanismes OOP.

Cela dépendra en grande partie de l'architecture de l'application et de l'entrelacement des fonctions entre elles.

+0

il n'utilise aucun OO. –

+0

@tandu oui, je sais. Votre point étant? L'idée est d'importer toutes les fonctions dans des classes statiques afin qu'elles puissent être chargées séparément. –

0

nécessite une surcharge. 100 exige est probablement beaucoup. L'analyse d'un fichier complet contenant les 100 inclus est probablement lente aussi. Les frais généraux d'exiger pourraient vous coûter plus cher, mais c'est difficile à dire. Cela ne vous coûtera peut-être pas assez.

Tous les repères sont mauvais, mais voici ce que je faisais:

couru un seul fichier comprennent un qui était d'environ 8000 lignes (ne rien faire chaque ligne utile, juste déclare une variable). Comparé au temps nécessaire pour exécuter une inclusion d'un fichier de 80 lignes (mêmes déclarations) 100 fois. Les résultats n'étaient pas concluants.

L'inclusion des fichiers cause-t-elle vraiment le problème? N'existe-t-il pas quelque chose dans l'exécution du script qui peut être optimisé? La mise en cache peut être une option.

Questions connexes