OVH Cloud OVH Cloud

PhpNet en vrac

96 réponses
Avatar
Spontex
Bonjour,

Je poste mon message ici car il m'est impossible de contacter
PhpNet.org, mon hébergeur, suite à une panne de la base de données du
serveur 1 depuis 13h45 (cf. http://www.phpnet.org/forum/ pour une démo !)
En effet, l'astreinte téléphonique n'est pas assurée en cette période de
vacances, et les autres moyens de signaler les pannes sont le forum, et
le panel de gestion du site. Ils reposent tous les deux sur cette
fameuse base cl1-sql1, qui est en panne. C'est donc la fête, donc,
d'autant qu'en ce moment, les défaillances de cette base de données qui
affectent tantôt une table, tantôt une autre, et obligent à réparer ces
tables sont nombreuses !

J'espère que ce sera vite réparé, et j'invite les autres utilisateurs
victimes de cette panne à en discuter ici.

Cordialement

10 réponses

Avatar
BlueWhisper
webvisio wrote:
ce qui n'est pas normal c'est que tu n'a pas configuré tes machines pour
eviter
des process qui durent autant de temps
exemple tu met un fichier my.cnf dans le rep /etc/
qui limite la durée des process mysql
[mysqld]
set-variable = wait_timeout0
set-variable = max_connections0

hébergeur est un metier tu sais......
et franchement partir en vacances en laissant les clients se debrouiller
n'est pas preuve de professionalisme...
il faut dans ce cas virer de tes pages
assistance 7/7 365/ans et remplacer par
attention cher membre ( pas clients) nous sommes en vacance et nous ne
pouvons assurer la hot line pendant ce temps.....

Il était pas en vacance, il était en déplacement pour aller à paris (au

RedBus) donc merci de lire un peu ce qu'il dit...

Faudra également que tu m'expliques comment changer la ram par
télépathie, ça m'intéresserait...

Sincèrement,

Laurent Fasnacht

Avatar
BlueWhisper
julien wrote:
un serveur mutualisé bien configurée empêche ce genre de requéte pour
éviter les dérives, non ?
Ou c'est parce qu'il est surchargé qu'une requéte prend autant de temps ?


À ma connaissance il n'existe pas de bon moyen pour limiter la durée
d'éxécution des requêtes (et puis même si tu t'arranges pour en mettre
un, tu peux être sûr que tous tes clients vont râler à partir du moment
où ils essaient de générer des index ou des trucs comme ça).

De toute façon, quelqu'un qui programme mal (ne parlons même pas de la
personne de mauvaise volonté) peut mettre à mal tout un cluster...

J'ai hébergé il y a un temps un site du genre. ça m'a saturé 2 machines
parce que ce gars savait pas les LIMIT et ORDER BY en mysql, et
n'utilisait pas de champ "id" avec lequel il ferait un join, mais le
pseudo en entier dans toutes les tables (et sans index bien sûr).

Sincèrement,

Laurent Fasnacht

Avatar
BlueWhisper
Anthony wrote:
Je veux justement car j'en ai marre d'être pris pour une vache à lait ne pas
conseiller PHPNET aux autres futurs client potentiels.


Pour ce que tu paies, j'estime que c'est loin de ce qu'on peut appeler
une vache à lait... de plus, j'ai l'impression qu'il y a quelques
milliers de clients satisfait, et 1 ou 2 mécontents...

Je me demande ce que diraient ceux de frih, si tout le monde de content
de phpnet commençait un thread pour le dire. ça ferais un joli flood je
pense.

Anthony wrote:
Quant au terme "flooder" il est vraiment inaproprié, je poste un message
simplement.
Un message oui, mais un message sur tous les forums où il y a un message

