ELB Health Check Issue about aws-refarch-wordpress HOT 8 CLOSED

Since the Web Template only completed with "HealthCheckType: EC2" I decided to test/change the ASG configuration in the console to "HealthCheckType: ELB"... Interesting, I have no issues now--I can adjust the ASG instance settings up/down and instances are launching/terminating as expected.

from aws-refarch-wordpress.

I'll take a look at this over the next few days and see if a change to resolve this will be pushing during my next push in the next few days.

from aws-refarch-wordpress.

Darryl, Know I'm currently working with AWS Tech Support as it appears the issue I was having with "HealthCheckType: ELB" are timeout issues due to latency within the site. Not sure why, yet, but the site is slow and that was causing HealthChecks to timeout/fail. If the root cause is something related to the CloudFormation Template (versus our wordpress site) I'll post it here.

from aws-refarch-wordpress.

Michael. Have you been able to resolve your ELB healthcheck issue?

from aws-refarch-wordpress.

Darryl,

Not yet... we have AWS techs reviewing ALB log files and Web Server packet captures as we speak--should have an answer soon.

-Mike

from aws-refarch-wordpress.

Darryl,

FYI, AWS Techs informed me this morning they are going to now involve a CloudFormation engineer in my case--current thinking is still high latency is causing Health Checks to Fail, and they are trying to determine root cause.

Has anyone reported to you any latency issues with this setup that I could bring to the attention of the techs working the case? Particularly, once a site is migrated over or a site is heavily built out?

-Mike

from aws-refarch-wordpress.

Mike,

The only issue we're aware of is related to EFS file systems running out of burst credits which drops the permitted throughput to the baseline throughput of 50 MiB/s per TiB of storage (or 50 KiB/s per GiB). If the WordPress site has a small amount of file system storage on EFS, it doesn't earn enough credits to sustain the throughput it needs and eventually the burst credit balance drops to zero. File systems earn credits at the baseline throughput rate and consume credits at the throughput driven by the site. If you're using more than your earning, eventually it will drop to zero. Performance may be great initially but when the burst credit balance drops to zero and the permitted throughput changes to the baseline throughput, the site experiences performance issues when the file system is unable to achieve the necessary throughput it demands. That's one of the reasons I built the burst credit balance alarms and dashboard, so customers can monitor and get notified on this condition.

from aws-refarch-wordpress.

Darryl,

FYI, The AWS Techs started to go down the EFS burst credit path as well, although I must say, we had the latency issues before the burst credit issues which basically shut down the site. We started our effort on V1.0 and were deep into trouble shooting while you released v2.0.x--so with the holidays and an unexpected priority, we decided to delete v1.0 and will restart with v2.0.1 later this month. As such, I'll close this issue.

Very excited about what you are doing here, can't wait to pick this up again in a couple of weeks.

Regards, Mike

from aws-refarch-wordpress.