Fichier php de 500ko ?

[XoSt]

Bonjour,

Je me demande si ça pose un problème d'avoir un fichier php de 500ko ? il est sur toutes les pages et contient le coeur du système de tout le site.

 

[keroin]

Bah c'est assez énorme quand même, il contient quoi ce fichier ? C'est le fichier index du template d'un site dynamique ?
En tout cas tes visiteurs risquent d'avoir des lenteurs d'ouverture du site (pour ceux qui sont encore en bas débit, le site ne s'ouvrira pas avant de longues dizaines de secondes, voire quelques minutes) :cry:

 

[Leonick]

L'avantage du php c'est la modularité et avec un script de base de 500 Ko, ça le fait vraiment pas :cry:

 

[e-kiwi]

keroin, pas du tout, il pourrai avoir un fichier php de 5Mo, cela ne generai pas le visiteur ! car le php est interpreté par le serveur. donc si derriere ca sort des fichiers html de quelques ko, aucun soucis pour le visiteur. c'est plutot ton serveur qui va faire la gueule mais AUCUN soucis pour le visiteur.

si je regarde tous les includes que fais ma page template php, je dois depasser les 100ko au final ca me sort une page html de 10ko

 

[keroin]

Ah ok je voyais pas ça comme ça

 

[Leonick]

Ce rajaillira obligatoirement sur le visiteur, mais sans dépendre du débit. Si le serveur rame pour exécuter le(s) scripts php, alors la page mettra plus de temps à être créée et donc à être envoyée sur le navigateur.
Quelque soit la taille de la page générée.

 

[e-kiwi]

oui, mais pas de l ordre de secondes comme dit, on parle de dixiemes de secondes dans ce cas. c est pour ca que je dis que le serveur souffrira. le visiteur n'y fera peut-etre meme pas attention si il n'y a pas un trafic immense sur le site.
faites le cfalcul du poids de toutes les pages appelés pour afficher une page dans phpBB

 

[Bourriquet]

A noter que les includes à-tire-la-rigot c'est pas forcément recommandé.

Pour alléger les appels, on peut néammoins préférence les déclinaisons en "once" des fonctions include et require:

include_once et require_once

Elles présentent l'avantage de vérifier d'abord la présence du ficher à charger dans la mémoire, histoire de ne pas le charger 5 ou 6 fois.

En regardant le temps d'exécution d'un script unique, cela ralentit biensur son exécution, vu que la fonction effectue une opération supplémentaire, mais cela se chiffre en millième de secondes et au final, lorsqu'on atteinds un traffic intéressant, on sent de meilleures performances.

 

[XoSt]

J'ai toutes les requetes mysql, la gestion des templates de tout le site, en fait presque tout le php est dedans

Avec des if pour savoir s'il faut ou pas executer bien sur.

 

[serval2a]

Bonjour,

Personnellement j'ai éclaté les fichiers fonctions pour garder une taille correcte de script php et mis en place un système de cache.

 

[e-kiwi]

>> j'ai éclaté les fichiers fonctions pour garder une taille correcte de script php

et un projet bien architecturé aussi ^^

 

[capleton59]

>> j'ai éclaté les fichiers fonctions pour garder une taille correcte de script php

et un projet bien architecturé aussi ^^

deja le serveur peut "ramer" mais en plus en cas de bug ... bon courage si c'est mal commenté :wink:

 

[XoSt]

Ne t'inquiète pas, je le connais par coeur le code

 

[e-kiwi]

oui mais habitue toi au travail en équipe au cas ou ^^

 

[rog]

cool

cool

je suis fan du script en monofichier

mon dernier fait 6000 lignes pour 46 ko

des fois j'y ajoute même les images

et pour répondre : non ça ne gêne pas du tout au contraire ça a quelques avantages

l'un d'eux c'est d'éviter les redeclarations de fonctions

rog

 

[e-kiwi]

>> l'un d'eux c'est d'éviter les redeclarations de fonctions

hhumm... je ne plussoit pas cet argument. un projet bien "architecturé" une fonction n'a sa place que dans un seul fichier

 

[Bourriquet]

C'est justement pour éviter les redéclarations que tes includes doivent être fait en utilisant la version "_once".

Par ailleurs, un script monofichier c'est complètement illisible, et loin d'être packagable, qui est quand même un des atouts majeurs pour un bon site: pour ma part je ne prévoie pas qu'un site reste sur le même serveur toute sa vie, vu que j'essaie d'en augmenter le traffic...

Autant prévoir à la base un système qui permet de migrer rapidement vers un OS un peu différent ou des versions de soft plus récentes. C'est là que ça peut être aussi intéressant d'utiliser des classes en PHP...

 

[rog]

lol

lol

j'ai cité cet exemple, mais il y en a d'autre du type : ça évite tout type de php injection


ensuite c'est pas du tout illisible

1)declaration de variables
2)developpement des différents évènements (je rajoute la norme MVC)
3)librairie de fonctions

si le projet est bien structuré, ça ne pose pas de probleme

rog

 

[serval2a]

Bonjour,
En fait tout dépend des fonctions dont on parle celles qui sont appelées dans cahque page et celles qui ne sont appelées que par certaines.
Là l'architecture à du sens et est plus pratique.
Traitement RSS d'un côté, affichage de données mysql de l'autre...

Avec pour résultat que si je n'appelle que la fonction RSS sur une page je n'ai pas besoin de me servir d'un fichier de 50, 100 voir 500Ko celui de 10 ko me suffit.

 

[rog]

lol

bonjour

c'est cool

mais le fichier php de 500ko va generer du code html qu peut très bien ne peser que 10 ko aussi

rog

 

[serval2a]

Tout à fait mais étant webmaster amateur et donc sur mutualisé je dois réduire au maximum ma conso serveur sous peine de devoir me retrouver chez OVH.

@+

 

[Bourriquet]

Re: lol

lol

j'ai cité cet exemple, mais il y en a d'autre du type : ça évite tout type de php

Quand c'est bien fait, pas d'injection possible. Par contre avec un fichier monoscript, il y a d'autre type d'injection... Par exemple via 'mysql_query', il est possible d'injecter du SQL.

Doit-on ne plus utiliser cette fonction pour autant ? Il faut juste bien faire attention.