LAMP on Raspberry Pi 2 - what ARM CPU + USB is capable of
I’ll make a reservation right away, the goal is not to find out the maximum capabilities of the system, but to find out the fundamental performance of modern microcomputers as full-fledged web servers and help evaluate competitiveness with respect to shared hosting. Therefore, this article does not address the issues of optimization and studying the maximum permissible load. Instead, an experiment is conducted on existing sites with real visitors.
Probably, many who are familiar with the microcomputers of edible families (Raspberry, Banana, Orange ...) thought about expanding the range of their use. Originally designed for smart home systems and robotics, they are becoming faster and faster while maintaining size. Low power consumption with increased processor power makes them attractive for potential use as web servers. Let's choose a model suitable for this.
Since the weakest point of such systems from the hosting point of view is the processor, which has a very low relative performance (more on that later), we will try to organize a web server on a budget option, but which, nevertheless, can turn out to be powerful enough for our task is the Raspberry Pi 2 model B. It has a 4-core processor that works in normal mode without cooling at 900 Mhz and the ability to change this frequency from 700 to 1200 Mhz. We will not raise the clock frequency, we just note that for “overclocking” you will need a radiator and, possibly, a fan. Since it so happened that today the Raspberry Pi 2 model B has the most productive processor among the "classmates", we select it for testing.
We have an unusual processor, the RISC family. In short, we can say that the set of instructions for such a processor is much smaller than that of “ordinary” ones, but it executes simple instructions very quickly. But to execute complex instructions such simple commands need a lot. Therefore, the clock cycles more. So if it seemed to anyone that 4 cores of 900 Mhz each is more than enough for a web server, then you should make an amendment - Broadcom BCM2836 quad core Cortex A7 for our task will not be faster than the old Pentium 300-400 Mhz. True, 6 times overtaking the previous single-core model on the Raspberry Pi, and 1.9 times ahead of the dual-core classmate on the Banana Pi M2 (which, although advertised by the presence of SATA and gigabit ethernet, is much less suitable for the web server because of its processor ) It is precisely because of the slowness of the central processor that we observe a record low consumption of microcomputers. According to available data, the Raspberry Pi consumes from 2 to 3 watts, 4 watts at peak load, 1 watts at idle. Well, 2-3 watts (5V, 0.4-0.6A) on average for the entire system, with the exception of powering storage media, is something worth fighting for in the field of corporate or home web hosting, which can make it profitable with economic points of view.
The memory used is not the fastest, it is DDR2, but there is a sufficient amount of memory - 1GB. I must say that this is a good amount for ordinary web servers running Linux.
A 100-megabyte network interface is sufficient for data transfer. We don’t need anything else - the information storage subsystem and the processor simply cannot cope with the heavy load.
We turn to a very interesting point - the built-in card reader allows the system to boot only from it (unless you redirect the bootloader ...), and this in a normal situation limits the choice of the main carrier to a micro SD card. The good news is that today they can already be of significant volume and work quickly. Although the shortcomings are already evident - we are unlikely to want to keep website files, databases, swap and logs on it, in order to avoid slow operation and premature reduction of the carrier's life. To do this, we will have another media on the USB bus. This approach will not only increase system performance, but also give the advantage of modularity - it is easy to replace the media with a spare one and make backups of the entire image. The question is what exactly do we want to use as an external medium - an SSD disk, HDD or a fast memory card. Here, everyone decides for himself, a lot depends on the nature of the hosted sites. It should be remembered that the Raspberry Pi 2 uses the USB 2.0 standard, which limits our file subsystem in data transfer speed.
In this example, as an external device, we will consider a relatively slow option for recording - this is a USB card reader with a Lexar Professional full-format SD card connected, which allows you to record data at only about 15Mb / s with this connection. Although (in the general case), media speeds above 100 megabits for reading and writing will be unimportant for us, since communication with the outside world is limited by this figure. When using disk subsystems, you should think about their power consumption. Winchester 2.5 "consumes ~ 5 watts and will probably require a separate power supply. You should also remember about the specific organization of input-output to Raspberry via USB, obviously, we have one more bottleneck:
So, the test media:
“ Internal ”: MicoSD 8Gb class 10
External: SD 32Gb class 10+ (UHS)
The system should be simple, but have full functionality. Therefore, one requirement is nothing more, but only Apache will hide behind Nginx, since memory allows.
Minibian is installed on the “internal” media from the image 2015-02-18-wheezy-minibian.img.
This is Debian 7.8 as a minimum for Raspberry. We make a reservation, in the standard repository they expect PHP no higher than 5.5 and Apache no higher than 2.2. This is not an unfortunate restriction, but for this article it is useful to check the possibility of using the latest versions. In order to install PHP 5.6.x and Apache 2.4.x, which are not included in the standard repository, I had to change the source for the 8th version of Raspbian, the system after apt-get upgrade began to have version 8.0.
Version 2.4.10 (Raspbian). Gzip is included, all the most commonly used modules from the standard distribution are connected, including mod_rewrite, mod_cache ..., not counting those that are enabled by default.
5.6.12-0 + deb8u1 (cli). Runs in Apache as prefork. There are php-curl, php-gd and other popular libraries.
5.5.44-0 + deb8u1 - (Raspbian).
Nginx / 1.6.2. Nginx is responsible for statics. Gzip compression is included.
Let me remind you that all the logs are written to external media, the MySQL database is there, swap is not disabled, but empty for the entire time of testing.
As auxiliary utilities I use PhpMyAdmin, htop, iostat and webmin. Exim4 is installed, but only for sending messages from forms. As you can see, our server is quite modern and functional. I will disappoint fans of the VESTA control panel - unfortunately, the manufacturer does not support ARM processors and is not going to do this in the near future. Therefore webmin.
I was not immediately going to do any synthetic tests, because they are more likely from the field of a very distant theory. In practice, everything strongly depends on the nature of the hosted sites, on the load distribution by time, on the communication channel, the number of views, the time of visitors on the site ..., as well as on the settings. In other words, I propose to see what actually turns out on existing sites.
The tested websites are not based on any CMS, but use the display of images from the database on dynamic (PHP) pages, so there can be quite an intense load on MySQL. But there are no AJAX connections at all. Since our hosting does not yet claim to be professional, it is considered sufficient for the test to place 16 active sites with low traffic on it, of which about five are about 100-200 people a day, the rest are not more than 50 visitors for the same time. In total - about 800-900 people a day, which is comparable in terms of acceptable load with low-cost shared hosting. Half of the visitors fall in the evening, the main visits happen at 20-22 hours (~ 300 people in two hours, on average 4 views = 10 views per minute, ~ 700 kb each = 116 kilobytes of traffic per second). We will designate this time “rush hour” and at the same time we will carry out testing. There will be only two types of tests - performance evaluation using third-party services and a report of htop, iostat utilities on real work.
We use only two main parameters - page generation time and page load time, for two types of pages - “heavy” (heavy for the processor, since there are a lot of pictures from MySQL, long generation) and “light” (normal dynamic PHP page). We will repeat each test 10 times to reduce the likelihood of a random result, and we will also use different services.
Let me remind you about the geography of testing servers and about their possible workload. Therefore, the absolute results can vary greatly, this is normal. I did repeated measurements with interruptions of 5-10 minutes in order to get into different load times of services. The channel of the tested Raspberry is gigabit optics, geography is Siberia, 150 guaranteed megabits to Moscow. In order to verify the server’s ability to serve several simultaneous connections, testing was launched simultaneously on the following service sites:
Page load time (46 requests): minimum - 925 ms, maximum - 1124 ms, average - 955 ms.
There are no complaints about speed.
Total page load time 3.9-4.2, average 4.0. Page generation time from 139 to 157, average 145 ms. That's why Google has no complaints - we get into the permissible 200 ms.
Page load time (85 requests): minimum - 946 ms, maximum - 1001 ms, average - 973 ms.
There are no complaints about speed.
Total page load time 5.3-4.2, average 4.0. Page generation time from 158 to 169, average 162 ms.
As expected, Htop showed that the main consumer of CPU time is mysql processes. They "ate" 98 minutes from the last day of processor time. What is not surprising - the frequent and “heavy” queries to the base were supposed from us initially. If the pictures were in the nginx cache, we would have an increase in performance, but the test is interesting because it models the increased load on MySQL with a margin, which, by the way, is typical for most CMS.
This utility showed average read and write speeds on media:
1. “Internal” media (system) - 0.87 kb / s average reading, 15.5 kb / s average recording (most likely due to nginx caching, there is something to improve in configuration).
2. “External” media (sites, logs, databases) - 2.4 kb / s read and 3 kb / s write (everything is fine here, reading is cached, logs are written).
CPU time distribution by htop, sampling - exactly two days of work (~ 1600 unique visitors served according to Yandex metrics):
mysql 6.8%
htop 1.8%
nginx 0.75%
apache2 <0.3%
For almost the rest of the time, the processor rested.
As a result, we have a large margin for free processor time, a margin for raising the processor frequency, a margin for the speed of recording media. There are many optimizations available for configuring both server programs (putting the nginx cache on a separate medium, for example), and the sites themselves. All together - a good potential for increasing overall productivity.
Our virtual visitor liked the speed of the web server on the microcomputer, despite the fact that there were other simultaneous visits. Thus, despite the bottlenecks (USB and processor), we have a very obvious conclusion - a full-fledged web server on the Raspberry Pi 2 model B is real. Both in software and in technical parameters. Based on the very low workload in the considered option, I will assume that he will be able to quickly serve at least a couple of thousand visitors to the average site (s?) Per day.
Multiprocessing helps to cope with requests faster, there is enough memory for caching, USB data transfer is satisfactory, so the baby server can not only save on electricity, but also make quick (plus inexpensive!) Replacement of failed equipment. Such a system can pay for itself when used on an enterprise network as a corporate server (database server, web server, backup server, file sharing) compared to other popular solutions. And surely be an alternative to virtual hosting in the right hands. Say, on a budget uninterruptible power supply, a microcomputer paired with a router can work for hours, so the issue of short-term (and not so) power outages can be leveled at home, if the provider's site also has UPS. And you can control electricity, give commands to various devices, connect a video camera and various sensors ...
Try, experiment, microcomputers - it's not only inexpensive, but also pleasantly quiet ...
Introduction
Probably, many who are familiar with the microcomputers of edible families (Raspberry, Banana, Orange ...) thought about expanding the range of their use. Originally designed for smart home systems and robotics, they are becoming faster and faster while maintaining size. Low power consumption with increased processor power makes them attractive for potential use as web servers. Let's choose a model suitable for this.
Why is the Raspberry Pi 2 model B?
Since the weakest point of such systems from the hosting point of view is the processor, which has a very low relative performance (more on that later), we will try to organize a web server on a budget option, but which, nevertheless, can turn out to be powerful enough for our task is the Raspberry Pi 2 model B. It has a 4-core processor that works in normal mode without cooling at 900 Mhz and the ability to change this frequency from 700 to 1200 Mhz. We will not raise the clock frequency, we just note that for “overclocking” you will need a radiator and, possibly, a fan. Since it so happened that today the Raspberry Pi 2 model B has the most productive processor among the "classmates", we select it for testing.
Technical features of the platform in question
CPU
We have an unusual processor, the RISC family. In short, we can say that the set of instructions for such a processor is much smaller than that of “ordinary” ones, but it executes simple instructions very quickly. But to execute complex instructions such simple commands need a lot. Therefore, the clock cycles more. So if it seemed to anyone that 4 cores of 900 Mhz each is more than enough for a web server, then you should make an amendment - Broadcom BCM2836 quad core Cortex A7 for our task will not be faster than the old Pentium 300-400 Mhz. True, 6 times overtaking the previous single-core model on the Raspberry Pi, and 1.9 times ahead of the dual-core classmate on the Banana Pi M2 (which, although advertised by the presence of SATA and gigabit ethernet, is much less suitable for the web server because of its processor ) It is precisely because of the slowness of the central processor that we observe a record low consumption of microcomputers. According to available data, the Raspberry Pi consumes from 2 to 3 watts, 4 watts at peak load, 1 watts at idle. Well, 2-3 watts (5V, 0.4-0.6A) on average for the entire system, with the exception of powering storage media, is something worth fighting for in the field of corporate or home web hosting, which can make it profitable with economic points of view.
Memory
The memory used is not the fastest, it is DDR2, but there is a sufficient amount of memory - 1GB. I must say that this is a good amount for ordinary web servers running Linux.
Network interface
A 100-megabyte network interface is sufficient for data transfer. We don’t need anything else - the information storage subsystem and the processor simply cannot cope with the heavy load.
Data storage
We turn to a very interesting point - the built-in card reader allows the system to boot only from it (unless you redirect the bootloader ...), and this in a normal situation limits the choice of the main carrier to a micro SD card. The good news is that today they can already be of significant volume and work quickly. Although the shortcomings are already evident - we are unlikely to want to keep website files, databases, swap and logs on it, in order to avoid slow operation and premature reduction of the carrier's life. To do this, we will have another media on the USB bus. This approach will not only increase system performance, but also give the advantage of modularity - it is easy to replace the media with a spare one and make backups of the entire image. The question is what exactly do we want to use as an external medium - an SSD disk, HDD or a fast memory card. Here, everyone decides for himself, a lot depends on the nature of the hosted sites. It should be remembered that the Raspberry Pi 2 uses the USB 2.0 standard, which limits our file subsystem in data transfer speed.
In this example, as an external device, we will consider a relatively slow option for recording - this is a USB card reader with a Lexar Professional full-format SD card connected, which allows you to record data at only about 15Mb / s with this connection. Although (in the general case), media speeds above 100 megabits for reading and writing will be unimportant for us, since communication with the outside world is limited by this figure. When using disk subsystems, you should think about their power consumption. Winchester 2.5 "consumes ~ 5 watts and will probably require a separate power supply. You should also remember about the specific organization of input-output to Raspberry via USB, obviously, we have one more bottleneck:
So, the test media:
“ Internal ”: MicoSD 8Gb class 10
External: SD 32Gb class 10+ (UHS)
Installation and composition of LAMP
The system should be simple, but have full functionality. Therefore, one requirement is nothing more, but only Apache will hide behind Nginx, since memory allows.
operating system
Minibian is installed on the “internal” media from the image 2015-02-18-wheezy-minibian.img.
This is Debian 7.8 as a minimum for Raspberry. We make a reservation, in the standard repository they expect PHP no higher than 5.5 and Apache no higher than 2.2. This is not an unfortunate restriction, but for this article it is useful to check the possibility of using the latest versions. In order to install PHP 5.6.x and Apache 2.4.x, which are not included in the standard repository, I had to change the source for the 8th version of Raspbian, the system after apt-get upgrade began to have version 8.0.
Apache
Version 2.4.10 (Raspbian). Gzip is included, all the most commonly used modules from the standard distribution are connected, including mod_rewrite, mod_cache ..., not counting those that are enabled by default.
Php
5.6.12-0 + deb8u1 (cli). Runs in Apache as prefork. There are php-curl, php-gd and other popular libraries.
MySQL
5.5.44-0 + deb8u1 - (Raspbian).
Nginx
Nginx / 1.6.2. Nginx is responsible for statics. Gzip compression is included.
Let me remind you that all the logs are written to external media, the MySQL database is there, swap is not disabled, but empty for the entire time of testing.
As auxiliary utilities I use PhpMyAdmin, htop, iostat and webmin. Exim4 is installed, but only for sending messages from forms. As you can see, our server is quite modern and functional. I will disappoint fans of the VESTA control panel - unfortunately, the manufacturer does not support ARM processors and is not going to do this in the near future. Therefore webmin.
Testing
I was not immediately going to do any synthetic tests, because they are more likely from the field of a very distant theory. In practice, everything strongly depends on the nature of the hosted sites, on the load distribution by time, on the communication channel, the number of views, the time of visitors on the site ..., as well as on the settings. In other words, I propose to see what actually turns out on existing sites.
The tested websites are not based on any CMS, but use the display of images from the database on dynamic (PHP) pages, so there can be quite an intense load on MySQL. But there are no AJAX connections at all. Since our hosting does not yet claim to be professional, it is considered sufficient for the test to place 16 active sites with low traffic on it, of which about five are about 100-200 people a day, the rest are not more than 50 visitors for the same time. In total - about 800-900 people a day, which is comparable in terms of acceptable load with low-cost shared hosting. Half of the visitors fall in the evening, the main visits happen at 20-22 hours (~ 300 people in two hours, on average 4 views = 10 views per minute, ~ 700 kb each = 116 kilobytes of traffic per second). We will designate this time “rush hour” and at the same time we will carry out testing. There will be only two types of tests - performance evaluation using third-party services and a report of htop, iostat utilities on real work.
1. The time of generation and loading by the user of pages at "peak hours"
We use only two main parameters - page generation time and page load time, for two types of pages - “heavy” (heavy for the processor, since there are a lot of pictures from MySQL, long generation) and “light” (normal dynamic PHP page). We will repeat each test 10 times to reduce the likelihood of a random result, and we will also use different services.
Let me remind you about the geography of testing servers and about their possible workload. Therefore, the absolute results can vary greatly, this is normal. I did repeated measurements with interruptions of 5-10 minutes in order to get into different load times of services. The channel of the tested Raspberry is gigabit optics, geography is Siberia, 150 guaranteed megabits to Moscow. In order to verify the server’s ability to serve several simultaneous connections, testing was launched simultaneously on the following service sites:
Light page (547 kb, without MySQL access)
PingDom.com, Sweden
Page load time (46 requests): minimum - 925 ms, maximum - 1124 ms, average - 955 ms.
Google PageSpeed Insights
There are no complaints about speed.
Sitespeed.ru
Total page load time 3.9-4.2, average 4.0. Page generation time from 139 to 157, average 145 ms. That's why Google has no complaints - we get into the permissible 200 ms.
`Heavy` page (843 kb, including 38 pictures of 10-15 kb from MySQL)
PingDom.com, Sweden
Page load time (85 requests): minimum - 946 ms, maximum - 1001 ms, average - 973 ms.
Google PageSpeed Insights
There are no complaints about speed.
Sitespeed.ru
Total page load time 5.3-4.2, average 4.0. Page generation time from 158 to 169, average 162 ms.
2. Report of the htop utility
As expected, Htop showed that the main consumer of CPU time is mysql processes. They "ate" 98 minutes from the last day of processor time. What is not surprising - the frequent and “heavy” queries to the base were supposed from us initially. If the pictures were in the nginx cache, we would have an increase in performance, but the test is interesting because it models the increased load on MySQL with a margin, which, by the way, is typical for most CMS.
3. Report of iostat utility
This utility showed average read and write speeds on media:
1. “Internal” media (system) - 0.87 kb / s average reading, 15.5 kb / s average recording (most likely due to nginx caching, there is something to improve in configuration).
2. “External” media (sites, logs, databases) - 2.4 kb / s read and 3 kb / s write (everything is fine here, reading is cached, logs are written).
4. CPU allocation
CPU time distribution by htop, sampling - exactly two days of work (~ 1600 unique visitors served according to Yandex metrics):
mysql 6.8%
htop 1.8%
nginx 0.75%
apache2 <0.3%
For almost the rest of the time, the processor rested.
As a result, we have a large margin for free processor time, a margin for raising the processor frequency, a margin for the speed of recording media. There are many optimizations available for configuring both server programs (putting the nginx cache on a separate medium, for example), and the sites themselves. All together - a good potential for increasing overall productivity.
Total
Our virtual visitor liked the speed of the web server on the microcomputer, despite the fact that there were other simultaneous visits. Thus, despite the bottlenecks (USB and processor), we have a very obvious conclusion - a full-fledged web server on the Raspberry Pi 2 model B is real. Both in software and in technical parameters. Based on the very low workload in the considered option, I will assume that he will be able to quickly serve at least a couple of thousand visitors to the average site (s?) Per day.
Multiprocessing helps to cope with requests faster, there is enough memory for caching, USB data transfer is satisfactory, so the baby server can not only save on electricity, but also make quick (plus inexpensive!) Replacement of failed equipment. Such a system can pay for itself when used on an enterprise network as a corporate server (database server, web server, backup server, file sharing) compared to other popular solutions. And surely be an alternative to virtual hosting in the right hands. Say, on a budget uninterruptible power supply, a microcomputer paired with a router can work for hours, so the issue of short-term (and not so) power outages can be leveled at home, if the provider's site also has UPS. And you can control electricity, give commands to various devices, connect a video camera and various sensors ...
Try, experiment, microcomputers - it's not only inexpensive, but also pleasantly quiet ...