Using Amazon Machine Learning to Predict the Best Time of Day for Exercise – Pt 1: Overview

A simple application that uses your Fitbit data to recommend the best time of day to workout.

Best Time of The Day Workout Recommendation[su_note note_color=”#d3d3d3″]Note: This is the first post about using Amazon Machine Learning to predict workout intensity. Part 2 will cover the design of the Machine Learning Model. The third post will cover the Lambda and Alexa code used to automate the model. A working model is available via web and Alexa. Code can be found/downloaded from my Hackster site.[/su_note]

A few months ago, one of my former co-workers1 published a brilliant post on Linked about using machine learning to predict his mood. It got me thinking – with all the data at my fingertips, what could – or should – I attempt to predict?

I ultimately decided to focus my attention on fitness. Specifically, I wanted to determine the most optimal time to workout on a given day.

Why? Well, when it comes to fitness, we live in a world of paradoxes.

We have the best fitness information available, the most knowledgeable doctors, and affordable devices to track our health.

We have the best workout options: gyms in every neighborhood; gyms at our offices; online and DVD courses to support fitness at home.

We even have more flexibility in our schedules. Many people work from home at least once a week. Our gyms open earlier and close later. Our employers support and encourage an active lifestyle.

Yet despite this, people struggle to find time to work out. And when we do get to the gym, we are either rushed or distracted – so our workouts become less impactful to our overall health.

texting-in-the-gym-300x300[1]

I built my app to help myself, and others, find the most optimal time of the day to workout. Are my workouts more efficient in the morning? Or do I get better results by working out at noon?

Each user is different, so I had to build the app so that each user’s prediction model was customized to their activities. This was done by building a custom model for each individual user of the application.

I’ll talk in detail about how I designed the machine learning model and how the app is architected in parts 2 and 3 of this topic. In the meantime, feel free to use the web based version of the app or the Alexa skill.

Moving from Apache to Nginx Web Server for better WordPress performance

Moving a WordPress site from Apache to Nginx isn’t easy, but is well worth the effort – if you are on a micro instance and memory is at a premium.

kermit_memeI’ve written multiple posts about optimizing my blog to increase speed (here, here, and here)… unfortunately, my web server continues to crash at least once a day (usually due to a spike in traffic).

I started looking to stripping out unnecessary Apache modules, but had too many problems identifying the required modules for WordPress. After 30 minutes of failed server re-starts, I decided to ditch Apache all together and install Nginx as my webserver.

While Apache is the most well know WordPress webserver, Nginx is growing in popularity (WordPress.com uses Nginx on their site). In order to get a clean install, I created a new t2.micro instance, installed Nginx (and php-fpm) and migrated my WordPress files over 1.

There isn’t a lot of documentation on Nginx: I spent most of my time referencing the instructions at the following sites:

The install wasn’t smooth sailing. I had a beast-of-a-time getting my permalinks to work, and I forgot to change a few of my settings in my wordpress.php conf file (which caused my server to constantly crash).

There are still a few things I need to reconfigure – W3 Total Cache works differently in Nginx, so I’ve ignored it. I also have yet to re-install my certificates for https.

All that being said, my website is as fast as it was when I started my blog – probably due to Nginx, as well as the lack of “bloat” on the server (old WordPress plugins and no MySQL install).

My other call-out is that the use of AWS RDS and an Elastic IP made the most complicated parts of the migration simple.

Tuning Apache to Improve t2.micro Performance

A few simple changes to your Apache config file can greatly improve your micro instance performance.

apache-server-logo[1]Last week, I moved my WordPress DB from my t2.micro instance to RDS, with the hope that the change would improve my website performance (I was originally hosting both the web and DB server on the same EC2 instance). The good news is that I no longer get the “database connection” errors I was wont to receive. Bad news is that I’m still having performance problems: now with Apache.

As a stopgap, I configured an alarm to reboot my instance in case I received a status failure. This was a less-than-ideal fix; my server would reboot multiple times a day – sometimes 2-3 times in a 30 minute window!

Last weekend, I finally got a chance to dedicate time to resolving the issue. I spent most of my time looking at the threading options for Apache – prefork, worker, and event. I tried both prefork (the default) and event (which is the less memory-intensive option of the three). I ultimately stayed with prefork, with the following settings (h/t to Marjin van Deele’s post: Tweaking a AWS EC2-micro instance for WordPress)1.

Timeout 30
KeepAlive On
MaxKeepAliveRequests 50
KeepAliveTimeout 10

<IfModule prefork.c>
    StartServers          3
    MinSpareServers       2
    MaxSpareServers       5
    MaxClients            10
    MaxRequestsPerChild   1000
</IfModule>

Two days later, my server seems to be ok. Next step is to strip out some of the preloaded modules from Apache (as outlined in Hayden James’ post: Strip Down Apache to Improve Performance & Memory Efficiency).

Leveraging RDS to improve performance in the AWS Free Tier

Amazon-RDS[1]Six months ago, I created a Free tier account and got access to a t2.micro instance at no cost (for a year). My plan was to port my old blog over from Blogger (check), freshen up on my Linux skills (check), and to dip my toe into Lambda and DynamoDB waters (check and check).

errorestablishingadatabaseconnection-180x180[1]As the name implies – a micro instance is SMALL (1 vCPU, 1 GiB RAM). Naturally, a micro instance isn’t the most robust1. I was constantly having Apache crash, or getting the dreaded WordPress database connection error.

Fortunately, the Free tier also comes with 750 hours of RDS. So, following the instructions Pascal Alma’s website, I proceeded to move my WordPress DB instance from EC2 to RDS.

The move was straight forward…. with a few hiccups:

  1. I originally planned to use the AWS Database Migration Service, but had a heck of a time getting the endpoints to connect. After 20 minutes of fooling around, I gave up on DMS and instead used the export/import instructions in Mr Alma’s website.
  2. Security, Security, Security – make sure that you allow communication between your EC2 and RDS servers. I have my EC2 instances in one security group and my RDS instance in another, so I needed to alter the security group inbound rules to allow communication between the server (you’ll need this to both move the data and for ongoing operations).2

A few hours later (and honestly what should have taken 30 mins), I was running my blog against the MySQL database instance in RDS.

My only concern is cost; this blog is a hobby and I not looking forward to paying $100 a year for two t2.micro instances (webserver and DB). Maybe I’ll move the web server to a nano instance… food for thought.

AWS Elastic Beanstalk – Managed Platform Updates

AWS Elastic Beanstalk can now update to the latest version of your underlying platform during a specified maintenance window.

ElasticBeanstalk_Thumbnail[1]Last night, I logged into the EC2 instance that supports this blog. Turns out that I’ve been a negligent system administrator – there were 69 updates pending!

The issue of patching and maintenance may seem trivial; however, companies spend millions of dollars keeps the underlying platforms for their enterprise systems up-to-date.

Enter the Managed Platform Updates updates to the AWS Elastic Beanstalk service. As stated on the AWS blog:

You can now choose to have your AWS Elastic Beanstalk environments automatically update to the latest version of the underlying platform running your application during a specified maintenance window. Elastic Beanstalk regularly releases new versions of supported platforms (i.e., Java, PHP, Ruby, Node.js, Python, .NET, Go, and Docker) with operating system, web & application server, and language & framework updates. Previously, you had to manually initiate updates to your Elastic Beanstalk environments using the Elastic Beanstalk console, command line interface (CLI), or API. Now, you can simply select a weekly maintenance window and have Elastic Beanstalk automatically update the platform version of your environment during that window.

It’ll be interesting to see if companies take advantage of this functionality, and if it causes a reduction in TCO for systems as they move to AWS.