Tag: aws

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.

Using Amazon CloudFront to speed up my site

Hare-and-Tortoise-300x156[1]For the first few months of it’s existence, this website was slow. I wasn’t sure what the problem was; I thought that maybe I needed more compute (the site is running on a t2.micro EC2 instance). Fortunately, before I switched instance sizes, I did some reading online.

The most helpful site -found here – lists 15 steps to improve performance. After making many of the recommended changes, I found that the largest impact was due to enabling a Content Delivery Network (CDN) and using caching.

I used W3 Total Cache for my cache changes. For my CDN, I used Amazon CloudFront. CloudFront was easy to set-up. Though W3 Total Cache has an option for enabling CDN, I used the WP Offload plugin (as it was already enabled to access my AWS account).

And, just like that, my response times went from 5-8 seconds to 1-3.

 

 

 

A Fitbit Low Battery SMS Notification using AWS – Part 3

In Part 1, I introduced an app that sends an SMS notification when your Fitbit battery is low. Part 2 covered the Authentication Flow of the process. This post describes how the device status is checked and communicated to the user.

Fitbit-SMS-Sched2The flow is as follows:

  1. The CloudWatch Scheduler kicks off a Lambda job that pulls registered users from the DynamoDB table. This information is based to a SNS topic, which in turn…
  2. …kicks off the Lambda function that obtains the Fitbit device info. The Fitbit api is called, and the resulting message is processed by the Lambda function. The device information is stored in and retrieved from the DynamoDB table as needed for processing and history tracking.
  3. If the result was a success then the a message is sent to the SNS topic for the subscribed user – assuming that the battery status is low AND the user has not already been notified.
  4. If a “Token Expired” error is returned, then the Lambda function passes the required information to the Refresh User SNS topic. The Lambda function again calls a Fitbit API; this time to refresh the token.
  5. If the token is refreshed, then the information is saved to the DynamoDB table and passed to the Get Device Info Topic (starting the process all over again)
  6. If a failure occurs, then a message is sent to the user, directing them to re-authorize the application to access their Fitbit account.

Continue reading “A Fitbit Low Battery SMS Notification using AWS – Part 3”

A Fitbit Low Battery SMS Notification using AWS – Part 2

In Part 1, I introduced an app that sends an SMS notification when your Fitbit battery is low. Part 2 covers the Authentication Flow of the process.

Fitbit-SMS-Auth

The flow is as follows:

  1. User accesses the sign-up page (and by default, provides authorization via Fitbit.com). The request is passed through an API Gateway to a Lambda function. The Lambda function calls a Fitbit api to authenticate the user.
  2. The Fitbit authentication returns to the Lambda code. From there: (3) the token is saved to a DynamoDB database, (4) a message is placed on a SNS topic, and (5) a success response is sent back to the webpage
  3. The user information (access_token, refresh_token, and mobile number) is saved to a DynamoDB table
  4. An SNe1079abb478cc4e04d13615bc10aa4ca[1]S topic receives the mobile number as a message
  5. A success message is sent back to the end user.
  6. The SNS topic (step 4) calls a second Lambda function.
  7. The Create_User_Topic lambda function creates a sns topic for the newly authenticated user.
  8. Once the topic is created, a notice is sent to the user’s mobile device – asking to confirm subscription.
  9. The user confirms the subscription.

Continue reading “A Fitbit Low Battery SMS Notification using AWS – Part 2”