LAMP sur Raspberry Pi 2 - ce que le processeur ARM + USB est capable de

Je ferai une réservation tout de suite, le but n'est pas de découvrir les capacités maximales du système, mais de découvrir les performances fondamentales des micro-ordinateurs modernes en tant que serveurs Web à part entière et d'aider à évaluer la compétitivité par rapport à l'hébergement partagé. Par conséquent, cet article ne traite pas des problèmes d'optimisation et d'étude de la charge maximale admissible. Au lieu de cela, une expérience est menée sur des sites existants avec de vrais visiteurs.

introduction


Probablement, beaucoup de ceux qui connaissent les micro-ordinateurs des familles comestibles (framboise, banane, orange ...) ont pensé à élargir la gamme de leur utilisation. Conçus à l'origine pour les systèmes domestiques intelligents et la robotique, ils deviennent de plus en plus rapides tout en conservant leur taille. Leur faible consommation d'énergie et leur puissance de processeur accrue les rendent attrayants pour une utilisation potentielle comme serveurs Web. Choisissons un modèle adapté à cela.

Pourquoi le Raspberry Pi 2 modèle B?


Étant donné que le point le plus faible de ces systèmes du point de vue de l'hébergement est le processeur, qui a des performances relatives très faibles (plus à ce sujet plus tard), nous essaierons d'organiser un serveur Web avec une option budgétaire, mais qui, néanmoins, peut s'avérer assez puissant pour notre tâche est le Raspberry Pi 2 modèle B. Il a un processeur à 4 cœurs qui fonctionne en mode normal sans refroidissement à 900 MHz et la possibilité de changer cette fréquence de 700 à 1200 MHz. Nous n'augmenterons pas la fréquence d'horloge, nous notons simplement que pour «l'overclocking», vous aurez besoin d'un radiateur et, éventuellement, d'un ventilateur. Puisqu'il se trouve qu'aujourd'hui le Raspberry Pi 2 modèle B possède le processeur le plus productif parmi les "camarades de classe", nous le sélectionnons pour les tests.

Caractéristiques techniques de la plateforme en question


CPU

Nous avons un processeur inhabituel, la famille RISC. En bref, on peut dire que l'ensemble d'instructions pour un tel processeur est beaucoup plus petit que celui des «ordinaires», mais il exécute très rapidement des commandes simples. Mais pour exécuter des instructions complexes, de telles commandes simples nécessitent beaucoup. Par conséquent, l'horloge fait plus de cycles. Donc, s'il semblait à quiconque que 4 cœurs de 900 MHz chacun sont plus que suffisants pour un serveur Web, alors vous devriez apporter un amendement - le Cortex A7 quadricœur Broadcom BCM2836 pour notre tâche ne sera pas plus rapide que l'ancien Pentium 300-400 Mhz. Certes, 6 fois plus que le précédent modèle à cœur unique sur le Raspberry Pi, et 1,9 fois devant le camarade de classe à double cœur sur le Banana Pi M2 (qui, bien que annoncé par la présence de SATA et d'Ethernet gigabit, est beaucoup moins adapté au serveur Web en raison de son processeur )C'est précisément à cause de la lenteur du processeur central que l'on observe une consommation record de micro-ordinateurs. Selon les données disponibles, le Raspberry Pi consomme de 2 à 3 watts, 4 watts à pleine charge, 1 watts au ralenti. Eh bien, 2-3 watts (5V, 0,4-0,6A) en moyenne pour l'ensemble du système, à l'exception de la puissance des supports de stockage - c'est ce pour quoi il vaut la peine de se battre dans le domaine de l'hébergement Web d'entreprise ou domestique, ce qui peut le rendre rentable avec des économies points de vue.ce qui peut le rendre économiquement avantageux.ce qui peut le rendre économiquement avantageux.

Mémoire

La mémoire utilisée n'est pas la plus rapide, c'est la DDR2, mais il y a une quantité de mémoire suffisante - 1 Go. Je dois dire que c'est une bonne quantité pour les serveurs Web ordinaires exécutant Linux.

Interface réseau

