php & ramdisk

[heulman]

bonjour,

J'ai un site en php qui rame.
Pas moyen d'optimiser le code car c'est encodé.
Pas moyen de prendre un serveur plus gros par manque de budget.

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.

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 ?

Bref je suis preneur de tout retour d'expérience sur l'utilisation d'un
ramdisk sur un site en php.

heulman

[f***@gmail.com]

[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

[heulman]

Post by f***@gmail.com
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.

Post by f***@gmail.com
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.

Post by f***@gmail.com
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

[P'tit Marcel]

Post by heulman
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)

Post by heulman
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+

[heulman]

Post by P'tit Marcel

Post by heulman
J'ai un site en php qui rame.

- 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.

Post by P'tit Marcel
- é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à

Post by P'tit Marcel

Post by heulman
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