Migration: WordPress + MariaDB (MySQL) + PHP + EC2 + CoudFront

I previously wrote about how and why I was migrating away from Hosteurope to Amazon AWS. The basics steps sounded very simple:

  1. Backup databases and data directories on the old server
  2. Set up the new server including all software & services needed
  3. Restore all backups to the new server
  4. Change DNS setting to apply changes to all visitors

Sounds easy, right?

Everyone who’s done that kind of thing before, knows it’s never quite that easy. Doing the first step is quite straight forward. Not a big deal. For the second step I ended up using a combination of howtos to get everything set up properly:

  1. Official AWS EC2: Linux+Apache+MySQL/MariaDB+PHP
    Tutorial: Install a LAMP Web Server on Amazon Linux 2
  2. Official AWS EC2: WordPress
    Tutorial: Hosting a WordPress Blog with Amazon Linux
  3. Working CloudFront Config for WordPress:
    Setting up WordPress behind Amazon CloudFront
  4. General WordPress on t2.nano Instance:
    How I made a tiny t2.nano EC2 instance handle thousands of monthly visitors using CloudFront

My main goal was to run the smallest instance AWS has (currently t3.nano) which costs around $3.75 per month. It turned out, MariaDB (and for that also MySQL) does not start up properly at the nano instance with just 512MB of RAM. Therefore, I had to go at minimum with the t3.micro instance.

To ensure that load spikes are being handled properly and the server will not go offline during these peak times, a content distribution network (CDN) comes in handy. The great thing about AWS is that they’ve thought of all these scenarios and of course they’ve got a CDN solution ready to deploy. It’s called CloudFront. The tricky part here is, to have CloudFront kick in at the right time, because it caches content to deliver it from its own edge locations across the globe, but at the same time WordPress generates websites dynamically. So CloudFront needs to be able to work in that environment. Setting up CloudFront properly was the part that cost most time, but it works great now.

CloudFront Network Map

I have now deployed CloudFront with multiple sites all running on the same t3.micro instance. One by one I activated for CloudFront distribution and over the past couple of days the traffic handled by CloudFront is going up continuously.

CloudFront Cache Statistics

To run massive load tests I used Apache JMeter for the first time. It’s a monster when it comes to load testing and it took me about an hour to get it running the first time. You can literally configure everything on there.

As it is when you’re setting up new things, you’ll have many “new things” you’re working with. In my case, it was the first time I used MariaDB, which is a fork from MySQL. It was also the first time I worked with php-fpm, which “is an alternative PHP FastCGI implementation with some additional features useful for sites of any size, especially busier sites”.

So far I’m quite happy with the current set up. Let’s see how this performs over time. My sites are constantly under attack from bots who are trying to figure out passwords and gain access otherwise to those sites. Yet, every site and server can and will eventually go down under just enough Denial of Service attacks. At the current attack level we’re doing OK, but let’s see how long this lasts and what adjustments I’ll have to deploy.

Please follow and like us:

Ganz viele Apachen machen nicht ganz so schnell schlapp

Ich bin echt ein bißchen beeindruckt, dass Apache bei der Serverauslastung nicht sofort komplett dicht macht. Auch wenn es trotzdem nach einigen Stunden dann passiert, so versuchen meine vielen kleinen Indianer-Gabeln doch ihren Job so gut wie möglich zu machen. Respekt.

screen-shot-2010-05-20-at-100352-am

Trotzdem sollte man vielleicht über ein allgemeines Tuning nachdenken. Eine halbe Minute Wartezeit für das Laden einer Webseite kann man ja keinem zumuten.

Please follow and like us:

Neuer Server, neues Glück

… oder mehr im Geldbeutel. Ja, der Kozi hat sich einen neuen Server bestellt und wir seinen hier laufenden Server4You Root Server bald abstellen. Auch wenn es “cool” ist einen Root Server zu haben, mit dem man fast alles machen kann, so ist er ja nun nicht wirklich nötig. Auch wenn die 44 Euro im Monat nicht so sehr auf den Geldbeutel drücken, so ist er ja nun nicht wirklich erforderlich, um meinen Blog (und vielleicht noch ein paar Bilder) zu hosten. Außerdem habe ich meine Updatefaulheit in Bezug auf das hier laufende FreeBSD etwas ins absurde getrieben. Nach fast 4 Jahren gibt es so viele Updates und Sicherheitspatches für mein FreeBSD 5.4-RELEASE-p11, dass ich gar nicht soweit zählen kann.

Hinzu kommt, dass neue WordPress-Versionen rummucken auf meiner alten Kiste. Wenn ich versuche bestimmte Seite mit irgendeinen Browser unter Mac OS X aufzurufen, schmiert der Indianer-Prozess weg und schreibt mir in das Apache-Log:

[Sun Nov 8 13:49:40 2009] [notice] child pid 489 exit signal Abort trap (6)

Erstmal steht der Kram im falschen Log, da das eigentlich eine OS-Fehlermeldung ist, und keine vom Apache. Klasse Fehlermeldung ist es noch dazu! Im Internet gibts nur ca. 3 Berichte da drüber und alle von FreeBSD Leuten. Lange Rede kurze Lösung: Updaten du fauler Koz! Wie schon erwähnt, das ist leichter gesagt, als getan. Naja, nun habe ich einen neuen VPS von Hosteurope mit schickem Debian druffn.

Hier das Wichtige liebe Tausende von Lesern: Die kommenden Tage wird der Blog umgezogen und er kann durchaus für eine kurze Zeit nicht erreichbar sein. Auch wenn ich damit nicht rechne.

P.S.: Die 31 Euro pro Monat, die ich spare, werden natürlich in die Rente angelegt.
P.P.S.: Eigentlich wollte ich ja nur ein bisschen Artikel schreiben hier, damit das häßliche Vieh endlich von der Startseite wegkommt!

Please follow and like us: