Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2887 connectés 

 


Dernière réponse
Sujet : OVH je vous hai ... mais pas tant que ça
imcdb le prob est résolu de toutes façons depuis que j'ai réécrit toutes mes requêtes.

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
imcdb le prob est résolu de toutes façons depuis que j'ai réécrit toutes mes requêtes.
[Albator]

Maho-kun a écrit :

Bah je sais pas trop mais ça faisais du 500 requete ttes les 3 minutes environ, après je sais pas comment faire pour connaître la BP utilisée ni le % pross, comme c justement du mutualisé.


 
500/180, pour simplifier on va dire que ça fait 3 requêtes par seconde.
Ce qui est ridiculement bas, donc ce n'est pas au niveau de SQL que tu consommes :)

Maho-kun

3Phach4 a écrit :

chargé ca veut pas dire grand chose. je me suis fait viré de chez OVH car j'avais un traffic de 80 mbits/s sur du mutualisé, ca c'est ce que j'appelle chargé.


Bah je sais pas trop mais ça faisais du 500 requete ttes les 3 minutes environ, après je sais pas comment faire pour connaître la BP utilisée ni le % pross, comme c justement du mutualisé.

3Phach4

Maho-kun a écrit :

J'ai un site bittorent, parfois bien chargé lors d'1 sortie, chez OVH en mutualisé depuis 1an½ ou +, et j'ai jamais eu de soucis :s...


 
chargé ca veut pas dire grand chose. je me suis fait viré de chez OVH car j'avais un traffic de 80 mbits/s sur du mutualisé, ca c'est ce que j'appelle chargé.

Maho-kun J'ai un site bittorent, parfois bien chargé lors d'1 sortie, chez OVH en mutualisé depuis 1an½ ou +, et j'ai jamais eu de soucis :s...
Sly Angel Normalement ça revient au même, niveau traitement MySQL c'est la même chose entre ta jointure et faire les 2 séparées, sauf si tes index ne sont pas correctement mis sur les champs id.
 
ex :


mysql> EXPLAIN SELECT * FROM serveur,contact WHERE serveur.id=8 and serveur.id=contact.id;
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table   | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | serveur | const | PRIMARY       | PRIMARY |       3 | const |    1 |       |
|  1 | SIMPLE      | contact | const | PRIMARY       | PRIMARY |       2 | const |    1 |       |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
2 rows in set (0.00 sec)
 
mysql> EXPLAIN SELECT * FROM serveur WHERE serveur.id=8;
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table   | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | serveur | const | PRIMARY       | PRIMARY |       3 | const |    1 |       |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)
 
mysql> EXPLAIN SELECT * FROM contact WHERE id=8;
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table   | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | contact | const | PRIMARY       | PRIMARY |       2 | const |    1 |       |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)


 
C'est pareil ;)
 
Sinon l'intérêt aussi de la jointure, c'est quand même de pouvoir la faire en faisant un WHERE sur une condition non commune aux 2 tables, du style :
 
SELECT * FROM table1, table2 WHERE table1.client="marcel" AND table1.id=table2.id;
 
Important à ce moment là d'avoir les index adaptés pour table1.client, table1.client et table2.client.

[Albator] Forcément si tu fais une requête sur plusieurs tables sans jointure, tu reçois en résultat le produit cartésien des tables; par exemple, si tu as 2 tables avec 100 enregistrements chacune, une requête sans jointure te retourne 100*100 = 10000 lignes: ça met vite un serveur à genoux !
 
Par contre j'ai pu constater à force de jouer avec mysql, que pour les petites sélections (genre une seule ligne), il vaut mieux utiliser 2 requêtes sur 1 table chacune que 1 requête sur les 2 tables, avec jointure.
 
Ex:
SELECT * FROM table1 WHERE id=4;
SELECT * FROM table2 WHERE id=4;
est plus rapide que:
SELECT * FROM table1, table2 WHERE table1.id=4 AND table1.id=table2.id;
 
