Thanks to
GlobaTel , one of the servers (modules) was able to get to the test. How from this article is the
Server on ARM? Made in Russia! . As you understand hosting on ARM, rather than x86, it is at least fresh and it will probably be fashionable. Thank you GlobaTel.
In this post I don’t want to raise much the topic of performance (but it will be), it’s much more interesting to see how seamlessly all the software of my project is started. I only deployed software, I did not move the database of images anywhere. So under the
cat anime-pictures.net i.e. nginx, Python + Pylons + SQLAlchemy, PostgreSQL, Memcached, Redis.
Immediately make a reservation - the note will not be the last, this is only a first impression.

')
Installation
The server is stable Ubuntu 12.04, my project is also running on this version of the OS in hetzner, only the platform is more standard i7-3770 and 32 gigabytes of RAM. After removing and stopping unnecessary services, I began to install the packages I needed:
- PostgreSQL : apt-get install and it's worth it, no problem. To begin with, I used all the default settings (except access) and in 10 minutes deployed a database dump.
- Memcached, Redis : It was still installed from the repository without problems and started, everything is the same as it was on x86.
- Pylons : I installed pip via apt-get and then, after pip I installed virtualenv, and inside I made pip install pylons, which pulls a dozen packages with it. Everything went perfectly, even what gcc required (by itself, the dev packages for python were installed).
- SQLAlchemy : It so happened that through pip I set 0.9, 0.8, 0.7 and everything was set great. But because of the API change for postgres.ARRAY, I had to leave 0.7.
- Pillow (PIL) : Here I thought there would be problems. The fact is that in ubuntu 12.04 there is an outdated version of the PIL, and not a new fork Pillow. Pillow is a library for working with images and it has a lot of C code and links to all sorts of libjpeg, libpng ... In addition, on their website they only say support for 386, amd64 and PPC. So pip install Pillow and everything is going without any problems.
- uwsgi : This is the same specific C code project. Installation through pip also went perfectly.
- nginx : Still no problem. Set up and earned.
- newrelic: I think everyone knows this good service for monitoring systems and applications. Alas, it did not work out with him. They distribute their client binary, and the packages are only for i386 and amd64. I wrote in those support and received a more or less pleasing answer:
Thanks for your support for the ARM server support.
I have added this as a feature request on your behalf. This information will be passed along to the development team.
so it is quite possible that such support will appear soon.
Performance
I didn’t do very serious measurements, since a lot was written about the performance of ARM (in this
article and on phoronix.com). Productivity is small and no one hides it.
For example, the test page rendering time (one of the pages with a picture on the site) was from 0.200 to 0.230 seconds, and after additional settings the DBMS was able to achieve 0.120-0.160 seconds, for comparison, on i7 the page is rendered somewhere in 0.050 seconds. The difference of 3-4 times does not seem terrible.
Then I used the apache bench to test how many pages per second the server can generate. Immediately make a reservation, I checked with 4 and with 8 processes for uwsgi and there was no difference. So, our 4th nuclear ARM server issued 20 requests per second, whereas i7-3770 gave up to 30 requests per second. It says that somewhere I have a narrow neck and I hope to fix it the other day. According to my estimates, I have to issue at least 200 requests per second (earlier there were such results).
Thoughts
- Do not be afraid of the new architecture, at least in python everything works out of the box.
- This is a great replacement for VPS! Purely on the subjective sensations, ARM works as a middle / upper segment VPS. If you need more RAM and more HDD, then the server on the ARM may well replace the VPS. I hope the prices will be comparable.
- Running heavy applications on frameworks such as Pylons and Django is stupid. This can only be done if you have a very small visit.
- For such servers are ideal asynchronous applications in Python / Tornado, or immediately in C ++. Now there are often configurations with Single Page Application, where the backend is just an interface to such fast databases as Redis or MongoDB.
In fact, I want to write a small application (not a spherical benchmark in a vacuum) on Tornado, specifically for this server, and look at the result. I hope everything will turn out and I will write one more note on this topic.
cat / proc / cpuinfoProcessor: Marvell - PJ4Bv7 Processor rev 2 (v7l)
processor: 0
BogoMIPS: 1325.46
processor: 1
BogoMIPS: 1325.46
processor: 2
BogoMIPS: 1325.46
processor: 3
BogoMIPS: 1325.46
Features: swp half thumb fastmult vfp edsp vfpv3 tls
CPU implementer: 0x56
CPU architecture: 7
CPU variant: 0x2
CPU part: 0x584
CPU revision: 2
Hardware: Marvell Armada XP GP Board
Revision: 0000
Serial: 0000000000000000
cat / proc / meminfoMemTotal: 8019640 kB
MemFree: 4065896 kB
Buffers: 115744 kB
Cached: 3421572 kB
SwapCached: 0 kB
Active: 2119148 kB
Inactive: 1654100 kB
Active (anon): 354668 kB
Inactive (anon): 22808 kB
Active (file): 1764480 kB
Inactive (file): 1631292 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 7299036 kB
HighFree: 3635332 kB
LowTotal: 720604 kB
LowFree: 430564 kB
SwapTotal: 16777212 kB
SwapFree: 16777212 kB
Dirty: 48 kB
Writeback: 0 kB
AnonPages: 235956 kB
Mapped: 33484 kB
Shmem: 141548 kB
Slab: 156072 kB
SReclaimable: 92748 kB
SUnreclaim: 63324 kB
KernelStack: 912 kB
PageTables: 2904 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20787032 kB
Committed_AS: 587816 kB
VmallocTotal: 122880 kB
VmallocUsed: 21376 kB
VmallocChunk: 60648 kB
df -hFilesystem Size Used Avail Use% Mounted on
/ dev / sda2 277G 4.6G 259G 2% /
udev 3.9G 4.0K 3.9G 1% / dev
tmpfs 1.6G 296K 1.6G 1% / run
none 5.0M 0 5.0M 0% / run / lock
none 3.9G 0 3.9G 0% / run / shm
/ dev / sda1 1008M 19M 938M 2% / boot