de phpnet (même datant d'une année) j'appelle ça un flood.

Anthony wrote:
[...]faire pire que PHPNET ce n'est pas possible, faut vraiment être
mauvais [...]


Je peux te citer au moins 20 hébergeurs pire que phpnet. Le premier dont
j'ai eu à être mécontent est franceonline, j'ai plusieurs hébergeurs qui
m'ont viré mon site pour surconsommation sql (les requêtes sont légères,
mais y'en a beaucoup, environ 2-3/s le soir). De plus, je ne compte pas
les hébergeurs incompétents (par ex ceux qui ne désactivent pas l'AXFR,
qui laissent des failles énorment (SQL injection par ex)).

C'est pas vrai ça c'est à croire que d'être mécontent de PHPNET
ça soit interdit. J'en suis mécontent, je le déconseille. Bientôt tu
trouveras des posts disant que je suis content d'un autre hébergeur (). Ce qui
compte c'est le respect du client, les problèmes passons. J'étais avant chez
un autre hébergeur qui a fermé ces portes. (Tu t'en fous mais attends). Cet
hébergeur était aux petits ognions avec ses clients (bien que les patrons
avaient un travail, un peu comme Thibaud et PHPNET). Tu demandais un truc au
support (par mail ou dans les forums), tu avais une réponse moins d'une
heure après avoir posté. Il y a eu quelques gros problème (genre passage
d'un paramètre à Off, désolé mais je ne sais plus lequel) qui a engendré un
immense problème sur des dizaines de sites (ceci était du à un mec qui
pouvait lire tous les dossiers des utilisateurs, donc le paramètre était
nécessaire à changer). (ne me donne pas l'argument de la mauvaise
programmation ce n'est pas les registers globals qui ont été passés à Off).
Enfin pour dire que moi j'ai réadapté mon script (mais ça ne m'a pas
dérangé). Un autre client qui ne pouvait pas faire autrement et bien les
admins lui ont réactivé ce paramètre (pas la peine de me dire htaccess, le
paramètre n'était pas modifiable via cette voie) rien que pour lui !!!


Cet hébergeur devait avoir peu de clients. Il est facile, lorsque l'on a
quelques centaines de clients, de faire du support "personnalisé" pour
chacun. Essaie de faire ça avec 3000+ clients... Si chaque client te
demande 10 min, ça te fait... 62 jours à temps plein (8h / jour) :)

Je pense que si cet hébergeur a fermé ses portes, il devait bien y avoir
une raison financière.

2 euros par mois, oui moins cher que PHPNET. Leurs serveurs étaient ultra
rapides (bien plus que chez PHPNET). Dommage qu'ils aient fermé (pas de
numéro de siret, et des concurrents les ont emm..dés pour ça)


Si y'a peu de monde sur un serveur, c'est plutôt normal que ça aille
rapidement. De plus, s'ils n'ont pas de numéro siret, ils échappent
probablement à toutes les réglementations en vigueur, ce qui prouve le
manque de sérieux de cet hébergeur.

Donc pourquoi je suis encore chez PHPNET ?

Simple, la fin de mon abonnement (payable par an....) se poursuit jusqu'à
novembre. Je partirai bien avant cependant, las d'une fiabilité déplorable
et SURTOUT de la communication absente ou irrespectueuse envers le client.


S'il est vrai que la communication fait parfois défaut, elle est
toujours respectueuse (bon je pense que si tu te fous de lui, il est
bien possible qu'il perde patience, comme ce qui va bientôt m'arriver à
force de poster)

Sincèrement,

Laurent Fasnacht

Avatar
julien
BlueWhisper wrote:
julien wrote:
un serveur mutualisé bien configurée empêche ce genre de requéte pour

éviter les dérives, non ?
Ou c'est parce qu'il est surchargé qu'une requéte prend autant de temps ?



À ma connaissance il n'existe pas de bon moyen pour limiter la durée
d'éxécution des requêtes (et puis même si tu t'arranges pour en mettre
un, tu peux être sûr que tous tes clients vont râler à partir du moment
où ils essaient de générer des index ou des trucs comme ça).


biensur il en existe un!
Et en programmant bien on peu toujours contourner ce problème, mais dans
ce cas on programme bien...


De toute façon, quelqu'un qui programme mal (ne parlons même pas de la
personne de mauvaise volonté) peut mettre à mal tout un cluster...

J'ai hébergé il y a un temps un site du genre. ça m'a saturé 2 machines
parce que ce gars savait pas les LIMIT et ORDER BY en mysql, et
n'utilisait pas de champ "id" avec lequel il ferait un join, mais le
pseudo en entier dans toutes les tables (et sans index bien sûr).


Dans ce cas se client n'aurait pas mis à mal le cluster, si c'était bien
configuré pour éviter les abus.
Le client aurait simplement vu un message d'erreur disant que la requête
est trop longue, sans géner les clients à cote à aucun moment!


Sincèrement,

Laurent Fasnacht



Avatar
Anthony
S'il est vrai que la communication fait parfois défaut, elle est
toujours respectueuse (bon je pense que si tu te fous de lui, il est
bien possible qu'il perde patience, comme ce qui va bientôt m'arriver à
force de poster)


Bien sûr !

