php & ramdisk

Le
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
fgirault
Le #31253
On 25 juil, 14:36, "heulman"
[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

P'tit Marcel
Le #30751
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/

heulman
Le #30749

On 25 juil, 14:36, "heulman"
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
Le #30750
"P'tit Marcel" 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


Publicité
Poster une réponse
Anonyme