Grant Shipley gshipley at
Thu Dec 12 12:18:11 MST 2013

On Thu, Dec 12, 2013 at 12:12 PM, Sasha Pachev <sasha at> wrote:

> >Yikes, that is bad. is actually OpenShift, the project I
> work
> >on. Do you know if this was because poorly written code or the service
> >itself?
> I do not know for sure. If you have access to the code/logs, the site
> is - the date is Sep 14, 2013 MST
> afternoon times.

Contrary to popular belief, and a nice tie in to the security mails on this
thread, we don't any have visibility at all to a users logs or code.  Even
as root, we can't view them with how we implemented SELinux.  All of our
policies were written and maintained by Dan Walsh (one of the creators of

So, I wish I could take a look but alas, I can't. :(

> I find it rather suspicious that the downtime was
> immediately after the race when more than the normal number of people
> are looking at the results. So I am thinking it was site-caused rather
> than cloud caused. If I were to make an educated guess, I would expect
> the problem to have come from something like SELECT * FROM results
> ORDER BY place LIMIT $N,$PAGE_SIZE which is how your average web
> developer will solve the paging problem on first try instead of having
> a key on place and doing SELECT * FROM results WHERE place > $N ORDER
> BY place LIMIT $PAGE_SIZE, and when a few people hit it at once in
> combination with the cloud limiting resources, we have a problem.

Either that or the user created a non-scalable application and it couldn't
handle the amount of HTTP traffic.  Highly doubtful though that a single
gear couldn't handle the amount of traffic from a marathon though.  It
should be able to handle the boston marathon traffic on a single gear IMO
if implemented correctly.

Speaking of which, I am thinking of running it this year now that I move
back west (Phoenix).

> --
> Sasha Pachev
> Fast Running Blog.
> Run. Blog. Improve. Repeat.
> /*
> PLUG:, #utah on
> Unsubscribe:
> Don't fear the penguin.
> */

More information about the PLUG mailing list