dans la famille Mutualisé, je me demande ce que vaut Infomaniak...
<http://www.infomaniak.ch/>
Il pourrait (notamment) présenter l'intérêt pour moi de permettre de
partager des données Outlook sur leurs serveurs via WebMail Sync...
Globalement, que pensez-vous de leur service ?
Merci pour vos infos.
Paul
> Globalement, que pensez-vous de leur service ?
Rien : ils ont à l'époque refusé d'héberger notre site associatif sous
prétexte que certaines photos, à vocation manifestement purement médicale,
y sont trop "déshabillées". Nous sommes donc alléEs sans regrets chez des
voisins à eux... et pour moins cher, en plus. Un hébergeur qui a à tel
point, et de façon préemptive, une peur irrationnelle du gendarme ne nous
intéresse pas : nous savons nous censurer tout seulEs...
Cornelia
--
Be out and be proud - today is the first day of the rest of your life
Support Transgenre Strasbourg : http://www.sts67.org
BoW : http://www.bownbend.com
GPG key ID 83FF7452, 659C 2B9F 7FD5 5C25 8C30 E723 4423 F8B8 83FF 7452
> Bonjour,
salut,
j'ai deux sites chez eux, rien à dire
trés bon service. support disponible et à l'ecoute, et puis ca tourne
simplement trés bien.
Voila.
Ca fonctionne toujours.
Mais, un peu à l'image de ce que dit Cornelia, ils refusent toute modif,
il n'y a aucune permissivité : par exemple, quand j'y étais, il était
impossible d'utiliser exec, passthru, system en php.
Impossible d'installer pas mal de solution de paiement en ligne.
Bref, je suis parti.
Facile d'être sécurisé lorsqu'on ne permet rien...
> Nous sommes donc alléEs sans regrets chez des
> voisins à eux... et pour moins cher, en plus
Euh... chez qui ?
> paul <paul....@alussinan.org> wrote :
>
> > Globalement, que pensez-vous de leur service ?
>
> Serveurs localisés en Suisse aux dernières nouvelles donc
> référencement un peu moins bons des sites francophones par rapport
> aux hébergeurs implantés en France.
Allez, siouplait, recommandez-moi un bon mutualisé, pas trop cher, pas
usine à gaz et plus sympa qu'OVH...
;-)
www.crémière.net ? ;-)
> Euh... chez qui ?
D'abord chez un hébergeur du Liechtenstein, mais qui n'existe plus (ça date
de trois ans environ), ensuite chez un autre Suisse, et maintenant chez des
Canadiens. Détails par PM, si tu veux.
sivit
celeonet ?
>
> celeonet ?
pour fréquenter un site & forum hebergé chez eux, je ne saurais les
conseiller. Le forum & le site sont parfois super lent, des fois
innaccessible... a éviter...
Juste par curiosité : vous pouvez m'expliquer ça ? Naïvement, je
croyais le référencement mondial.
Si tu n'indique pas:
- Ton FAI
- Ton type de connexion à internet
- (éventuellement) Ta localisation au moment de ces dysfonctionnement
Alors ce que tu affirmes n'est pas tout à fait valable.
En effet, certains FAI ont une connectivité "avantagée" vers certains
FSI/hébergeur, en fonctions de leurs accords techniques et commerciaux.
Et qui dit "avantagée" dit "au détriment" des autres ...
--
Huile Essentielle de Camphre http://www.huile-camphre.fr
Infogerance http://www.infogerance.us
(Serveurs, Postes de travail, Développement logiciel)
> Phach wrote:
>>> celeonet ?
>> Le forum & le site sont parfois super lent, des fois
>> innaccessible... a éviter...
>
> Si tu n'indique pas:
> - Ton FAI
> - Ton type de connexion à internet
> - (éventuellement) Ta localisation au moment de ces dysfonctionnement
>
> Alors ce que tu affirmes n'est pas tout à fait valable.
> En effet, certains FAI ont une connectivité "avantagée" vers certains
> FSI/hébergeur, en fonctions de leurs accords techniques et commerciaux.
> Et qui dit "avantagée" dit "au détriment" des autres ...
>
Orange, 8 mega ! j'ai pas tenu bon de le préciser car je pense pas avoir un
provider ou une localisation farfelu.
IMHO, les ralentissements proviennent plus de l'infra technique au niveau
serveur (Mysql, etc) que du reste... meme si la connectivité joue beaucoup,
aller jusqu'au timeout sans afficher la page d'un forum, hum...
je parle bien de navigation, donc d'affichage de pages relativement légère
en terme de poids.
c'est bien simple, j'ai conseillé à l'admin de changer son phpBB pour un
SMF (pour cause de spam incontrolable entre autre) ce qu'il a fait et
depuis les ralentissements sont moins fréquents et les erreurs sont moins
fréquentes.
perso je sais pas si c'est une légende ou non, mais je constate aucun
probleme de référencement pour mon site chez infomaniak.
Si le site est bien fait, y a pas de raison d'être moins bien référencé
Je précise, je m'occupe du site FR d'une chanteuse anglaise connue, le site
et forum sont hebergés chez infomaniak.
J'ai tenté l'expérience suivante qui vaut ce qu'elle vaut, voici :
google.fr / page web : 1er résultat sur le nom de la chanteuse.
google.fr / page francophone : 1er résultat sur le nom de la chanteuse.
google.fr / page France : 1er résultat sur le nom de la chanteuse.
yahoo.fr avec les 3 memes options : 1er résultat à chaque fois également.
certes le test n'est peut etre pas trés révélateur, mais bon... j'avoue que
je suis dubitatif sur l'affirmation de Paul. Mais c'est vrai qu'on entend
dire ça depuis quelques années.
> IMHO, les ralentissements proviennent plus de l'infra technique au niveau
> serveur (Mysql, etc) que du reste... meme si la connectivité joue beaucoup,
> aller jusqu'au timeout sans afficher la page d'un forum, hum...
>
> je parle bien de navigation, donc d'affichage de pages relativement légère
> en terme de poids.
>
> c'est bien simple, j'ai conseillé à l'admin de changer son phpBB pour un
> SMF (pour cause de spam incontrolable entre autre) ce qu'il a fait et
> depuis les ralentissements sont moins fréquents et les erreurs sont moins
> fréquentes.
Hum, changement de forum, moins de ralentissement ? C'est l'infra
Celeonet qui est à mettre en cause ou le forum qui une usine à gaz et
qui n'a pas sa place sur du mutualisé ?
Euh... en principe un hébergeur a du peering et du transit. Le peering est
en général gratuit ou très peu cher, et permet d'améliorer la connectivité
vers certains FAI. Mais le transit payant est tout de même sensé
fonctionner vers les FAI vers lesquels il n'y a pas de peering.
Si ce n'est pas le cas, c'est que l'hébergeur radine sur ses transits (les
liaisons les plus chères mais qui permettent d'accéder à tout l'internet)
pour favoriser ses peering. Sans économiser sur les transits, un peering,
c'est améliorer la connexion vers un FAI, mais PAS au détriment des autres.
Sur des machines rapides et non saturées, un forum PHPBB sera rapide, la
conséquence sera sur la montée en charge du serveur, pas sur le visiteur.
Dans le monde réel, sur du mutualisé le client partage les ressources
avec d'autres. Cela implique des limitations aussi bien en terme
d'utilisation MySQL que Web. Cela évite les "dérives" qui pourraient
impacter les sites hébergés sur les mêmes clusters.
Pour ta gouverne, une requête MySQL qui s'exécute pendant 120s aura un
impact sur la vitesse d'affichage du site sans forcément impacter de
manière conséquente la charge de la machine. La faire tomber à 1s
d'exécution peut s'effectuer de 2 façons, soit en collant un cluster
MySQL (qui paye ?) soit en revoyant le code.
Personnellement j'ai toujours privilégié la deuxième solution par
déontologie (et je ne parle pas de plateformes mutualisées). Chez
Celeonet nous ne sommes pas adeptes des propositions commerciales à
rallonge si 10 minutes de dev suffisent pour régler un problème.
Je corrige donc, sur des machines "rapides et non saturées et non
limitées" ;-)
Chez nous on appelle ça un serveur virtuel ou dédié :) Sur du mutu,
partage de ressources et donc sécurisation pour qu'une personne ne
puisse pas mettre la zone ailleurs que sur son site.
Chez nous ça s'appelle un mutualisé, pour éviter la zone on a d'autres
techniques ;-)
Ok j'ouvre un compte :D
lixium ? ;-)
Le noyau linux sait gérer les priorités, alors autant utiliser ces facultés,
là-dessus tu rajoutes du monitoring pour veiller au grain, on ne sait
jamais, et au final tu n'as pas besoin de limitations "dures".
Mais je suis d'accord avec toi, si tu te contentes de mettre plusieurs
clients sur une machine sans plus de réflexion, ça va vite crasher !
Je crois surtout que nous n'avons pas les mêmes problématiques :
http://www.webhosting.info/webhosts/reports/total_domains/CELEONET.FR
http://www.webhosting.info/webhosts/reports/total_domains/EUROPEANSERVERS.NET
Un simple ratio, basiquement nous avons 30 fois plus de "chance" que toi
d'avoir un client qui abuse. Tu es dans un contexte où ton monito te
permet de réagir en cas d'abus après incident (1 fois l'an), notre
problématique est différente nous nous devons d'anticiper l'incident (1
fois par jour).
Si le monito se déclenche chez nous à cause d'un client sur du mutu je
ne considère pas ça comme normal et ça ne se reproduit pas 2 fois.
> Hum, changement de forum, moins de ralentissement ? C'est l'infra
> Celeonet qui est à mettre en cause ou le forum qui une usine à gaz et
> qui n'a pas sa place sur du mutualisé ?
Total des fils de discussion: 1220
Total des messages: 7147
Total des membres: 458
Moyenne des messages par jour: 12
Moyenne d'utilisateurs connectés par jour: 11.94
c'est vraiment un petit forum !!
Aucun doute là-dessus. Il n'y a pas de magie, payer plus cher = moins de
clients = moins de problèmes = plus de qualité. A moins évidemment qu'on
mette aussi 30 fois moins de machines derrière ;-)
> Tu es dans un contexte où ton monito te
> permet de réagir en cas d'abus après incident (1 fois l'an)
Il agit de lui-même en fait en tuant le script concerné (on a rarement le
temps d'attendre une intervention humaine dans ces cas là), après on n'a
plus qu'à agir pour expliquer au client ce qu'il doit faire pour que ça ne
se reproduise pas.
Mods ?
je ne sais pas, je n'en suis pas l'admin.
je constatais les lenteurs qu'en simple visiteur sur le forum en question.
J'aimerais bien savoir ce que vous considérez comme "cas anormaux" et
comment vous les detectez :)
Typiquement, un script qui prend 99% de CPU pendant plusieurs minutes
Certe mais depuis cette discusion qui date de septembre 2007, google
(qui représente tout ou presque en france) permet dans son google
webmaster tools de définir :
"Si votre site cible les internautes d'une zone géographique
particulière, vous pouvez l'associer à cette zone. Ces informations nous
aideront à déterminer les modalités d'affichage de votre site dans les
résultats de recherche propres à une région."
En gros un site avec une ip suisse peut prétendre bien apparaitre en
france...
La limite de temps d'exécution ne le jette pas ? comment savoir que _ce_
script (et pas un autre) prend autant de temps ?
Ce n'est pas forcément le script PHP du client, ça peut être PHP lui-même
qui plante... (vu la qualité du développement de PHP...). Ou un script CGI.
Ou Apache.
> comment savoir que _ce_
> script (et pas un autre) prend autant de temps ?
ps afux
> http://www.webrankinfo.com/forums/viewtopic_79889.htm
Bizarre, pour moi cette page n'existe pas... Ni la section forums,
d'ailleurs...
d'après le whois :
Last Updated on: 04-Mar-08
J'imagine que tu n'as donc pas php en module (sinon c'est pas super
précis comme depistage :-))
cgi ?
voila pourquoi
en effet
> cgi ?
fastcgi
derniére question (j'espére ne pas abuser :)) :
process fcgi pour tout le serveur, ou x process par site ?
D'ailleurs, pcinpact en parle aussi
(<http://www.pcinpact.com/actu/news/42221-webrankinfo-gmail-detournement-domaine-nom.htm>)
par site
Vous êtes mignons tous les deux :-)
Vous parlez depuis le début de MySQL et vous avez cité le code, les
serveurs, la configuration php, mais jamais les optimisations sur la
base elle même...
--
Stephane Kanschine
Association APINC : http://www.apinc.org/
Sur la base ? Sur le coté client tu veux dire ?
Si il a envie de faire un code de merde, tu fais quoi ? :) Tu recode à
sa place ? Tu l'éduque ?
La partie client est la partie la plus aléatoire là dedans, car celle
incontrôlable :)
> Stephane Kanschine a écrit :
>>
>> Vous parlez depuis le début de MySQL et vous avez cité le code, les
>> serveurs, la configuration php, mais jamais les optimisations sur la
>> base elle même...
>>
>
> Sur la base ? Sur le coté client tu veux dire ?
Non.
> Si il a envie de faire un code de merde, tu fais quoi ? :) Tu recode à
> sa place ? Tu l'éduque ?
Non.
> La partie client est la partie la plus aléatoire là dedans, car celle
> incontrôlable :)
Un parseur du log slow query, qui fait les explain analize truc, qui
rajoute les bons index, non ?
Exactement.
Ce serait si simple ?
Oui, voir nos stats :
Hier (le 10 mars 2008), sur 16158187 requêtes MySQL, 524 ont duré une
seconde ou plus, le taux de requêtes MySQL ayant duré moins d'une seconde
est donc de 99.9968%. En moyenne, depuis le 1er mars 2008, ce taux est de
99.9983%.
OUI (dans 99% des cas) !!!
Thomas