Kioob

Avec une solution de type VDS ce type d'offre reste envisageable. Sans survente pour ce qui est de l'espace disque, du CPU, et de la mémoire. Par contre pour moi "bande passante illimitée" sous entend forcément "survente".

Je prends un cas concret : un serveur OVH MG Max, 8 coeurs, 16Go de RAM, 1.5To de stockage, pour environ 200€ par mois (avec les diverses options).

Si on colle 16 VDS là dessus, ça nous fait quand même des machines avec pas loin d'1Go de RAM et 85Go de stockage, avec 50% d'un coeur de Xeon, pour une douzaine d'euros mensuels.

Bon évidement l'éventuel revendeur va rajouter sa marge, et les tarifs seront probablement entre 20 et 30€. Mais ça reste dans le même ordre d'idée non ?

Reste que hors survente la bande passante de la machine sera de 25Mbps chez OVH, soit 1.5Mbps seulement par VDS.

Tout ça pour dire que de nos jours, 50Go de stockage est abordable sans être bien gros.

Justement, personne n'a dit que tu devais changer de registrar quand tu changes d'hébergement. J'ai des clients qui ont leur domaine chez OVH et le site est hébergé chez Sivit, tout comme certains ont leurs DNS chez Gandi et les sites chez OVH.

Bref, c'est totalement indépendant. Du moment que le domaine est chez OVH, tu peux utiliser leur service DNS et faire pointer le domaine sur les IP que tu veux, qu'elles soient chez OVH ou non.

Bonjour,

la plupart des registrar proposent ça il me semble, c'est notamment le cas d'OVH et de Gandi.

Maintenant pour une association tu peux peut-être aussi te tourner vers des services tels que l'APINC.

Olivier

sarc : sans demander aux copains oui, il y a ab (= Apache Benchmark) et siege par exemple deux outils permettant de simuler plus ou moins bien des connexions d'internautes. Par contre pour le "sans se faire engueuler par l'hébergeur", je ne tenterais certainement pas ça sur un mutualisé non.

Yep, c'est déjà plus précis oui.

Donc pour récapituler, on est sûr d'avoir au moins le cas n°1 : jusqu'à 15'000 sessions PHP ouvertes. Déjà va peut être falloir faire attention à la méthode de stockage de celles-ci (les placer en mémoire de préférence et/ou avec une répartition sur deux niveaux).

Coté keepalive, si les 15'000 se pointent plus ou moins dans la même minute, le cas n°3 risque de vite se présenter. Dans ce cas pour moi il faut prévoir un serveur http gérant correctement le keepalive (apache-mpm-event, nginx, varnish, lighty, etc) ou bien carrément le désactiver (à conditions que les fichiers statiques soient sur un autre serveur...).

Le problème de varnish pour le coup va être les sessions : difficile de mettre en cache un contenu spécifique à chaque utilisateur.

Reste que théoriquement si les 15'000 se pointent strictement en même temps, PHP va avoir bien du mal à gérer cela. A raison de 4Mo minimum par instance de PHP, ça va être tendu... et j'espère que ce n'est pas un CMS bouffant 30Mo par page qui fait tourner ça.

Heureusement en pratique il y a peu de chances pour que les visiteurs cliquent au même instant sur le bouton. Il s'agit d'approximations, mais si par exemple on accepte un délai de 10 secondes pour l'affichage de la page, et que le traitement PHP ne dure que 50ms, et que derrière on accepte 50 processus simultanés, on est déjà à 10'000 exécutions (sous 10 secondes).

Maintenant tout va dépendre du délai de réponse acceptable, et du temps de traitement réel coté PHP. On en revient un peu au même : va falloir tester avec un simulateur de charge.

Bonsoir,

pour commencer il faudrait être sûr de ce dont on parle : quand tu indiques 15'000 connexions simultanées, c'est :

• * le nombre de sessions PHP actives à un instant T
  * le nombre de visiteurs ayant accéder à une page durant les 120 dernières secondes
  * le nombre de connexions keepalive ouvertes sur le serveur http
  * le nombre de téléchargements simultanés
  * le nombre de téléchargements simultanés de pages dynamiques
  

