[phpBB Debug] PHP Warning: in file [ROOT]/viewtopic.php on line 2342: file_get_contents(http://www.like-rank.com/profile.php?id=eyIwIjoibmlmcm91IiwiMSI6InBmcnM5MSIsIjIiOiJyZWZlcmVuY2V1ciIsIjMiOiJtYm91Y2hhdWQiLCI0Ijoibmlmcm91IiwiNSI6IldhbGxhcyIsIjYiOiJuaWZyb3UiLCI3IjoiV2FsbGFzIiwiOCI6IldhbGxhcyIsIjkiOiJlbnpvc3BoZXJlIiwiMTAiOiJ0YW5yb3VnZSIsIjExIjoiU3lsdmFpblAiLCIxMiI6InNpdGF4YSJ9): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
[phpBB Debug] PHP Warning: in file [ROOT]/urltoico/index.php on line 213: file_get_contents(http://): failed to open stream: operation failed
[phpBB Debug] PHP Warning: in file [ROOT]/urltoico/index.php on line 265: file_get_contents(http://g.etfv.co/): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
[phpBB Debug] PHP Warning: in file [ROOT]/urltoico/index.php on line 274: file_put_contents([ROOT]/urltoico/img/.png): failed to open stream: Aucun fichier ou dossier de ce type
[phpBB Debug] PHP Warning: in file [ROOT]/urltoico/index.php on line 265: file_get_contents(http://g.etfv.co/www.sitaxa.com): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
[phpBB Debug] PHP Warning: in file [ROOT]/urltoico/index.php on line 274: file_put_contents([ROOT]/urltoico/img/www.sitaxa.com.png): failed to open stream: Aucun fichier ou dossier de ce type
Optimisation serveur et script : mysql, sql, php, apache, se

Vous aimez ? Like-Rankez ;) Like-Rank


Optimisation serveur et script : mysql, sql, php, apache, se

le Lun 3 Fév 2014 18:55

Bonjour je partage avec vous quelques optimisations/trucs personnelles.
Si vous en avez d'autre je suit preneur :)
Quand ont est mordu d'Optims on s’arrête pas au Search Engine :mrgreen:



1 - Décupler les performances de mysql

1.1 - TMPFS

Tmpfs permet de créer un dossier en mémoire vive je l'utilise pour créer le dossier des fichier temporaire de mysql.
mysql à donc un accès bien plus rapide à son système de cache.
Par rapport au disque dur, les temps de latence sont (à la louche) de l'ordre de 1000 fois moins long et les débit de l'ordre de 100 fois plus rapide
personnellement j'ai eu des gains assez impressionnant, typiquement 10 à 100 selon les requêtes et pages testées.
Comment faire.
Code: Tout sélectionner
Créer un dossier en mémoire vive avec mount
mount -t tmpfs -o size=1G tmpfs /var/tmpfs
chown -R mysql:mysql /var/tmpfs

Configurer mysql : éditer le fichier my.cnf
tmpdir = /var/tmpfs
redémarrer mysql
../etc/init.d/mysql restart

Vérifier que le type de système de fichier et bien tmpfs
stat -f -c '%T' /var/tmpfs


1.2 - Trouver les requêtes SQL les plus lentes avec mysql.
Mysql permet de loguer les requêtes les plus lentes.
Il existe un outil très pratique qui compile les informations issus du log afin de voir qu'elles sont les requêtes les plus lentes : slowquerydigest.
Voici le type d'information qu'il donne.

Code: Tout sélectionner
user@serv:~# pt-query-digest /var/log/mysql/mysql-slow.log

# 3.9s user time, 60ms system time, 28.47M rss, 82.69M vsz
# Current date: Mon Feb  3 16:28:41 2014
# Hostname: ****
# Files: /var/log/mysql/mysql-slow.log
# Overall: 18.31k total, 251 unique, 0.51 QPS, 0.20x concurrency _________
# Time range: 2014-02-03 06:25:41 to 16:28:37
# Attribute          total     min     max     avg     95%  stddev  median
# ============     ======= ======= ======= ======= ======= ======= =======
# Exec time          7123s    31us     41s   389ms   705ms      3s     3ms
# Lock time          3720s       0     34s   203ms    89us      2s    40us
# Rows sent        493.10k       0  41.75k   27.57   36.69  747.86    1.96
# Rows examine     283.10M       0 902.87k  15.83k  42.34k  64.83k   6.31k
# Query size         4.03M      21  10.53k  230.97  511.45  278.74  192.76

# Profile
# Rank Query ID           Response time   Calls R/Call  V/M   Item
# ==== ================== =============== ===== ======= ===== ============
#    1 0x5426DDC3B3C59303 3213.0224 45.1%   343  9.3674 11.17 SELECT url
#    2 0x36FC998FB633A817  312.8265  4.4%   709  0.4412  6.39 SELECT url
#    3 0x0922993E69490CF7  301.6556  4.2%    20 15.0828  7.92 CREATE TABLE top_profil
#    4 0x5A3A9D2055BD69EB  256.6551  3.6%    63  4.0739 11.35 SELECT user
#    5 0x6F5E880DC02EDCFA  192.7243  2.7%    20  9.6362 13.97 CREATE TABLE top_domain
#    6 0x763424933D4F8364  191.3124  2.7%    20  9.5656  9.79 CREATE TABLE top_sousdomain
#    7 0x94233B608927F7B9  170.3247  2.4%    84  2.0277  9.77 UPDATE url
#    8 0x02C727837AB1BE3F  162.8170  2.3%   696  0.2339 17.00 SELECT top_profil
#    9 0xAAB73D3925262636  146.1937  2.1%   396  0.3692  2.96 SELECT url
#   10 0x12610D9AF42F9615  132.4543  1.9%    48  2.7595 20.91 UPDATE url
# MISC 0xMISC              736.4139 10.3% 12112  0.0608   0.0 <216 ITEMS>

# Query 1: 0.01 QPS, 0.09x concurrency, ID 0x5426DDC3B3C59303 at byte 3771735
# This item is included in the report because it matches --limit.
# Scores: V/M = 11.17
# Time range: 2014-02-03 06:29:48 to 16:00:52
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count          1     343
# Exec time     45   3213s   101ms     41s      9s     29s     10s      4s
# Lock time     50   1880s    25us     28s      5s     21s      7s      2s
# Rows sent      0     305       0       3    0.89    0.99    0.34    0.99
# Rows examine   0     309       0       4    0.90    0.99    0.37    0.99
# Query size     1  46.74k     139     140  139.52  136.99       0  136.99
# String:
# Databases    likerank
# Hosts       *****
# Users       ******
# Query_time distribution
#   1us
#  10us
# 100us
#   1ms
#  10ms
# 100ms  ##########################################
#    1s  ################################################################
#  10s+  ########################################################
# Tables
#    SHOW TABLE STATUS FROM `likerank` LIKE 'url'\G
#    SHOW CREATE TABLE `likerank`.`url`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT * FROM `url` WHERE `domain` = '4dec7cc0a4d' and `sousdomain` = '4eae35f1b35' and `chemin` = 'd41d8cd98f0' and `page` = 'd41d8cd98f0'\G

# Query 2: 0.02 QPS, 0.01x concurrency, ID 0x36FC998FB633A817 at byte 3776712
# This item is included in the report because it matches --limit.
# Scores: V/M = 6.39
# Time range: 2014-02-03 06:26:07 to 16:28:20
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count          3     709
# Exec time      4    313s   101ms     33s   441ms   740ms      2s   241ms
# Lock time      1     66s    29us     19s    94ms    76us      1s    66us
# Rows sent     21 103.56k       0     150  149.58  143.84    7.63  143.84
# Rows examine   5  15.67M       0 183.29k  22.63k  59.57k  18.08k  16.75k
# Query size     3 136.22k     154     299  196.74  271.23   32.33  183.58
# String:
# Databases   ******
# Hosts        *****
# Users        *****
# Query_time distribution
#   1us
#  10us
# 100us
#   1ms
#  10ms
# 100ms  ################################################################
#    1s  #
#  10s+  #
# Tables
#    SHOW TABLE STATUS FROM `likerank` LIKE 'url'\G
#    SHOW CREATE TABLE `likerank`.`url`\G
# EXPLAIN /*!50100 PARTITIONS*/
SELECT * FROM `url`  WHERE  score>'.05' AND domain!='384f44574bc' AND MATCH (`content`) AGAINST ('--------------------' IN BOOLEAN MODE) order by score DESC limit 0,150\G

# Query 3: 0.00 QPS, 0.01x concurrency, ID 0x0922993E69490CF7 at byte 836372
# This item is included in the report because it matches --limit.
# Scores: V/M = 7.92
# Time range: 2014-02-03 06:30:30 to 16:00:32
# Attribute    pct   total     min     max     avg     95%  stddev  median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count          0      20
# Exec time      4    302s      1s     32s     15s     30s     11s     18s
# Lock time      7    267s   100ms     31s     13s     29s     11s     17s
# Rows sent      0       0       0       0       0       0       0       0
# Rows examine   3   9.33M 477.73k 478.01k 477.85k 462.39k       0 462.39k
# Query size     0   3.40k     174     174     174     174       0     174
# String:
# Databases    *****
# Hosts        ****
# Users       ****
# Query_time distribution
#   1us
#  10us
# 100us
#   1ms
#  10ms
# 100ms
#    1s  ##################################
#  10s+  ################################################################
# Tables
#    SHOW TABLE STATUS FROM `likerank` LIKE 'top_profil'\G
#    SHOW CREATE TABLE `likerank`.`top_profil`\G
create TABLE top_profil
SELECT domain, sousdomain, profil, SUM(score) as score,
 SUM(1s) as 1s, SUM(1m) as 1m
, SUM(1a) as 1a,url  FROM url group by domain,sousdomain,profil\G
# Converted for EXPLAIN
# EXPLAIN /*!50100 PARTITIONS*/
SELECT domain, sousdomain, profil, SUM(score) as score,
 SUM(1s) as 1s, SUM(1m) as 1m
, SUM(1a) as 1a,url  FROM url group by domain,sousdomain,profil\G

Sous debian, je l'installe comme ceci

Code: Tout sélectionner
apt-get install percona-toolkit

Configuration de mysql pour loguer les requettes lentes (et en bonus, les tables sans index).
my.cnf
Code: Tout sélectionner
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 0.1
# j'ai confugré 100ms pour loguer toutes les requêtes qui durent plus de 100ms potentiellement améliorable
log-queries-not-using-indexes = 1
#j'en profite pour loguer les requêtes qui n'utilisent pas des index pour améliorer cela aussi


grace au "log-queries-not-using-indexes", dans le log brut je peu voir des requêtes qui testent un trop grand nombre d'enregistrement à cause de défauts d'index 6769 entrées dans ce cas.
Code: Tout sélectionner
# Time: 140203  6:26:18
# User@Host:************
# Query_time: 0.003484  Lock_time: 0.000067 Rows_sent: 5  Rows_examined: 6769
SET timestamp=1391405178;
SELECT * FROM `top_profil` WHERE  `domain` = 'baf28671001' and `sousdomain` = 'bbdbe444288' and ( profil = 123456 OR `profil` = 'e08d26f35f0' OR `profil` = '786a7590c97' OR `profil` = '9ad443ee5e8' OR `profil` = '60c32758c24' OR `profil` = 'b46965c01ae'  );


1.3 En fonction de ce que l'on trouve, les optimisations peuvent être :
la création d'index secondaire pour certaines colonnes
réécrire/optimiser des requêtes
améliorer l'algorithme qui utilise ces requêtes.


2 - Delester le serveur des charges inutiles.

Pour les tâches non prioritaire : script en cron, copie de sauvegardes, etc. il est inutile de monopoliser la puissance du serveur.

2.1 - Désactiver un script PHP en cas de trop forte charge.

Certain script php ne sont pas cruciaux, l'idée est de les autoriser à ses lancer seulement si le serveur n'est pas trop chargé.

Exemple, chez moi, certains scripts (crawler, MAJ du Like-Rank, syndicateur) sont désactivé lorsque la charge du système est supérieure à 2, à vue de nez ils restent actif plus de 95% du temps.
Code: Tout sélectionner
$load = sys_getloadavg();
if ($load[0]>2)
{
   echo "trop de charge" ;
   exit ;
}


2.2 - Baisser la priorité de tâches non prioritaire (notamment en cron)

Pratique pour que des tâches non prioritaire ne ralentissent pas des tâches plus urgrente (servir le contenue web par exemple)

La commande nice est bien connue, elle permet de baisser la priorité d'exécution d'un processus (priorité d'éxecution processeur).

nice -n19

Il existe aussi un autre outil ionice, il permet de baisser la priorité d'accès d'un processus sur ses entrées/sorties (priorité d'accès aux disques dur).
ionice -c3

exemple, une entrée cron
Code: Tout sélectionner
ionice -c3 nice -n19 rm -f /usr/local/bin/php5 /var/run/monscript.php



3 Ne pas utiliser de serveur MAIl ni de serveur nom de domaine (bind par exemple).
Personnellement et pour le moment, je ne fais rien d'avancé de ce côté, donc je n'utilise pas ces serveurs.
Cela me décharge de leur gestion et libère des ressources pour le serveur.
Je me contente de créer des entrées DNS et c'est tout.
Autre bénéfice, pas de mails de spam plein le disque dur du serveur.
Niveau DNS, cela à aussi contrecarré une tentative de vol de mon nom de domaine
(attaque DDOS du port normalement utilisé par bind : cela à fait planté le port, freezé la carte réseaux lors d'un reboot, mais n'a eut aucune autres conséquence).

4 - Autres optimisation plus classiques plus orienté contenue/http.

Il existe de nombreuses source traitant de ces cas, donc je ne m'étend pas sur ce sujet.
Si vous n'avez pas fait cela il peut être intérressant de vous y intérresser
:arrow: Optimisation d'apache.
:arrow: Installation de systèmes de cache en PHP
:arrow: Optimisation des requêtes HTTP, à l'aide des outils firebug, yahoo-slow, pagespeed, etc.
:arrow: Afficher/loguer les temps de génération des pages web avec php (microtime)

Et si vous avez envie d'aller un peut plus loin dans cette direction,
vous pouvez utiliser des alternatives plus rapide à mysql et à apache, j'ai testé mais je n'ais finalement pas retrouvé mon ROI.
:arrow: Installation de nginx a la place d'apache ou le duo nginx en reverse proxy + apache
:arrow: utilisation d'un autre SDBD autre que mysql



Merci de : BrunoTWallasenzospherersw



nifrou





le Lun 3 Fév 2014 19:08     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Nifrou tu ne devrais pas afficher les structure de tes tables publiquement comme ça. Si tu as une faille 1 jour, ce sera 2 fois plus facile de tout péter.
Merci pour le partage d'experience



Merci de : mbouchaudnifrouBrunoT



pfrs91



le Lun 3 Fév 2014 19:55     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Merci pour le partage hyper technique Nifrou ;)



Merci de : nifrou



referenceur


le Lun 3 Fév 2014 20:05     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Bonsoir et merci pour les informations partagées.



Merci de : nifrou



mbouchaud



le Lun 3 Fév 2014 20:07     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

meric pfrs91, j'ai offusqué quelque info, les plus critiques.
Je pense que ce qui reste ne pose pas de problèeme, ce ne serait pas de grande utilité à un hackeur potentiel.



Merci de : pfrs91



nifrou



le Lun 3 Fév 2014 22:59     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Bonsoir Nifrou,
Merci pour le partage très intéressent ! :geek:





Wallas



le Mar 4 Fév 2014 02:19     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Merci à xavier :arrow: http://www.sitaxa.com/
qui m'a trouvé la cause de la non utilisation des index pour ce cas

Code: Tout sélectionner
# Time: 140203  6:26:18
# User@Host:************
# Query_time: 0.003484  Lock_time: 0.000067 Rows_sent: 5  Rows_examined: 6769
SET timestamp=1391405178;
SELECT * FROM `top_profil` WHERE  `domain` = 'baf28671001' and `sousdomain` = 'bbdbe444288' and ( profil = 123456 OR `profil` = 'e08d26f35f0' OR `profil` = '786a7590c97' OR `profil` = '9ad443ee5e8' OR `profil` = '60c32758c24' OR `profil` = 'b46965c01ae'  );


IN est preferable à OR pour que les index soit correctement utilisé :arrow:
Code: Tout sélectionner
SELECT * FROM `top_profil` WHERE  `domain` = 'baf28671001' and `sousdomain` = 'bbdbe444288' and profil in  (123456,'e08d26f35f0','786a7590c97','9ad443ee5e8','60c32758c24','b46965c01ae'  );



J'ait déja traité une dizaine de requête lente, il ne me reste plus qu'un cas qui me pose problème, si quelqu'un à un idée d'ou cela vient ;)
Code: Tout sélectionner

# Query_time: 0.105725  Lock_time: 0.000057 Rows_sent: 1  Rows_examined: 1
SET timestamp=1391472766;
SELECT * FROM `url` WHERE `domain` = 'bcd70f4cb17' and `sousdomain` = 'd20de1d499b' and `chemin` = 'e8010340c0d' and `page` = 'd2f9c6a09c5';

# Query_time: 0.490403  Lock_time: 0.000060 Rows_sent: 1  Rows_examined: 1
SET timestamp=1391472766;
SELECT * FROM `url` WHERE `domain` = '5993b02c21b' and `sousdomain` = 'd41d8cd98f0' and `chemin` = '12b28cd6ffd' and `page` = 'dc5fe2af3b2';

Il y à un index sur chacun des champs de la requête.
Sur phpmyadmin il me retourne bien une seule entrée (en 0,3 ms).
ha oui au passage, cette table fait + de 500 Mega octets :mrgreen:





nifrou



le Mar 4 Fév 2014 02:54     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Bonsoir Nifrou,

Ce n'est pas déconseillé de faire SELECT * (all) ? ( point de vue performance. )
J'ai toujours lu que point de vue performances c'est mieux d'éviter l'étoile (all),
et donc de sélectionner que ce que l'on a besoin.
SELECT champ_1, champ_2, champ_5 FROM

Enfin, c'est juste une remarque. :wink2:
je ne sais pas si la requête que tu nous montre (le rapport) est la même dans ton code.
Donc c'est une simple remarque, si ça peut être utile.
Perso, j'évite le SELECT *

Ne pas sélectionner ce dont vous n’avez pas besoin
Une façon très courante pour obtenir les données souhaitées est d’utiliser le symbole *, qui va faire tous les champs de la table souhaitée:

Code: Tout sélectionner
SELECT * FROM wp_posts;

Au lieu de cela, vous devez absolument sélectionner uniquement les champs souhaités comme indiqué dans l’exemple ci-dessous. Sur un site très petites, disons, un visiteur par minute, qui ne serait pas faire la différence. Mais sur un site comme les tchats, il évite beaucoup de travail pour la base de données.

Code: Tout sélectionner
SELECT title, excerpt, author FROM wp_posts;


Source: http://mayeul.com/10-astuces-sql-pour-a ... e-donnees/





Wallas



le Mar 4 Fév 2014 04:10     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Une petite astuce,

Pour améliorer les performances Smarty ( que tu utilise ici sur le forum )
et donc pour améliorer les temps d'affichages des pages.

Il y a une petite astuce facile à mettre en place,
Elle consiste à "Minyfier" le code des fichiers compilés enregistrés dans le dossier -> /smarty_compile/
( mélange de Php et de Html ) c'est un avant cache, ensuite ils permettent de construire les pages.

Dans le fichier -> /smarty/Smarty_Compiler.class.php

Juste après ce code:

Code: Tout sélectionner
$compiled_content = $template_header . $compiled_content;
        return true;
    }


On rajoute:

Code: Tout sélectionner
/*************** HACK Minify HTML / COMPRESS CODE *******************/
$compiled_content = trim(preg_replace('/((?<!\?>)\n)[\s]+/m', '\1', $compiled_content));
$compiled_content = preg_replace('#<!--//.*?-->#s', '', $compiled_content);
$compiled_content = preg_replace("/(\r\n|\n|\r)/", "", $compiled_content);
$compiled_content = str_replace(CHR(13).CHR(10),"",$compiled_content);
$compiled_content = preg_replace("/(\n\n|\n\n\n)/", "", $compiled_content);
$compiled_content = preg_replace("#>(\s+)<#s", "><", $compiled_content);



Ensuite, pour vérifier que ça fonctionne, dans le dossier -> /smarty_compile/
Le code des fichiers doit être mynifié. ( pas de saut à la ligne etc ... )

ça permet de gagner un peux en temps d'affichages des pages lorsque l'on utilise Smarty. :geek:





Wallas



le Mar 4 Fév 2014 14:28     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Merci pour ces conseils :happy:





enzosphere


le Mer 5 Fév 2014 18:09     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Merci pour les conseils, je garde ça bien au chaud.





tanrouge


le Mer 5 Fév 2014 18:31     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

Pour la partie nginx versus Apache, les gains de performance sont toujours compliqués à obtenir. Pour que nginx devienne vraiment intéressant, il faut avoir un trafic avec beaucoup d'objets différents, c'est à dire servir des pages complexes différentes à des utilisateurs connectés.
Quand on sert de la page "anonymous" (non personnalisée), utiliser une bonne stratégie de cache est toujours plus efficace qu'utiliser un autre moteur qu'Apache.

Le grand classique est d'utiliser Varnish, mais on peut avoir des stratégies encore plus old school en créant des versions statiques d'un site, placées sur des serveurs avec un round robin en frontal. Le seul souci est ensuite la synchronisation lors des changements et la gestion du back office, mais ce n'est pas la mort non plus.





SylvainP



le Jeu 20 Fév 2014 11:25     Re : Optimisation serveur et script : mysql, sql, php, apache, se      

J'ait déjà traité une dizaine de requête lente, il ne me reste plus qu'un cas qui me pose problème, si quelqu'un à un idée d'ou cela vient ;)

# Query_time: 0.105725 Lock_time: 0.000057 Rows_sent: 1 Rows_examined: 1
SET timestamp=1391472766;
SELECT * FROM `url` WHERE `domain` = 'bcd70f4cb17' and `sousdomain` = 'd20de1d499b' and `chemin` = 'e8010340c0d' and `page` = 'd2f9c6a09c5';

# Query_time: 0.490403 Lock_time: 0.000060 Rows_sent: 1 Rows_examined: 1
SET timestamp=1391472766;
SELECT * FROM `url` WHERE `domain` = '5993b02c21b' and `sousdomain` = 'd41d8cd98f0' and `chemin` = '12b28cd6ffd' and `page` = 'dc5fe2af3b2';


Il faut ajouter explain devant chaque select pour avoir le détail des clé, index etc. utilisés.

Il ne faut pas utiliser le select * car si demain ta table est vouée à grandir ou d'avoir des champs qui prennent de la ram (text, longtext etc.), la ram sera utilisée lors de la requête (et réservée pour la taille du champs) alors que tu ne vas pas l'utiliser à la fin (idem si tu fais des jointures etc.)

Pour ces requêtes tu peux également faire un index unique sur l'union des 3 champs, ce qui sera plus rapide à la lecture sur ces requêtes (et tu perdras un peu sur les insert et update).

Enfin, il y a les select SQL_CACHE etc. qui peuvent t'aider à gagner du temps





sitaxa





Retourner vers Le blog de Webmaster Rank

 


  • Articles en relation
    Réponses
    Vus
    Dernier message
Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 1 invité
 


  • Information sur les posteurs
  • Wallas

    Impliqué
    Remerciements : 585
    Avatar du membre
    Le Forum pour les annuairistes
    2172 Messages
    3 sur ce sujet
    Inscription Jan 2011
    site web
  • nifrou

    Administrateur
    Remerciements : 862
    Avatar du membre
    Conseil n°1 : Grace au Like-Rank, notez et promouvez vos contenus les plus interressant
    3040 Messages
    3 sur ce sujet
    Inscription Fév 2008
    site web
  • SylvainP

    Débutant
    Remerciements : 11
    Avatar du membre
    33 Messages
    1 sur ce sujet
    Inscription Juil 2013
    site web
  • enzosphere

    Occasionnel
    Remerciements : 32
    Avatar du membre
    93 Messages
    1 sur ce sujet
    Inscription Mai 2013
  • mbouchaud

    Occasionnel
    Remerciements : 50
    Avatar du membre
    157 Messages
    1 sur ce sujet
    Inscription Jan 2013
    site web
  • pfrs91

    Habitué
    Remerciements : 86
    Mon blog SEO / Web Jeromeweb.net
    312 Messages
    1 sur ce sujet
    Inscription Oct 2012
    site web
  • referenceur

    Régulier
    Remerciements : 160
    Avatar du membre
    Abondance : Actualités SEO et Référencement
    2372 Messages
    1 sur ce sujet
    Inscription Oct 2009
  • tanrouge

    Régulier
    Remerciements : 152
    Avatar du membre
    Décrouvrez enfin une Alternative à ADSENSE...
    631 Messages
    1 sur ce sujet
    Inscription Aoû 2012
  • sitaxa

    Nouveau
    1 Messages
    1 sur ce sujet
    Inscription Fév 2014

allez en bast