Zend FR

perso, j'ai un énoorme développement à faire, qui va demander plusieurs ressources tel qu'un graphiste, d'autres développeurs. N'ayant pas d'expérience dans les gros développements (type CRM), je ne me vois pas commençer mon application sans utiliser un framework. ZF est vraiment compliqué pour moi, mais après c'est un choix : je préfère perdre du temps maintenant sur son apprentissage (et je ne suis pas prêt d'avoir fini).

Voilà, pour résumé mon choix d'utiliser ZF (j'y suis que depuis qq semaines d'auto-formation) :
- je ne veux pas m'occuper de l'intégration du graphisme, l'aspect VUE m'interesse (je pourrais utiliser un moteur de template comme Smarty aussi)
- je ne veux pas que chaque développeur programme à sa sauce et s'il quitte le projet, recommencer son travail. Il est important pour moi que l'équipe suit un modèle de développement, alors Z-F répond parfaitement à mes attentes de ce côté
- Je ne supporte pas faire des copier coller de code et de travailler sans cesse sur des classes buggés : ZF met à ma disposition des modèles de gestions de bd, authentification, droit, etc. Bon, pour l'instant étant donné que je maitrise que dalle, je ne peux pas vraiment parler mais j'espère que ça viendra)
- ZF est orienté objet, c'est super, ça limite le bourrinage
- Partisan du suite www.developpez.com, j'ai vu qu'il y'avait un sous forum ZF et pleins de tutos français : alors ça me garanti le serieux du framework
- enfin, la communauté de ZF france est petite (ce sont toujours les mêmes qui répondent aux questions du forum présent), mais avec une réactivité étonnante ! Perso je suis complêtement charmé : aucun de mes problèmes n'a été sans suite et pourtant les questions débiles j'en ai posé et j'en pose encore. Franchement merci aux admins et autres personnes du forum, vous donnez envie de contribuer pour ZF.

Quoi qu'il en soit, mon appli à réaliser est énorme et met en oeuvre beaucoup de point que je n'ai pas encore abordé avec ZF (javascript, template, couplage avec d'autre cms/crm, etc...). Je te parle en tant que super débutant.

Bon courage !

Dernière modification par whitespirit (19-02-2008 06:37:56)

Bonjour,

J'ai un site avec un trafic relativement fort (900 000 pages vues / mois, 500 000 visites/mois) qui fonctionne bien avec le ZF (1.0.3).
Les caractéristiques sont :
- 1 serveur apache
- 1 base séparée
- site assez simple fonctionnellement
- Pas activé APC
- Pas utilisé Zend_Cache

J'avais implémenté un système de cache, mais comme ça tient la charge, je ne l'ai pas activé.

Ca tient bien. Même remarque que Titerm, PHP n'est pas réputé pour sa vitesse, le ZF non plus, cependant avec les serveurs actuels on peut déjà atteindre des trafics sympa sans se poser trop de question... (certes, mon site est un lilliputien par rapport à celui de Titerm )

Sinon Zend_Cache est bien pensé et facile à mettre en place en cas de besoin.

A+, Philippe

PHP est un langage de script très performant.
Le problème avec les frameworks, n'est pas tellement le code objet ( même si les __call, __autoload et autres call_user_* ne sont pas des plus perfomants ) mais le nombre de fichiers à inclure.

PHP n'est pas un langage compilé => il compile chacun de ses scripts à la volée, puis les execute. (Parsing, Compilation OPCodes, puis Execution de l'OPCode par le ZendEngine)
Lors d'un appel include, l'execution du moteur est mise en pause, et l'adresse de la pile est mémorisée. PHP commence alors à parser le fichier inclut, puis à le compiler, pour enfin l'executer, et retourner à l'adresse de pile précédemment sauvée.
Et ainsi de suite.

Ce processus est très couteux lorsque beaucoup de fichiers et d'inclusions entrent en jeu.
Un cache d'OPCode permet d'éviter toutes ces étapes en gardant en mémoire vive le code compilé, et évite ainsi de lourdes étapes, répétitives, à PHP.

Cacher au niveau HTTP est aussi une très bonne chose pour optimiser les perfs, toute la question réside dans le TTL à utiliser. Sur les sites très dynamiques, cette solution devient peu appropriée, même si les ressources statiques peuvent toujours être cachées ( et doivent l'être ).
Utiliser du load balancing pour gérer le contenu statique/dynamique est une bonne solution à rajouter.

Compiler Apache avec PHP en statique est très bon aussi, de même que compiler PHP soi-même avec toutes les options d'optimisations pour sa machine, et en virant tous les modules non nécéssaires.

Bah si, nous, on a plusieurs frontaux... Bon c'est pas du LVS, c'est vraiment des serveurs physiques et le load balancing est fait par un proxy en amont. Chaque frontal est autonome. Tous nos sites tournent sur ces mêmes serveurs, le public, l'institutionnel, etc...

1/ Perso, je n'ai jamais eu de pb d'utilisation avec APC. On a parfois trouvé des bugs mais après soit une ouverture, soit une proposition de patch, c'est rapidement intégré dans le trunk et dispo dans la version suivante. La team qui gère est relativement réactive.
2/ Aucun impact sur le dev si tu te contente d'utiliser le cache d'op code. La valeur pour le shm dépend de la consommation que tu en feras personnellement dans tes dev indépendamment du cache d'opcode. De toute facon, le cache d'opcode ne consomme quasi rien (sur mon serveur actu, 1000 fichiers = 15Mo).

Si APC n'est pas déjà dans le core, cela ne devrait plus tarder. Je pesne que Zend a traîné les pieds car il vende aussi un cache d'opcode mais il me semble qu'il est acté que APC doit intégrer le core. En revanche, il sera probablement off par défaut dans php.ini.
Avec la distrib apc, tu doit avoir un apc.php, met le sur ton serveur web, tu auras pas mal d'info en live sur ton APC.