Une interface réseau de 100 mégaoctets suffit pour le transfert de données. Nous n'avons besoin de rien d'autre - le sous-système de stockage d'informations et le processeur ne peuvent tout simplement pas faire face à la lourde charge.

Stockage de données

Nous passons à un point très intéressant - le lecteur de carte intégré permet au système de démarrer uniquement à partir de celui-ci (sauf si vous redirigez le chargeur de démarrage ...), et cela dans une situation normale limite le choix du support principal à une carte micro SD. La bonne nouvelle est qu'aujourd'hui, ils peuvent déjà être d'un volume important et fonctionner rapidement. Bien qu'il existe déjà des lacunes - il est peu probable que nous souhaitions conserver les fichiers du site Web, les bases de données, les échanges et les journaux, afin d'éviter un fonctionnement lent et une réduction prématurée de la vie du transporteur. Pour ce faire, nous aurons un autre média sur le bus USB. Cette approche augmentera non seulement les performances du système, mais donnera également l'avantage de la modularité - il est facile de remplacer le média par un autre et de faire des sauvegardes de l'image entière. La question est de savoir exactement ce que nous voulons utiliser comme support externe - un disque SSD, un disque dur ou une carte mémoire rapide.Ici, tout le monde décide par lui-même, cela dépend beaucoup de la nature des sites hébergés. Il faut se rappeler que le Raspberry Pi 2 utilise la norme USB 2.0, ce qui limite notre sous-système de fichiers en vitesse de transfert de données.

Dans cet exemple, en tant qu'appareil externe, nous considérerons une option d'enregistrement relativement lente - il s'agit d'un lecteur de carte USB avec une carte SD plein format Lexar Professional connectée, ce qui vous permet d'enregistrer des données à seulement environ 15 Mo / s avec cette connexion. Bien que (dans le cas général), des vitesses de lecture supérieures à 100 mégabits pour la lecture et l'écriture seront sans importance pour nous, car la communication avec le monde extérieur est limitée par ce chiffre. Lorsque vous utilisez des sous-systèmes de disques, vous devez penser à leur consommation d'énergie. Winchester 2.5 "consomme ~ 5 watts et nécessitera probablement une alimentation séparée. Vous devez également vous souvenir de l'organisation spécifique de l'entrée-sortie vers Raspberry via USB, évidemment, nous avons un goulot d'étranglement de plus:

schéma fonctionnel du Raspberry Pi 2 modèle B

Donc, le support de test:

" Interne ": MicoSD 8Gb classe 10
Externe: SD 32 Go classe 10+ (UHS)

Installation et composition de LAMP


Le système doit être simple, mais avoir toutes les fonctionnalités. Par conséquent, une exigence n'est rien de plus, mais seul Apache se cachera derrière Nginx, car la mémoire le permet.

système opérateur

Minibian est installé sur le support «interne» à partir de l'image 2015-02-18-wheezy-minibian.img.

Il s'agit de Debian 7.8 au minimum pour Raspberry. Nous faisons une réservation, dans le référentiel standard, ils n'attendent pas de PHP supérieur à 5,5 et d'Apache pas supérieur à 2,2. Ce n'est pas une restriction gênante, mais pour cet article, il est utile de vérifier la possibilité d'utiliser les dernières versions. Afin d'installer PHP 5.6.x et Apache 2.4.x, qui ne sont pas inclus dans le référentiel standard, j'ai dû changer la source de la 8ème version de Raspbian, le système après la mise à niveau apt-get a commencé à avoir la version 8.0.

Apache

Version 2.4.10 (Raspbian). Gzip est activé, tous les modules les plus couramment utilisés de la distribution standard sont connectés, y compris mod_rewrite, mod_cache ..., sans compter ceux qui sont activés par défaut.

Php

5.6.12-0 + deb8u1 (cli). Fonctionne dans Apache en tant que préfork. Il existe php-curl, php-gd et d'autres bibliothèques populaires.

MySQL

5.5.44-0 + deb8u1 - (Raspbian).

Nginx