Mais ça dépend peut-être aussi du type de table. Je pense que mysql fonctionne mieux avec beaucoup de "petites" requêtes qu'avec des "grosses"... Enfin, c'est ce que j'observe sur mon serveur, ça n'est pas une vérité absolue :)
imcdb maintenant, ca va mieux...  ca tourne mieux.
Spacewanker Et juste pour info. Tu sais combien de requetes tu envoyait par jour vers le serveur quand tu était sur OVH ?
imcdb c'est pas super rapide parce que mon serveur MySQL croule sous mes requetes pas optimisées... mais ca va aller mieux maintenant que j'ai pigé le principe des jointures SQL :)
Sly Angel Apparement c'est bon :) C'est pas super rapide, mais ça doit être la connexion là ( c'est sur les images la première fois )
imcdb non, c'est sur. A ce propos, je suis passé en hébvergement local (chez moi, quoi)
 
ccédez-vous au site de l'extérieur ?
juste pour savoir si j'ai tout bien configuré ?
Sly Angel En même temps combien tu payes pour ce mutualisé ? Faut-il vraiment s'attendre à un service impeccable quand ça coûte 3 fois rien ?
[Albator] J'avais le même genre de pb en mutualisé chez ovh. Dès que tu veux utiliser un peu les moyens mis à disposition, ça gueule que tu consommes trop de ressources...
 
En fait l'idéal pour eux serait un site constitué uniquement de pages statiques et d'images. Pas de PHP, pas de SQL, ça consomme trop de ressources.
angefox aie :)
imcdb j'hallucine !!!!
Ma base est encore desactivée ! ca fait TROIS fois cette semaine !!
j'en peux plus.
 
je vais héberger le jeu chez moi, en fin de compte.
[Albator] Ha, les joies du mutualisé :)
imcdb finalement, meme s'ils sont lents et ne disent jamais d'ou vient le prob, grace a eux mon site tourne quand meme.  
 
et pour info, le blaireaux c'est moi : j'avais une table avec une clé primaire qui devait pouvoir etre dupliquée. et un champ appelé "procédure", alors que ce nom est une fonction SQL.
 
Donc mea culpa...
imcdb c'est trop fort. Je les joints par telephone a 14h55. 15h25 => c'est réglé.
comme quoi.  
 
Moralité; des qu'il y a un prob, je les appelle !ouf, ils ont sauvés SimCarriere.
angefox Oui c'est un gros soucis ca, dès qu'ils reactivent sauvegarde et demenage...
imcdb oui, mais la ca se depasse, un tel j'menfoutisme. Quand je vois les heures que je passe à répondre aux mails et aux MP que les joueurs de SimCarriere m'envoyent sans arret, et je me dis que j'en suis meme pas salarié...
OVH ne fait ca que pour l'argent. Et je peux meme pas recupérer ma base pour aller chez un autre hébergeur, car elle est désctivée, donc impossible à sauvegarder...
angefox C'est poour ca qu'il faut eviter a tout prix ovh.. ;)
imcdb je precise que la faiute m'incombe car j'ai utiliser des  
SELECT + FROM au lieu de SELECT count(*) FROM  
 
dans bien des requêtes, et je comprends la surcharge aisni générée.
Mais leur atttitude et la nonchalence affichées me mettent hors de moi.
imcdb salut a tous,
 
voila que OVH m'envoi un mail, stipulant que mes requetes SQL surchargent le serveur. Hier meatin, 10h. ils me disent, confirmez nous par retour de mail que vous ferez le necesssairte, et votre site sera de nouveau accessible. Aucun avertissement prealable... 13h30 hier je renvoi le mail disant que je fdais les chgt de scripts necessaire, et que je confirme pour reactiver ma base SQL.
resultzt, 24h plus tard, toujours plus aucune base de données dispo sous phpmyadmin, alors que mon amnager ovh indique qu'elle existe (ils l'ont desactivé). donc aucune restauration possible, rien n'y fait.
 
OVH, je vous hai !!!

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)