Déjà en fonction de ces 5 cas, la solution changera radicalement. Pour la première par exemple, il n'y a pas forcément besoin de faire quoi que ce soit.

Pour les deux suivantes, il faut surtout faire attention au nombre de slots autorisés par Apache (si toutefois tu utilises Apache), en particulier si tu utilises autre chose que le mpm_event d'Apache et que le keepalive est actif.

Enfin pour les deux derniers cas, c'est probablement à évaluer au cas par cas, une solution peut consister à utiliser Varnish en frontal afin de maintenir un cache statique, ne serait ce que de quelques secondes.

Ca c'est uniquement pour dégrossir. Après faut voir en détail le code PHP, les requêtes SQL utilisées ainsi que le modèle de données. A haut régime le moindre verrou peut tout faire tomber. Sans oublier d'autres aspects qui peuvent parfois être bloquant : le firewall, la bande passante, ou même le système de logs.

Il faudra bien tester tout ça avant la mise en prod afin d'éviter de mauvaises surprises.

lol. Dans ce cas je n'ai vraiment rien compris aux logs en question.

Bonne nouvelle en tous cas, et désolé pour la fausse alerte.

Bonjour,

je ne suis pas forcément un expert en sécurité, mais visiblement ton serveur test des ports UDP sur le serveur 94.23.203.251. C'est pas bon signe du tout (à moins que tu utilises une application spécifique qui s'amuserait avec l'UDP ?), à mon avis ton serveur est utilisé pour scanner le réseau OVH ; et si c'est bien le cas OVH ne devrait pas tarder à la couper.

Yep le soucis étant que locate n'est par défaut plus installé sur les systèmes Debian ; et pour ma part je le désactivais car le cron responsable de créer la base était trop gourmand sur certains systèmes.

Mais quand il est disponible, locate est effectivement beaucoup beaucoup plus rapide qu'un find.

hello,

si locate n'est pas dispo :

find /dossier/où/chercher -name '*.key'

C'est RAID1 ou RAID0 avec 2 disques. RAID0 est plus rapide mais RAID1 plus sûr. Je ne sais pas s'ils auront la même usure mais en cas de casse il est peu probable qu'ils cassent la même jour (où alors j'ai vraiment pas de chance)

Et bien justement, un SSD est sensé ne pas "casser" mais au contraire peut s'user. En RAID 1 les écritures seront effectuées en simultané sur les deux SSD et auront ainsi chacun la même usure, d'où mon hésitation. Mais Nicolas a répondu à ce point

Mon serveur actuel n'a que 16Go. Après analyse approfondie mes problèmes viennent de mon système de cache qui travaille sur des millions de fichiers qui prennent entre 40 et 50Go sur le disque. Il y a un très gros ralentissement de ce côté. L'idée est de changer de système de cache et de placer une partie des données dans un cache mémoire avec memcached.

Mon futur serveur aura 48Go de mémoire et 10Go de données sur disque.

40 à 50Go de "cache" pour si peu de données derrière, oui je veux bien croire que ce soit complètement non productif.

Il n'en reste pas moins qu'avec 48Go de mémoire à mon avis l'intégralité du disque sera dans le cache, et donc que les performances en lecture importent peu dans ton cas.

D'après ce que j'ai lu memcached est beaucoup utilisé avec MySQL pour stocker le résultat des requêtes en cache. Ce qui permet d'alléger la charge sur les BDD.

Xcache compile les scripts php et place le tout en mémoire... ça accélère le php mais je ne crois pas que ça améliore MySQL. Pour ça je vais mettre eaccelerator qui fait la même chose.

Je parlais "évidement" des API fournies par xcache, apc et même eaccelerator qui permettent d'accéder à une zone mémoire commune (avec gestion des verrous intégrée) ; ce qui est généralement beaucoup plus rapide que memcached. Mais oui memcached est beaucoup utilisé (je l'utilise moi même), mais essentiellement dans des contextes multi serveur, là où les solutions mémoire ne peuvent être utilisées.