Nginx / 1.6.2. Nginx est responsable de la statique. La compression Gzip est incluse.

Permettez-moi de vous rappeler que tous les journaux sont écrits sur des supports externes, la base de données MySQL est là, le swap n'est pas désactivé, mais vide pendant toute la durée du test.

En tant qu'utilitaires auxiliaires, j'utilise PhpMyAdmin, htop, iostat et webmin. Exim4 est installé, mais uniquement pour l'envoi de messages à partir de formulaires. Comme vous pouvez le voir, notre serveur est assez moderne et fonctionnel. Je vais décevoir les fans du panneau de contrôle VESTA - malheureusement, le fabricant ne prend pas en charge les processeurs ARM et ne le fera pas dans un avenir proche. Par conséquent, webmin.

Essai


Je n'allais pas immédiatement faire de tests synthétiques, car ils sont plus susceptibles de provenir du domaine d'une théorie très éloignée. En pratique, tout dépend fortement de la nature des sites hébergés, de la répartition des charges par le temps, du canal de communication, du nombre de vues, du temps des visiteurs du site ..., ainsi que des paramètres. En d'autres termes, je propose de voir ce qui se passe réellement sur les sites existants.

Les sites Web testés ne sont basés sur aucun CMS, mais utilisent l'affichage d'images de la base de données sur des pages dynamiques (PHP), il peut donc y avoir une charge assez intense sur MySQL. Mais il n'y a aucune connexion AJAX. Étant donné que notre hébergement ne prétend pas encore être professionnel, il est considéré suffisant pour que le test place 16 sites actifs à faible trafic, dont environ cinq représentent environ 100-200 personnes par jour, les autres ne sont pas plus de 50 visiteurs pour le même temps. Au total - environ 800 à 900 personnes par jour, ce qui est comparable en termes de charge acceptable avec un hébergement partagé peu coûteux. La moitié des visiteurs tombent le soir, les principales visites ont lieu à 20-22 heures (~ 300 personnes en deux heures, en moyenne 4 vues = 10 vues par minute à ~ 700 ko chacune = 116 kilo-octets de trafic par seconde).Nous désignerons cette heure «heure de pointe» et en même temps nous effectuerons des tests. Il n'y aura que deux types de tests: l'évaluation des performances à l'aide de services tiers et un rapport des utilitaires htop et iostat sur le travail réel.

1. L'heure de génération et de chargement par l'utilisateur des pages aux "heures de pointe"

Nous n'utilisons que deux paramètres principaux - le temps de génération de page et le temps de chargement de page, pour deux types de pages - «lourd» (lourd pour le processeur, car il y a beaucoup d'images de MySQL, longue génération) et «léger» (page PHP dynamique normale). Nous répéterons chaque test 10 fois pour réduire la probabilité d'un résultat aléatoire, et nous utiliserons également différents services.

Permettez-moi de vous rappeler la géographie des serveurs de test et leur charge de travail possible. Par conséquent, les résultats absolus peuvent varier considérablement, c'est normal. J'ai fait des mesures répétées avec des interruptions de 5 à 10 minutes afin d'entrer dans différents temps de chargement des services. Le canal de la framboise testée est l'optique gigabit, la géographie est la Sibérie, 150 mégabits garantis à Moscou. Afin de vérifier la capacité du serveur à servir plusieurs connexions simultanées, des tests ont été lancés simultanément sur les sites de service suivants:

Page légère (547 ko, sans accès MySQL)

PingDom.com, Suède

Temps de chargement de la page (46 requêtes): minimum - 925 ms, maximum - 1124 ms, moyenne - 955 ms.

Google PageSpeed ​​Insights

Il n'y a rien à redire sur la vitesse.

Sitespeed.ru

Temps total de chargement des pages 3.9-4.2, moyenne 4.0. Temps de génération de page de 139 à 157, 145 ms en moyenne. C'est pourquoi Google n'a aucune plainte - nous entrons dans les 200 ms autorisés.

Page `Heavy` (843 ko, dont 38 images de 10-15 kb de MySQL)

PingDom.com, Suède

