Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
fgirault
On 25 juil, 14:36, "heulman" wrote:
[mon site rame]
Malgré l'encodage, peut être est-il possible de faire du profiling (avec xdebug2 par exemple) pour savoir ce qui rame ?
Si c'est coté base de données que ça coince, ça ne sert pas à grand chose de s'escrimer avec php.
Jetez un coup d'oeil à :
http://www.xdebug.org/docs/profiler
Malgré l'encodage, des choses intéressantes peuvent apparaître.
Je pensais utiliser un ramdisk. Vaut-il mieux l'utiliser sur les fichiers du site, sur le cache de eaccelerator, ou peut-être sur la base de données ?
Si vous avez 4Go de Ram, pourquoi pas, tant que vous faites les backups sur des supports de masse.
Ceci dit, si l'OS n'est pas trop moisi, le cache du système de fichier doit déjà maintenir en mémoire les fichiers les plus accédés (si sa stratégie de cache n'est pas trop mauvaise). Ce qui équivaut à un ramdisk.
Bref je suis preneur de tout retour d'expérience sur l'utilisation d'un ramdisk sur un site en php.
Désolé de ne pas apporter plus d'eau au moulin, mais empiler les solutions d'optimisation ne me semble pas la vraie solution au problème. Il y a manifestement un problème dans l'application, seul un correctif à ce niveau fera avancer le schmillblick. Sinon, à ce compte, vous revenez dans 2 mois pour demander comment faire moins ramer le site malgré le ramdisk.
-- FG
On 25 juil, 14:36, "heulman" <heul...@hotmail.com> wrote:
[mon site rame]
Malgré l'encodage, peut être est-il possible de faire du profiling
(avec xdebug2 par exemple) pour savoir ce qui rame ?
Si c'est coté base de données que ça coince, ça ne sert pas à grand
chose
de s'escrimer avec php.
Jetez un coup d'oeil à :
http://www.xdebug.org/docs/profiler
Malgré l'encodage, des choses intéressantes peuvent apparaître.
Je pensais utiliser un ramdisk.
Vaut-il mieux l'utiliser sur les fichiers du site, sur le cache de
eaccelerator, ou peut-être sur la base de données ?
Si vous avez 4Go de Ram, pourquoi pas, tant que vous faites
les backups sur des supports de masse.
Ceci dit, si l'OS n'est pas trop moisi, le cache du système
de fichier doit déjà maintenir en mémoire les fichiers
les plus accédés (si sa stratégie de cache n'est pas
trop mauvaise). Ce qui équivaut à un ramdisk.
Bref je suis preneur de tout retour d'expérience sur l'utilisation d'un
ramdisk sur un site en php.
Désolé de ne pas apporter plus d'eau au moulin, mais empiler les
solutions d'optimisation ne me semble pas la vraie solution
au problème. Il y a manifestement un problème dans l'application,
seul un correctif à ce niveau fera avancer le schmillblick. Sinon,
à ce compte, vous revenez dans 2 mois pour demander comment
faire moins ramer le site malgré le ramdisk.
Malgré l'encodage, peut être est-il possible de faire du profiling (avec xdebug2 par exemple) pour savoir ce qui rame ?
Si c'est coté base de données que ça coince, ça ne sert pas à grand chose de s'escrimer avec php.
Jetez un coup d'oeil à :
http://www.xdebug.org/docs/profiler
Malgré l'encodage, des choses intéressantes peuvent apparaître.
Je pensais utiliser un ramdisk. Vaut-il mieux l'utiliser sur les fichiers du site, sur le cache de eaccelerator, ou peut-être sur la base de données ?
Si vous avez 4Go de Ram, pourquoi pas, tant que vous faites les backups sur des supports de masse.
Ceci dit, si l'OS n'est pas trop moisi, le cache du système de fichier doit déjà maintenir en mémoire les fichiers les plus accédés (si sa stratégie de cache n'est pas trop mauvaise). Ce qui équivaut à un ramdisk.
Bref je suis preneur de tout retour d'expérience sur l'utilisation d'un ramdisk sur un site en php.
Désolé de ne pas apporter plus d'eau au moulin, mais empiler les solutions d'optimisation ne me semble pas la vraie solution au problème. Il y a manifestement un problème dans l'application, seul un correctif à ce niveau fera avancer le schmillblick. Sinon, à ce compte, vous revenez dans 2 mois pour demander comment faire moins ramer le site malgré le ramdisk.
-- FG
P'tit Marcel
J'ai un site en php qui rame.
mes conseils à deux centimes : - optimiser en priorité le gestionnaire de base de données. On peut par exemple lui demander de tracer les requêtes fortement consommatrices. Si c'est le même serveur où tournent BD et php, prévoir un peu plus que 256Ko de RAM... - amha, un ramdisk ne sert à rien à la BD car tout SGBD digne de ce nom dispose de son propre système de mémoire virtuelle. - voir s'il n'y a pas d'archivage à faire dans la BD (taille des tables, % de consultation/maj des lignes) - éventuellement : vérifier que les logs BD, php, web et applicative soient d'une taille raisonnable (un mauvais paramétrage peut créer des logs énormes qui sont coûteuses à remplir)
J'ai déjà mis en place e-accelerator qui a un peu amélioré les perfs il y a quelques mois mais ça rame à nouveau.
C'est un indice qu'il y a quelques chose à faire côté archivage de BD. Est-ce que l'application intègre une fonction de réduction de la taille des informations stockées (transfert en tables d'historique, effacement après sauvegarde, etc.) ? Certains développeurs oublient qu'un logiciel peut durer plus longtemps qu'une startup...
a+ -- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
J'ai un site en php qui rame.
mes conseils à deux centimes :
- optimiser en priorité le gestionnaire de base de données. On peut par
exemple lui demander de tracer les requêtes fortement consommatrices. Si
c'est le même serveur où tournent BD et php, prévoir un peu plus que
256Ko de RAM...
- amha, un ramdisk ne sert à rien à la BD car tout SGBD digne de ce nom
dispose de son propre système de mémoire virtuelle.
- voir s'il n'y a pas d'archivage à faire dans la BD (taille des tables,
% de consultation/maj des lignes)
- éventuellement : vérifier que les logs BD, php, web et applicative
soient d'une taille raisonnable (un mauvais paramétrage peut créer des
logs énormes qui sont coûteuses à remplir)
J'ai déjà mis en place e-accelerator qui a un peu amélioré les perfs il y a
quelques mois mais ça rame à nouveau.
C'est un indice qu'il y a quelques chose à faire côté archivage de BD.
Est-ce que l'application intègre une fonction de réduction de la taille
des informations stockées (transfert en tables d'historique, effacement
après sauvegarde, etc.) ? Certains développeurs oublient qu'un logiciel
peut durer plus longtemps qu'une startup...
a+
--
P'tit Marcel
stats sur les forums modérés http://www.centrale-lyon.org/ng/
mes conseils à deux centimes : - optimiser en priorité le gestionnaire de base de données. On peut par exemple lui demander de tracer les requêtes fortement consommatrices. Si c'est le même serveur où tournent BD et php, prévoir un peu plus que 256Ko de RAM... - amha, un ramdisk ne sert à rien à la BD car tout SGBD digne de ce nom dispose de son propre système de mémoire virtuelle. - voir s'il n'y a pas d'archivage à faire dans la BD (taille des tables, % de consultation/maj des lignes) - éventuellement : vérifier que les logs BD, php, web et applicative soient d'une taille raisonnable (un mauvais paramétrage peut créer des logs énormes qui sont coûteuses à remplir)
J'ai déjà mis en place e-accelerator qui a un peu amélioré les perfs il y a quelques mois mais ça rame à nouveau.
C'est un indice qu'il y a quelques chose à faire côté archivage de BD. Est-ce que l'application intègre une fonction de réduction de la taille des informations stockées (transfert en tables d'historique, effacement après sauvegarde, etc.) ? Certains développeurs oublient qu'un logiciel peut durer plus longtemps qu'une startup...
a+ -- P'tit Marcel stats sur les forums modérés http://www.centrale-lyon.org/ng/
heulman
a écrit dans le message de news:
On 25 juil, 14:36, "heulman" wrote:
Jetez un coup d'oeil à : http://www.xdebug.org/docs/profiler Malgré l'encodage, des choses intéressantes peuvent apparaître.
Je vais regarder cela au calme ce week-end.
Ceci dit, si l'OS n'est pas trop moisi, le cache du système de fichier doit déjà maintenir en mémoire les fichiers les plus accédés (si sa stratégie de cache n'est pas trop mauvaise). Ce qui équivaut à un ramdisk.
Y a-til un moyen de voir quels sont les fichiers qui sont maintenus en mémoire ?
En fait, en tatonnant j'ai l'impression qu'il y a un nombre d'include très important d'une quantité de petits fichiers. C'est pourquoi j'ai pensé à un engorgement au niveau du HD et donc à un Ramdisk.
Désolé de ne pas apporter plus d'eau au moulin, mais empiler les solutions d'optimisation ne me semble pas la vraie solution au problème. Il y a manifestement un problème dans l'application, seul un correctif à ce niveau fera avancer le schmillblick. Sinon, à ce compte, vous revenez dans 2 mois pour demander comment faire moins ramer le site malgré le ramdisk.
perso je pense que l'appli est en cause mais je ne peux malheuereusement pas y toucher.
heulman
<fgirault@gmail.com> a écrit dans le message de news:
1185371326.850240.252350@o61g2000hsh.googlegroups.com...
On 25 juil, 14:36, "heulman" <heul...@hotmail.com> wrote:
Jetez un coup d'oeil à :
http://www.xdebug.org/docs/profiler
Malgré l'encodage, des choses intéressantes peuvent apparaître.
Je vais regarder cela au calme ce week-end.
Ceci dit, si l'OS n'est pas trop moisi, le cache du système
de fichier doit déjà maintenir en mémoire les fichiers
les plus accédés (si sa stratégie de cache n'est pas
trop mauvaise). Ce qui équivaut à un ramdisk.
Y a-til un moyen de voir quels sont les fichiers qui sont maintenus en
mémoire ?
En fait, en tatonnant j'ai l'impression qu'il y a un nombre d'include très
important d'une quantité de petits fichiers. C'est pourquoi j'ai pensé à un
engorgement au niveau du HD et donc à un Ramdisk.
Désolé de ne pas apporter plus d'eau au moulin, mais empiler les
solutions d'optimisation ne me semble pas la vraie solution
au problème. Il y a manifestement un problème dans l'application,
seul un correctif à ce niveau fera avancer le schmillblick. Sinon,
à ce compte, vous revenez dans 2 mois pour demander comment
faire moins ramer le site malgré le ramdisk.
perso je pense que l'appli est en cause mais je ne peux malheuereusement pas
y toucher.
Jetez un coup d'oeil à : http://www.xdebug.org/docs/profiler Malgré l'encodage, des choses intéressantes peuvent apparaître.
Je vais regarder cela au calme ce week-end.
Ceci dit, si l'OS n'est pas trop moisi, le cache du système de fichier doit déjà maintenir en mémoire les fichiers les plus accédés (si sa stratégie de cache n'est pas trop mauvaise). Ce qui équivaut à un ramdisk.
Y a-til un moyen de voir quels sont les fichiers qui sont maintenus en mémoire ?
En fait, en tatonnant j'ai l'impression qu'il y a un nombre d'include très important d'une quantité de petits fichiers. C'est pourquoi j'ai pensé à un engorgement au niveau du HD et donc à un Ramdisk.
Désolé de ne pas apporter plus d'eau au moulin, mais empiler les solutions d'optimisation ne me semble pas la vraie solution au problème. Il y a manifestement un problème dans l'application, seul un correctif à ce niveau fera avancer le schmillblick. Sinon, à ce compte, vous revenez dans 2 mois pour demander comment faire moins ramer le site malgré le ramdisk.
perso je pense que l'appli est en cause mais je ne peux malheuereusement pas y toucher.
heulman
heulman
"P'tit Marcel" a écrit dans le message de news: 46a84b5e$0$12176$
J'ai un site en php qui rame.
mes conseils à deux centimes : - optimiser en priorité le gestionnaire de base de données. On peut par exemple lui demander de tracer les requêtes fortement consommatrices. Si c'est le même serveur où tournent BD et php, prévoir un peu plus que 256Ko de RAM... - amha, un ramdisk ne sert à rien à la BD car tout SGBD digne de ce nom dispose de son propre système de mémoire virtuelle. - voir s'il n'y a pas d'archivage à faire dans la BD (taille des tables, % de consultation/maj des lignes)
La BD est de taille raisonnable (3Mo environ) et rien vu de spécial à optimiser.
- éventuellement : vérifier que les logs BD, php, web et applicative soient d'une taille raisonnable (un mauvais paramétrage peut créer des logs énormes qui sont coûteuses à remplir)
RAS de ce côté là
J'ai déjà mis en place e-accelerator qui a un peu amélioré les perfs il y a quelques mois mais ça rame à nouveau.
C'est un indice qu'il y a quelques chose à faire côté archivage de BD. Est-ce que l'application intègre une fonction de réduction de la taille des informations stockées (transfert en tables d'historique, effacement après sauvegarde, etc.) ? Certains développeurs oublient qu'un logiciel peut durer plus longtemps qu'une startup...
J'ai l'impression que le pb est dû à une grande quantité d'include de petits fichiers. Dans ce cadre le Ramdisk est-il une solution éventuelle ?
heulman
"P'tit Marcel" <geononauxspams@centrale-lyon.org> a écrit dans le message de
news: 46a84b5e$0$12176$426a74cc@news.free.fr...
J'ai un site en php qui rame.
mes conseils à deux centimes :
- optimiser en priorité le gestionnaire de base de données. On peut par
exemple lui demander de tracer les requêtes fortement consommatrices. Si
c'est le même serveur où tournent BD et php, prévoir un peu plus que 256Ko
de RAM...
- amha, un ramdisk ne sert à rien à la BD car tout SGBD digne de ce nom
dispose de son propre système de mémoire virtuelle.
- voir s'il n'y a pas d'archivage à faire dans la BD (taille des tables, %
de consultation/maj des lignes)
La BD est de taille raisonnable (3Mo environ) et rien vu de spécial à
optimiser.
- éventuellement : vérifier que les logs BD, php, web et applicative
soient d'une taille raisonnable (un mauvais paramétrage peut créer des
logs énormes qui sont coûteuses à remplir)
RAS de ce côté là
J'ai déjà mis en place e-accelerator qui a un peu amélioré les perfs il y
a quelques mois mais ça rame à nouveau.
C'est un indice qu'il y a quelques chose à faire côté archivage de BD.
Est-ce que l'application intègre une fonction de réduction de la taille
des informations stockées (transfert en tables d'historique, effacement
après sauvegarde, etc.) ? Certains développeurs oublient qu'un logiciel
peut durer plus longtemps qu'une startup...
J'ai l'impression que le pb est dû à une grande quantité d'include de petits
fichiers.
Dans ce cadre le Ramdisk est-il une solution éventuelle ?
"P'tit Marcel" a écrit dans le message de news: 46a84b5e$0$12176$
J'ai un site en php qui rame.
mes conseils à deux centimes : - optimiser en priorité le gestionnaire de base de données. On peut par exemple lui demander de tracer les requêtes fortement consommatrices. Si c'est le même serveur où tournent BD et php, prévoir un peu plus que 256Ko de RAM... - amha, un ramdisk ne sert à rien à la BD car tout SGBD digne de ce nom dispose de son propre système de mémoire virtuelle. - voir s'il n'y a pas d'archivage à faire dans la BD (taille des tables, % de consultation/maj des lignes)
La BD est de taille raisonnable (3Mo environ) et rien vu de spécial à optimiser.
- éventuellement : vérifier que les logs BD, php, web et applicative soient d'une taille raisonnable (un mauvais paramétrage peut créer des logs énormes qui sont coûteuses à remplir)
RAS de ce côté là
J'ai déjà mis en place e-accelerator qui a un peu amélioré les perfs il y a quelques mois mais ça rame à nouveau.
C'est un indice qu'il y a quelques chose à faire côté archivage de BD. Est-ce que l'application intègre une fonction de réduction de la taille des informations stockées (transfert en tables d'historique, effacement après sauvegarde, etc.) ? Certains développeurs oublient qu'un logiciel peut durer plus longtemps qu'une startup...
J'ai l'impression que le pb est dû à une grande quantité d'include de petits fichiers. Dans ce cadre le Ramdisk est-il une solution éventuelle ?
