Tout sur : Serveur
CloudFlare, 2e essai pour que ça fonctionne correctement
Je suis quelqu’un « des deuxièmes fois ». J’entends par là que j’ai tendance à toujours me planter une première fois (quelque soit la préparation), pour finir par réussir la deuxième fois.
Comme je l’avais relaté durant un précédent billet, j’avais tenté il y a environ 1 mois d’utiliser CloudFlare… Sans succès. Mes erreurs avait été de mettre le système sur mon blog le « plus critique » (toutes proportions gardées), de me tromper de nom de domaine pour le changement des DNS (FAIL total de ce côté, j’ai honte), et enfin de le faire en journée. Pour le fait que je l’avais fait en journée, ce n’est qu’une demi-erreur, disons que cela aura exarcerbé mon impatience et ma peur de l’échec. L’erreur réellement fondamentale aura été de me tromper de DNS. (Lire la suite…)
Chez Pingdom, on a pu lire une analyse très intéressante concernant l’arrêt par Apple de sa gamme de serveurs Xserve. En effet, Apple a arrêté sa gamme de serveurs rack, mais propose toujours à l’achat des persions de Macs Pro et Macs Mini avec MacOS X Server comme système d’exploitation. Il reste compréhensible que Apple arrête cette gamme, tant elle est désormais éloignée de leurs produits phares. Pour autant, il n’est pas exclu que Apple revienne sur le marché, en renversant les règles établies, comme ils ont su le faire jusqu’à maintenant pour d’autres produits comme les iPod, les iPhones ou les Macbook Air. (Lire la suite…)
En l’espace de quelques jours, j’ai vu passer sous mon fil Twitter trois articles très intéressant à propos de la configuration Varnish+Apache. Pour ceux qui ne connaissent pas, Varnish est un serveur statique, fréquemment utilisé par les gros sites de journaux en ligne, notamment dans une configuration de Reverse Proxy, c’est à dire Varnish en frontend et Apache en backend. Un peu de la même façon que ce que j’ai expliqué plusieurs fois ici, où je fonctionne avec Nginx en frontend et Apache en backend. (Lire la suite…)
Site encore down hier, la faute à un espace disque rempli
Hier encore, abricocotier était down. PLus exactement, le serveur est tombé vers 12h29 et est remonté vers 12h59 (d’après les dates données par Mon.itor.us, mais en fait il a été down un peu moins de temps). Déjà le matin, en publiant un billet sur le Windows Phone 7, j’avais eu la désagréable surprise de ne pas pouvoir uploader mes images correctement. Je me disais que c’était peut-être parce qu’après la tombée du serveur la veille, PHP n’avait peut-être pas été redémarré dans les même conditions que précédemment, et les fonctions de PHP permettant de recevoir les fichiers et de les redimensionner n’étaient peut-être pas utilisables. En fait, pas du tout.   (Lire la suite…)
Hier, le blog était down pendant une heure et demi
Hier, le blog n’a pas été accessible entre 19h43 et 21h13 (heures relevées par l’outil de monitoring Monitis). J’ai donc mis facilement 3/4 d’heure à me rendre compte que le blog ne répondait plus (et encore, c’est un coup de chance que j’aie eu besoin d’y accéder à ce moment là ), et trois autres quarts d’heures à le remettre debout, la faute à mon absence devant mon PC personnel (et donc le besoin de retrouver à droite à gauche les différents codes d’accès). Notez que ce genre d’événement fait sérieusement penser à passer sous AppEngine, par exemple sur Bloog, ce qui permettrait au moins d’éviter d’avoir à faire ce genre de maintenance. (Lire la suite…)
D’après une note publiée sur TechCrunch, Facebook pourrait (notez le conditionnel) faire contruire un nouveau DataCenter rempli de serveurs fonctionnant à partir de processeurs ARMs (donc différents des serveurs classiques sur architecture x86). La note signale bien sûr que c’est l’efficacité énergétique qui pourrait être intéressante pour Facebook. A l’inverse de TechCrunch, je reste plus intéressé par l’ampleur médiatique que pourrait fournir une telle décision dans le monde des processeurs ARM. En effet, Facebook constitue un partenaire commercial sérieux en terme de volume (gros volume de serveurs, même si finalement très faible comparé à ce dont disposent d’autres companies telles que Google), et en terme de besoin (Facebook fonctionne sur du PHP, et donc reste proche de la pile LAMP). (Lire la suite…)
Des images encodées en Base64 pour accélérer le chargement de sa page en diminuant les requètes
J’en ai déjà parlé plusieurs fois : accélérer le temps de chargement d’un site passe entre autre par la réduction du nombre de fichiers à charger, car chaque requète supplémentaire nécessite un temps non compressible pour appeler le serveur, établir une connexion, et télécharger le fichier. Cela peut passer par la transformation des images en pixels CSS, ou bien également pas leur définition en Base64. Je n’avais jusqu’alors pas trop regardé cette solution en terme d’avantages apportés, mais j’aurais dû, comme je l’explique ci-dessous.   (Lire la suite…)
L’architecture serveur du futur se fera-t-elle via une virtualisation des ressources ou via un architecture physique louée comme telle ? C’est la question que nous nous posions dans les commentaires du billet sur l’arrivée des dédibox v3. Cela tombe bien : ça faisait assez longtemps que j’avais envie de parler des nouveaux types d’architecture pour les hébergeurs, et que je ne trouvait pas l’occasion de le faire. En effet, à l’heure actuelle, au moins trois poids lourds en terme de capitalisation ont lancé des offres de serveurs, toutes virtualisées.  (Lire la suite…)
- 1and1 | Amazon | AppEngine | ARM | Google | Intel | OVH | Serveur
- [ 5 ] Commentaires
- Tweet This !
Dans la longue série des billets que je fais sur l’optimisation de la vitesse de chargement et d’envoi d’un site web, j’en suis arrivé à faire plusieurs billets sur Nginx. Par ailleurs, j’ai découvert récemment (via Lionel) le webware GTmetrix, qui permet de faire rapidement un état des lieux des performances de son site, grâce auquel j’ai pu me rendre compte qu’il ne me restait pas grand chose à améliorer à part l’encodage des fichiers en gzip. Cet encodage permet de réduire grandement la quantité d’information envoyée au client (car celle-ci est compressée), et notamment pour les fichiers textes (comme les feuilles de style et fichiers javascripts), pour lesquels on atteint facilement des réduction de 70%.
(Lire la suite…)
Dans la lignée du script de sauvegarde quotidienne des bases de données, je me suis dis qu’il serait bon également de sauvegarder les fichiers associés au fonctionnement du site, parmi lesquels on peut citer (pour un blog WordPress) les images uploadées, les différents plugins installés, les fichiers du thèmes, etc. Le problème vient quand on a plusieurs sites sur le même serveur, et donc il est à mon avis compliqué de gérer au cas par cas ce qu’il faut sauvegarder ou non. Notez également que, en terme de place, les fichiers texte (tous les fichiers de code source en premier lieu) se compressent très bien, donc il n’est pas un problème de les sauvegarder tous.
(Lire la suite…)
- 29 January 2012Pas de loi de Moore dans les cartes graphiques depuis plusieurs années(1) Comments
- 29 January 2012Rénovation des structures de chauffage urbain à Paris(5) Comments
- 28 January 2012Etat des lieux de ma dépendance à Google(9) Comments
- 28 January 2012Désactiver l'accélération de la souris sous Mac OS(4) Comments
- 27 January 2012Priceminister : photos des nouveaux locaux à Réaumur(4) Comments
- 24 January 2012Les singes de doigt, ou marmousets pygmées(0) Comments
- 24 January 2012Une pénurie de développeurs ? Et si on arrêtait de prendre les gens pour des cons ?(109) Comments
- 23 January 2012Le meilleur du web en 3 minutes et demi(0) Comments
- 22 January 2012FreeMobile : comment activer les données cellulaires sur un iPhone(25) Comments
- 10 January 2012Free Mobile lance le forfait illimité sans engagement à 20 euros par mois(6) Comments