| View previous topic :: View next topic |
| Author |
Message |
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
 Posted: Wed Apr 13, 2005 4:15 pm Post subject: Optimisation des ressources d'un SERVEUR ! |
 |
|
Bonsoir !
Comme je vous en avais déjà parlé lorsque nous avions travaillé en collaboration l'année dernière sur l'analyse de la programmation du site Populassite, je viens de trouver une idée en ce qui concerne le compteur de boutons 88x31 affichés par populassite sur ces palettes !
Je sais qu'en temps normal, pour cela, il suffit d'utiliser des requêtes SQL... Ce qui implique donc une connexion_sql au prélable, puis une déconnexion, etc.
Même si je suis sur un serveur dédié, comme j'ai l'esprit d'optimisation, et que je ne souhaite pas consommer bêtement de l'énergie, je fais tout pour utiliser des systèmes de "cache" php (contenant déjà les valeurs des variables) au lieu de requêtes sql intempestives, et il s'avère que c'est une excellente solution puisque lorsque j'étais sur du mutualisé, le fait d'avoir passé en mode cache différé (toutes les 30 s) avait fait reprendre plein de ressources à mon serveur mutualisé de l'époque !
ENFIN, BREF...
Voilà mon idée !
Je voudrais savoir s'il est (à votre avis) plus efficace de faire des créations de fichiers vides dans le répertoire /cache de Populassite et de simples <renommages> de fichiers pour ainsi comptabiliser les affichages des boutons de chacun de mes 500 membres actifs dans la journée ? (c'est une idée que je viens d'inventer à l'instant pour optimiser les performances du serveur lol)
Dîtes-moi si ça marcherait mieux à votre avis que des connexion_sql, requête s'insertion, de sélection, et déconnexion... Quand le trafic est important, je crois savoir que le SQL est déficient !!!! (par rapport à mes expériences avec le mutualisé) car il y a trop de <connexions simultanées>, et tout plante assez rapidement !!!!
Donc, je vous répète mon idée : il suffirait d'avoir 500 fichiers vide portant (par exemple) les noms nbb_id_1_0, nbb_id_2_0, etc.
Et si par exemple, en fin de journée, l'id 1 a fait affiché 500 boutons de son site par l'intermédiaire des palettes de Populassite, alors le fichier vide portera le nom suivant : nbb_id_1_500
Voilà donc mon idée intuitive !!
Dîtes-moi si c'est plus RAPIDE que le sql ou plus fiable ou perforamnt (j'ai l'impression intuitive que OUI lolol car il suffit juste d'une petite option comme "dir *.*" et au pire un fwrite (pour écrire le premier fichier vide) mais surtout le plus drôle : le RENOMMAGE direct du fichier... qui je pense, pour un serveur, doit être archi rapide à gérer en comparaison avec des requêtes sql et des connexions !!!)
@+++
Cordialement |
|
| Back to top |
|
 |