Temps de chargement de la page (85 requêtes): minimum - 946 ms, maximum - 1001 ms, moyenne - 973 ms.

Google PageSpeed ​​Insights

Il n'y a rien à redire sur la vitesse.

Sitespeed.ru

Temps total de chargement des pages 5.3-4.2, moyenne 4.0. Temps de génération de page de 158 à 169, 162 ms en moyenne.

2. Rapport de l'utilitaire htop

Comme prévu, Htop a montré que le principal consommateur de temps CPU est les processus mysql. Ils ont "mangé" 98 minutes à partir du dernier jour de temps processeur. Ce qui n'est pas surprenant - les requêtes fréquentes et «lourdes» adressées à la base étaient initialement supposées de nous. S'il y avait des images dans le cache nginx, nous aurions un gain de performances, mais le test est intéressant car il modélise l'augmentation de la charge sur MySQL avec une marge, ce qui est d'ailleurs typique de la plupart des CMS.

3. Rapport de l'utilitaire iostat

Cet utilitaire a montré des vitesses moyennes de lecture et d'écriture sur les supports:
1. Support «interne» (système) - 0,87 kb / s en lecture en moyenne, 15,5 kb / s en écriture en moyenne (probablement en raison de la mise en cache nginx, il y a quelque chose à améliorer en configuration).
2. Médias «externes» (sites, journaux, bases de données) - 2,4 kb / s en lecture et 3 kb / s en écriture (tout va bien ici, la lecture est mise en cache, les journaux sont écrits).

4. Allocation CPU

Distribution du temps CPU par htop, échantillonnage - exactement deux jours de travail (~ 1600 visiteurs uniques servis selon les métriques Yandex):

mysql 6,8%
htop 1,8%
nginx 0,75%
apache2 <0,3%

Pendant presque le reste du temps, le processeur s'est reposé.

En conséquence, nous avons une grande marge pour le temps libre du processeur, une marge pour augmenter la fréquence du processeur, une marge pour la vitesse du support d'enregistrement. De nombreuses optimisations sont disponibles pour configurer à la fois les programmes serveur (placer le cache nginx sur un support séparé, par exemple) et les sites eux-mêmes. Tous ensemble - un bon potentiel pour augmenter la productivité globale.

Total


Notre visiteur virtuel a apprécié la vitesse du serveur Web sur le micro-ordinateur, malgré le fait qu'il y ait eu d'autres visites simultanées. Ainsi, malgré les goulots d'étranglement (USB et processeur), nous avons une conclusion très évidente - un serveur Web à part entière sur le Raspberry Pi 2 modèle B est réel. Tant dans le logiciel que dans les paramètres techniques. Sur la base de la très faible charge de travail de l'option envisagée, je suppose qu'il sera en mesure de servir rapidement au moins quelques milliers de visiteurs par jour sur le ou les sites moyens.

Le multitraitement aide à faire face aux demandes plus rapidement, il y a suffisamment de mémoire pour la mise en cache, le transfert de données via USB est satisfaisant, de sorte que le serveur bébé peut non seulement économiser de l'électricité, mais aussi effectuer rapidement (et à peu de frais!) Le remplacement de l'équipement défectueux. Un tel système peut être rentable lorsqu'il est utilisé sur un réseau d'entreprise en tant que serveur d'entreprise (serveur de base de données, serveur Web, serveur de sauvegarde, partage de fichiers) par rapport à d'autres solutions populaires. Et certainement une alternative à l'hébergement virtuel entre de bonnes mains. Par exemple, sur une alimentation électrique sans coupure économique, un micro-ordinateur couplé à un routeur peut fonctionner pendant des heures, de sorte que la question d'une panne de courant courte (et pas si) peut être réglée à la maison,si le site du fournisseur a également UPS. Et vous pouvez également contrôler l'électricité, donner des commandes à divers appareils, connecter une caméra vidéo et divers capteurs ...

Essayez, expérimentez, les micro-ordinateurs - ce n'est pas seulement bon marché, mais aussi agréablement silencieux ...

Source: https://habr.com/ru/post/fr384209/


All Articles