Bonsoir,

quelques remarques en vrac :

- "sécurité du RAID 1", les deux SSD risquent d'avoir strictement la même usure dans le cas présent, donc pour le moment je suis assez dubitatif quant à l'intérêt du RAID 1 dans ce cas

- 48Go de mémoire, 10Go de données sur le disque, et malgré tout des problèmes de temps de lecture disque !? Es-tu certain que ce ne sont pas seulement les écritures qui te posent problème ?

- pour moi le principal intérêt de memcached c'est l'accès réseau, il permet d'avoir un cache commun à plusieurs serveurs. Dans une config mono serveur j'aurais tendance à lui privilégier des solutions d'accès à la mémoire partagée (via xcache, apc, ou autre), généralement beaucoup plus rapide.

Bonjour,

un "simple" serveur de type VDS / VPS / RPS devrait suffir, en installant par exemple NginX et le module flv.

En fait comme je disais à Dadou (en PV) j'ai commandé le miens sur ce site il y a plus de 3 semaines, et je n'ai toujours rien reçu. Donc doucement peut être sur les achats compulsifs

Bonjour,

plutôt que de forcer des conversions en chaine, je travaillerais directement sur la date :

select * from tatable where date(ladate) = curdate()

Pour faire tourner un serveur chez moi (mais clairement pas pour de l'hébergement dans mon cas) je me suis commandé un petit SheevaPlug : ça ne coûte pas grand chose à l'achat et coté consommation il consomme moins que mes PC éteints.

Par contre comme expliqué au dessus, ça demande du temps et des compétences.

Bonjour,

ou sinon tu prends directement une offre dans cette gamme de prix : http://www.lowendbox.com

Et donc il manquait simplement un restart d'Apache ou non ?

Parce que moi aussi j'aimerais bien savoir ce qui coinçait dans cette configuration

Là comme ça je suppose qu'au niveau de la configuration Apache il manque un AllowOverride Options.

la doc : http://httpd.apache.org/docs/2.0/mod/core.html#allowoverride

Ouef, c'est du webmin, désolé je ne peux rien pour toi.

Hello,

pour information avec MySQL vient l'outil "perror" qui a pour principal intérêt de donner le message d'erreur correspondant aux fameux codes que renvoi MySQL.

Ainsi pour ton code 111 on obtient :

~$ perror 111
OS error code 111:  Connection refused

Et pour le coup quand je vois que c'est l'OS qui retourne un classique "Connection refused" j'ai du mal à y voir un bug de MySQL. Aurais tu plus d'infos à ce sujet ?

Bonjour,

pour le serveur "privé" ça dépend de la technologie utilisée et surtout du taux de remplissage de l'architecture physique. Impossible de définir une règle absolue.

Par contre quand j'opte pour un serveur virtuel à la place d'un petit dédié, c'est pour ces critères :

• matériel de meilleure qualité, donc moins de risque de pannes
  
• stockage sécurisé (raid)
  
• possibilité d'extension facile (par exemple en un click on double la puissance CPU et quantité de mémoire)
  

Pour ce qui est des performances pures, ça dépend trop du fournisseur pour pouvoir se prononcer.

En même temps tu indiques "ou un privé suffit" j'en déduis que tu comptes prendre un serveur privé encore moins cher qu'un dédié discount... faut pas s'attendre à avoir les mêmes perfs dans ce cas.

1) ici tu loues un serveur dédié, tu ne l'achètes pas. C'est aussi possible, mais généralement pas dans la même tranche de budget.

2) les Kimsufi n'ont pas vraiment de support, et l'entrée de gamme n'a pas de RAID au niveau des disques. Perso je n'y mettrais pas de données importantes. Coté tarifs ce sont déjà des "boites à chaussures" livrées sans support, difficile de faire plus bas... à moins d'opter pour un serveur virtuel, mais faudra prévoir des changements de gamme au fur et à mesure de l'évolution de ton trafic.