admin
Site Admin
Joined: 01 Aug 2002
Posts: 305
Location: 182
|
| Posted: Wed Apr 13, 2005 6:34 pm Post subject: |
|
|
effectivement la génération de fichier plat sans requettes mysql c'est l'idée...éviter les commande dir et directement donner les noms des fichiers avec des id pour pouvoir faire un fopen direct dessus
_________________
Fred
Fredsoftwares Forum Admin |
|
| Back to top |
|
|
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
| Posted: Wed Apr 13, 2005 6:41 pm Post subject: Je suis d'accord mais |
|
|
Oui, bien sûr, j'y avais pensé !
Mais, est-ce que le fait de LIRE un fichier avec un FOPEN, de remettre à jour la variable, de ré-écrire avec un FWRITE n'est-elle pas plus fastidieuse (car plusieurs opérations de lecture/ECRITURES sur un disque dur est peut-être mauvais ?)
que de faire simplement un accès lecture avec une instruction, par exemple pour un membre d'id X (dans mon exemple)...
Pour récupérer le nom exact... Ensuite, une simple addition PHP... et un RENOMMAGE par ex :
| Code: |
| ren nb_X_13 nb_X_14 |
pour ainsi expliquer qu'il y a eu un affichage de plus de bouton pour l'id X
car je vous rappelle que le but de ma maoeuvre est de compter le nombre d'affichages... donc, mon idée pour éviter les écritures d'octets sur le serveur (correspondant aux varaibles php ayant des valeurs) je préfère faire un REN... ce qui optimise peut-être la vitesse d'écriture sur le disque dur non ? car une réécriture fwrite nécessite des trucs de fragmentation du disque dur je crois... non ?
en gros ?
vous pensez donc que l'astuce du [dir * (bien ciblé !!) + REN] est plus LENTE qu'un [FOPEN sur fichier connu + accès à une variable PHP + remise à jour de cette variable + FWRITE] ?
Merci à vous pour vos éclaircissements de qualité  |
|
| Back to top |
|
|
admin
Site Admin
Joined: 01 Aug 2002
Posts: 305
Location: 182
|
| Posted: Wed Apr 13, 2005 7:22 pm Post subject: |
|
|
en fait remplacer des requettes SELECT avec un WHERE est intéréssant quand on peux accéder direct au fichier contenant les datas ex : tutu_1.php
ensuite pareil les updates du contenu dedans est plus rapide, de toutes les façons une base de données fait aussi des écritures disques donc..
_________________
Fred
Fredsoftwares Forum Admin |
|
| Back to top |
|
|
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
| Posted: Wed Apr 13, 2005 7:28 pm Post subject: OK |
|
|
Oui, oui !
D'une certaine manière, je suis d'accord avec vous... Mais comme je voulais "supprimer" ces écritures disque le plus possible lol !
Donc, ok...
Le "dir ciblé" avec "ren" du fichier souhaité... c'est mauvais !
Comment êtes-vous autant au courant de cela ?
Un renommage (avec dir ciblé au préalable) est donc moins performant qu'un FWRITE selon vous à cause du "DIR" qui met trop de temps (car d'après moi, REN va plus vite que FWRITE) ?
Vous n'avez pas été très explicite par rapport à ça, mais je pense que selon vous, le dir est à PROSCRIRE même s'il est bien ciblé... c'est bien ça ?
un DIR a donc une certaine lenteur avec un fort trafic même si on le "cible" ?
@+++ et merci encore ! mais alors, si j'utilise votre technique suggérée, cela signifie que les fichiers ne seront plus "plats", mais "presque plats" dans la mesure où il contiendront par exemple : "$n = 1"
et à l'appel suivant : "$n = 2", etc. |
|
| Back to top |
|
|
admin
Site Admin
Joined: 01 Aug 2002
Posts: 305
Location: 182
|
| Posted: Wed Apr 13, 2005 7:37 pm Post subject: |
|
|
Un renommage (avec dir ciblé au préalable) est donc moins performant qu'un FWRITE selon vous à cause du "DIR" qui met trop de temps (car d'après moi, REN va plus vite que FWRITE) ?
-> je sais pas précisement dire...
Vous n'avez pas été très explicite par rapport à ça, mais je pense que selon vous, le dir est à PROSCRIRE même s'il est bien ciblé... c'est bien ça ?
-> un dir c'est comme faire un select * ça browse donc ça pompe
_________________
Fred
Fredsoftwares Forum Admin |
|
| Back to top |
|
|
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
| Posted: Wed Apr 13, 2005 7:54 pm Post subject: |
|
|
ok, MERCI !
je comprend
toutes les "boucles de recherche éventuelles sur le disque dur", il faut les retirer en gros car elle consomme du temps...
mais le SQL admet aussi des "connexions" et des "déconnexion"
pourquoi y a*--til des saturations parfois ?
max connect...
ça vient de quoi ça ?
cette limite ?
@+++
je vais donc utiliser un fread, et un fwrite... ça sera sûrement plus efficace qu'une connexion sql, update et deconnexion_sql
car ya pas de recherche à faire |
|
| Back to top |
|
|
admin
Site Admin
Joined: 01 Aug 2002
Posts: 305
Location: 182
|
| Posted: Wed Apr 13, 2005 8:05 pm Post subject: |
|
|
| populassite wrote: |
ok, MERCI !
je comprend
toutes les "boucles de recherche éventuelles sur le disque dur", il faut les retirer en gros car elle consomme du temps...
mais le SQL admet aussi des "connexions" et des "déconnexion"
pourquoi y a*--til des saturations parfois ?
max connect...
ça vient de quoi ça ?
cette limite ?
@+++
je vais donc utiliser un fread, et un fwrite... ça sera sûrement plus efficace qu'une connexion sql, update et deconnexion_sql
car ya pas de recherche à faire |
mysql ça viens des connexions persistantes (conseillées) mais votre hébergeur ne maitrise rien et ça sature le serveur, il y a une conf spéciale a faire
_________________
Fred
Fredsoftwares Forum Admin |
|
| Back to top |
|
|
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
| Posted: Wed Apr 13, 2005 9:16 pm Post subject: |
|
|
non, en fait, je n'ai pas utilisé vos méthodes conseillées comme j'avais des doutes sur le serveur justement et j'ai donc mis des connexion_sql et des deconnexion_sql
et non des persistantes... mais bon, si ça se trouve, il suffit de changer une variable pour éviter le bug de "max connect"
salutations |
|
| Back to top |
|
|
admin
Site Admin
Joined: 01 Aug 2002
Posts: 305
Location: 182
|
| Posted: Wed Apr 13, 2005 9:21 pm Post subject: |
|
|
| populassite wrote: |
non, en fait, je n'ai pas utilisé vos méthodes conseillées comme j'avais des doutes sur le serveur justement et j'ai donc mis des connexion_sql et des deconnexion_sql
et non des persistantes... mais bon, si ça se trouve, il suffit de changer une variable pour éviter le bug de "max connect"
salutations |
il faut mettre cela dans le conf mysql
wait_timeout=300
interactive_timeout=300
_________________
Fred
Fredsoftwares Forum Admin |
|
| Back to top |
|
|
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
| Posted: Wed Apr 13, 2005 9:25 pm Post subject: |
|
|
| ce qui signifie ??? |
|
| Back to top |
|
|
admin
Site Admin
Joined: 01 Aug 2002
Posts: 305
Location: 182
|
| Posted: Wed Apr 13, 2005 9:30 pm Post subject: |
|
|
| populassite wrote: |
| ce qui signifie ??? |
a donner a l'hébergeur
_________________
Fred
Fredsoftwares Forum Admin |
|
| Back to top |
|
|
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
| Posted: Wed Apr 13, 2005 9:42 pm Post subject: |
|
|
| oui, mais ça veut dire quoi les timeout, etc. ? |
|
| Back to top |
|
|
admin
Site Admin
Joined: 01 Aug 2002
Posts: 305
Location: 182
|
| Posted: Wed Apr 13, 2005 9:46 pm Post subject: |
|
|
| populassite wrote: |
| oui, mais ça veut dire quoi les timeout, etc. ? |
c'est pour couper les connexions qui trainet
_________________
Fred
Fredsoftwares Forum Admin |
|
| Back to top |
|
|
populassite
Joined: 27 May 2004
Posts: 62
Location: France
|
| Posted: Wed Apr 13, 2005 10:09 pm Post subject: Pas d'utilisation de requêtes sql : comptabilisation directe |
|
|
OK !
maintenant, voilà le script que j'ai réalisé, en suivant vos conseils pour la comptabilisation de l'affichage des boutons sans utilisation de requêtes SQL inutiles avec des "where" (il fonctionne) mais j'aimerais votre avis d'expert : s'il est suffisamment efficace tel qu'il est programmé là...
| Code: |
function compter_bouton($id) {
global $root;
$fichier = $root."cache/nboutons/$id";
$fp = @fopen($fichier, "r");
if ($fp) {
$nb = fread($fp,filesize($fichier));
fclose($fp);
} else $nb = 0;
$nb++;
$fp = fopen($fichier, "w");
fwrite($fp,$nb);
fclose($fp);
} |
|
|
| Back to top |
|
|
|
Register
Log in
FAQ
Search
