0

I am running Bitnami Parse Server (Parse Stack) with included mongoDB on AWS T2.micro EC2 instance. All config is done and forced HTTPS enabled. At the moment, I save image files directly on mongoDB on the same instance as parse-server. When I retrieve the image via nodejs web app (local and Heroku), I get extreme delay, ~3 seconds, whereas when it was hosted by parse.com, downloads were ~200ms max. Image shows this delay.

Loading images from Parse Server and self-hosted mongoDB is very slow and stalls

I have tried the following with no success:

  1. Disabled HTTPS and reverted to default HTTP
  2. Connect to mongoDB on mlab (my previous DB location)
  3. Instead of using DNS CNAME forwarding, used AWS-provided public domain
  4. Tried both on Heroku hosted web app and local

A few other options I am considering (but would like to know the reasons why it may work):

  • Use AWS S3 Bucket for file storage
  • Put mongoDB on a separate EC2 instance (we want to keep cost to minimum for testing)
  • Do a full stack build on our own (not Bitnami)

I am running out of options. The same exact nodejs app will work fine if I connect back to parse.com hosted parse-server with mlab hosted mongodb. Once the initial download occurs, rest are fairly fast. Where is the "Stalled" activity coming from? Content download only took 90ms.

jbro
  • 75
  • 9

1 Answers1

0

It looks like what you want to achieve is too much for a T2.micro instance. Amongst the options you propose, my recommendation is to store the images in a S3 bucket + CloudFront. This would free the server from the task of transferring the assets to the client.

Javier Salmeron
  • 8,365
  • 2
  • 28
  • 23
  • I have investigated further and enabled S3 bucket as the only file serve. All the setup is complete, however, whenever the download go through EC2's proxy to retrieve a file (therefore public would not see s3.amazonaws.com on url, but storage.mydomain.com, enabled via Parse Server S3 File Adapter), I get slower/stalled activity similar to original post. When served straight from S3, it is faster at sub 1s. What could cause this? Is it because t2.micro is not enough? Or is there network setting on EC2 to optimize this? – jbro Dec 07 '16 at 06:52