Category: Sysadmin

System administration is a special are of IT. It also has a special place in my heart. It is an interesting mixture of all the other disciplines, both common across the whole industry, and at the same time unique for each person, company, and geographical location. When I have something to say or share about system administration, I use this category.

Office 365 Lync Online SRV DNS records on Amazon Route 53

One of the very few things we still rely on from Microsoft at work is Office 365.  Not because it is so great, but because I simply didn’t have the time to move away yet (quiet Christmas season is coming soon).  Most people don’t get exposed much to it anyway, using Evolution or Thunderbird email clients, or forwarding everything to Gmail altogether.  But as an administrator of the service I get constantly annoyed by the “there are problems with your domain” notification.  After ignoring it for about a year, I decided to finally fix it.  All that was needed is a couple of records in the DNS zone.

Unfortunately, the instructions Microsoft provides don’t quite well apply to Amazon Route 53 user interface.  It took me a few tries and some searching to find the right ones.  Here they are, thanks to a comment on this page:

First record:

1. Log into Route 53.
2. in the hosted zones window, check the box next to YOURDOMAIN.com
3. click  [ > Go to Record Sets]
4. Click  [Create Record Set]
5. Enter  _sipfederationtls._tcp , in the Name field
6. Switch type to SRV – Service locator
7. In the Value window Enter: 100 1 5061 sipfed.online.lync.com
8. Click [Create]

Second record:

9. Click  [Create Record Set]
10. Enter: _sip._tls , in the name field
11. Switch type to SRV – Service locator
12. In the Value window Enter: 100 1 443 sipdir.online.lync.com
13. Click [Create]

Five Linux-Ready, Cost-Effective Server Control Panels

webuzo

“Five Linux-Ready, Cost-Effective Server Control Panels” reviews 5 some alternatives to cPanel, which, they say, is rather expensive.  My beef with cPanel is not the price, but the technical merit.  Even though I love the fact that it is written in Perl, I don’t agree with its “let me handle everything” approach.

cPanel installs all the software that it helps to manage.  This might be a “so what” issue for most people, but not for me.  I like my servers clean.  And I want to utilize the tools that already come with my server – RPM, yum/dnf, etc.  Control panels can help with routine, but when something breaks, I should be able to go to the config files and deal with the problem using the distribution’s recommended ways.  cPanel, unfortunately, breaks that.  It downloads sources, applies patches, locally compiles things, and has its own layout for configuration files.  That’s too much mess for me.

I haven’t used any of the other control panels reviewed in the article (I usually prefer the command line way), but I hope they aren’t as intrusive and abusive as cPanel.  Sometimes control panels are useful for providing a bit of help to non-technical users (create mailbox, change email password, backup the website, etc), but if they are as needy as cPanel, thanks, but no thanks.

HTTP Status Dogs

HTTP Status Dogs – Hypertext Transfer Protocol response status codes. And dogs.  If you are even a tiny bit familiar with HTTP or dogs, this will put a smile on your face.  I’m thinking to use these as default error pages from now on.

502

WordPress Benchmark of MySQL server on Amazon EC2

I have a friend who is a newcomer to the world of WordPress.  Until recently, he was mostly working with custom-built systems and a PostgreSQL database engine, so there are many topics to cover.

One of the topics that came up today was the performance of the database engine.  A quick Google search brought up the Benchmark plugin, which we used to compare results from several servers.  (NOTE: you’ll need php-bcmath installed on your server for this plugin to work.)

My friend’s test server showed a rather poor 48 requests / second result.  And that’s on an Intel Core2 Duo E4500 machine with 4 GB of RAM and 160 GB 7200 RPM SATA HDD, running Ubuntu 12.04 x86-64.

So, I tried it on my setup.  My setup is all on Amazon EC2, using the smallest possible t2.micro servers (that’s Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz, with 1 GB of RAM and god knows what kind of hard disk, running Amazon AMI).

First, I ran the benchmark on the test server, which hosts about 20 sites with low traffic (I didn’t want to bring up a separate instance for just a single benchmark run).  MySQL runs on the same instance as the web server.  And here are the results:

Your System Industry Average
CPU Speed: 38,825 BogoWips 24,896 BogoWips
Network Transfer Speed: 97.81 Mbps 11.11 Mbps
Database Queries per Second: 425 Queries/Sec 1,279 Queries/Sec

Secondly, I ran the benchmark on one of the live servers, which also hosts about 20 sites with low traffic. Here though, Nginx web server runs on one instance and the MySQL database on another. Here are the results:

Your System Industry Average
CPU Speed: 37,712 BogoWips 24,901 BogoWips
Network Transfer Speed: 133.91 Mbps 11.15 Mbps
Database Queries per Second: 1,338 Queries/Sec 1,279 Queries/Sec

In both cases, MySQL is v5.5.42, running on the /usr/share/doc/mysql55-server-5.5.42/my-huge.cnf configuration file. (I find it ironically pleasing that the tiniest of Amazon EC2 servers fits perfectly for the huge configuration shipped with documentation.)

The benchmark plugin explains how the numbers are calculated. Here’s what it says about the database queries:

To benchmark your database I use your wp_options table which uses the longtext column type which is the same type used by wp_posts. I do 1000 inserts of 50 paragraphs of text, then 1000 selects, 1000 updates and 1000 deletes. I use the time taken to calculate queries per second based on 4000 queries. This is a good indication of how fast your overall DB performance is in a worst case scenario when nothing is cached.

So, it’s a good number to throw around, but it’s far from the realistic site performance, as your WordPress site will mostly get SELECTs, not INSERTs or UPDATEs or DELETEs. And then, you’ll obviously need to see how many SQL queries do you need per page. And then you’ll need to examine all the caching in play – from browser, web server, WordPress, MySQL, and the operating system. And then, and then, and then.

But for a quick measure, I think, this is a good benchmark. It’s obvious that my friend can get a lot more out of his server without digging too deep. It’s obvious that separating web and database server into two Amazon instances gives you quite a boost. And it’s obvious that I don’t know much about performance measuring.