C'est toujours de la faute du client avec PHPNET et ça y'en a marre. Je peux
te sortir des archives zip de clients mécontents quand Thibaud disait par
exemple que la cause d'un gros problème était la clim de chez Ovanet (il y a
deux clims chez Ovanet, pourquoi ne pas avoir avoué que le problème venait
de chez lui ?)

Maintenant si tu es un ami de Thibaud on peut comprendre, tout comme les
autres pro-phpnetiens du forum (ils se reconnaîtront), ils ont même fondé
"l'association des phpnetiens unis" voir opu.phpnet.org. Leurs avis ne
peuvent donc être objectifs, tout comme le tient puisque étant en dédié tu
es hors sujet dans ce post. Va plutôt vanter les mérites de PHPNET dans le
domaine du dédié...

Avatar
BlueWhisper
Anthony wrote:
C'est toujours de la faute du client avec PHPNET et ça y'en a marre. Je peux
te sortir des archives zip de clients mécontents quand Thibaud disait par
exemple que la cause d'un gros problème était la clim de chez Ovanet (il y a
deux clims chez Ovanet, pourquoi ne pas avoir avoué que le problème venait
de chez lui ?)


Euh, sans vouloir te contredire (mais je le ferais malgré tout) ovanet
n'assure pas la climatisation. Ils sont uniquement fournisseur de bande
passante et d'ip. Le datacenter c'est Redbus Interhouse, et c'est eux
qui sont responsable de la clim et de l'alimentation électrique.

Enfin quoi qu'il en soit je ne vois guère comment est-ce que thibaud
pourrait être responsable de la clim. (et encore moins d'un problème de
celle-ci)

Maintenant si tu es un ami de Thibaud on peut comprendre, tout comme les
autres pro-phpnetiens du forum (ils se reconnaîtront), ils ont même fondé
"l'association des phpnetiens unis" voir opu.phpnet.org. Leurs avis ne
peuvent donc être objectifs, tout comme le tient puisque étant en dédié tu
es hors sujet dans ce post. Va plutôt vanter les mérites de PHPNET dans le
domaine du dédié...


C'est marrant, selon toi c'est que les avis négatifs sur phpnet qui
peuvent être objectifs. De plus, j'argumente mes dires, ce qui est le
summom de la non-objectivité :)

Je te rappellerais que les membres de l'opu (je n'en fais pas partie
d'ailleurs) ne reçoivent rien de phpnet, il s'agit uniquement d'un
système d'entraide, d'amélioration d'entente, et d'un petit délire aussi.

Je ne vois donc pas en quoi ces membres seraient non-objectifs (il n'y
aurait aucun intérêt pour eux).

Amicalement,

Laurent Fasnacht

Avatar
julien


S'il est vrai que la communication fait parfois défaut, elle est
toujours respectueuse (bon je pense que si tu te fous de lui, il est
bien possible qu'il perde patience, comme ce qui va bientôt m'arriver à
force de poster)

Sincèrement,

Laurent Fasnacht



Sur ce newsgroup phpnet a rarement était respecteux envers les clients
dans ses propos.
Que le client soit "casse couille" ou non, il n'y a pas d'excuse à
perdre ou non patience, si on agit professionnelement.

Avatar
BlueWhisper
julien wrote:
BlueWhisper wrote:

julien wrote:
un serveur mutualisé bien configurée empêche ce genre de requéte pour

éviter les dérives, non ?
Ou c'est parce qu'il est surchargé qu'une requéte prend autant de
temps ?




À ma connaissance il n'existe pas de bon moyen pour limiter la durée
d'éxécution des requêtes (et puis même si tu t'arranges pour en mettre
un, tu peux être sûr que tous tes clients vont râler à partir du
moment où ils essaient de générer des index ou des trucs comme ça).



biensur il en existe un!
Et en programmant bien on peu toujours contourner ce problème, mais dans
ce cas on programme bien...

Bah évidemment, tu peux faire un truc qui kill les thread MySQL de plus

de 15s par ex... seulement là tu es mal si tu dois générer un index...
de plus ça ralerait beaucoup si cette protection était mise en place, je
peux te le garantir...

De toute façon ce n'est pas ça qui a créé le problème au niveau sql...
c'est uniquement son site qui a dépassé le nombre de connexions sql
utilisées à cause de ça...

D'ailleurs à ma connaissance il y a un script qui verrouille les bases
des trop gros consommateurs (ce qui a fait des histoires d'ailleurs).

J'ai hébergé il y a un temps un site du genre. ça m'a saturé 2
machines parce que ce gars savait pas les LIMIT et ORDER BY en mysql,
et n'utilisait pas de champ "id" avec lequel il ferait un join, mais
le pseudo en entier dans toutes les tables (et sans index bien sûr).


Dans ce cas se client n'aurait pas mis à mal le cluster, si c'était bien
configuré pour éviter les abus.
Le client aurait simplement vu un message d'erreur disant que la requête
est trop longue, sans géner les clients à cote à aucun moment!


une requête de 3s c'est trop long pour toi? Les requêtes n'étaient pas
excessivement longues, mais beaucoup trop pour ce que ça aurait dû être
(0.02s avec index, limit et order by)... Le gaillard faisait 20Go de
traffic par jour... normalement ça aurait du passer sans pb, mais à
condition d'avoir un truc un peu optimisé.

Pour ce client, la solution employée a été de mettre un sleep de 3s
avant chaque page, mais je doute ce soit une bonne solution pour phpnet ;)

N'empêche pour la "dérive hors-sujet" on fait pas mal... surtout quand
on sait que phpnet a été victime d'un problème matériel et non logiciel.

Sincèrement,

Laurent Fasnacht



Avatar
BlueWhisper
julien wrote:


S'il est vrai que la communication fait parfois défaut, elle est
toujours respectueuse (bon je pense que si tu te fous de lui, il est
bien possible qu'il perde patience, comme ce qui va bientôt m'arriver
à force de poster)

Sincèrement,

Laurent Fasnacht




Sur ce newsgroup phpnet a rarement était respecteux envers les clients
dans ses propos.
Que le client soit "casse couille" ou non, il n'y a pas d'excuse à
perdre ou non patience, si on agit professionnelement.


A ma connaissance, les seuls clients à commencer un thread ici sont ceux
qui nous les cassent déjà sur le forum à longueur de journée... jsuis
désolé de le dire ainsi, mais à mon avis c'est amplement mérité pour
ceux-ci. (avis personnel qui n'engage que moi, et dont je ne souhaite
pas de réponse)

Sincèrement,

Laurent Fasnacht


Avatar
Anthony
Euh, sans vouloir te contredire (mais je le ferais malgré tout) ovanet
n'assure pas la climatisation. Ils sont uniquement fournisseur de bande
passante et d'ip. Le datacenter c'est Redbus Interhouse, et c'est eux
qui sont responsable de la clim et de l'alimentation électrique.


Désolé c'était Claranet (j'ai confondu avec Ovanet). En fait quand PHPNET
avait eu un gros problème l'excuse de Thibaud c'était "c'est la clim de
claranet qui déconne". Un petit contact chez Claranet te fesait passer pour
un c.. puisqu'ils ont deux systèmes de climatisation.

Pourquoi ne pas avoir avoué sa responsabilité ?

Enfin quoi qu'il en soit je ne vois guère comment est-ce que thibaud
pourrait être responsable de la clim. (et encore moins d'un problème de
celle-ci)


Heu j'ai bien dit ça dans mon post tu es sûr ?

C'est marrant, selon toi c'est que les avis négatifs sur phpnet qui
peuvent être objectifs. De plus, j'argumente mes dires, ce qui est le
summom de la non-objectivité :)


Non il n'y a pas que les avis négatifs qui sont objectifs. Le rapport
qualité/prix de PHPNET est excellent, seulement les avis négatifs sont tout
de suite censurés, c'est donc qu'ils dérangent. Si ils dérangent, ils sont
objectifs. Quant à ton "argumentation" laisse nous en juger...

Je ne vois donc pas en quoi ces membres seraient non-objectifs (il n'y
aurait aucun intérêt pour eux).


Les avis positifs sont souvent postés par les mêmes personnes (tout comme
les avis négatifs me diras-tu), et comme par hasard la grande majorité de
ces personnes ont des liens rapprochés avec Thibaud (qui est modé sur le
chat par exemple ? Ceux qui donnent des avis positifs sans même avoir
d'arguments solides).

Quand on fait une remarque sur une mise à jour de PHP on nous fait des
insinuations merdiques (je cite Alex dans ce topic qui visiblement ce fout
de la gueule du client puisqu'il n'a rien d'autre à dire pour défendre
PHPNET)

http://www.phpnet.org/forum/index.php?showtopicY25

et Apache 2 ?
Voila, comme ça, on a tout fait, on est tranquille...


Et après on est respectueux du client...
Pfff argumentes mieux la prochaine fois.