Meteor Galaxy Pricing?

you can add more containers if the usage goes up on the overiew submenu:

if you want to use bigger containers go to settings, scaling, and choose the container size you need:

1 Like
https://forums.meteor.com/t/one-galaxy-for-everyone/19247/44?u=mz103&source_topic_id=22380

These user-concerns keep jumping up in lots of places. I think the community would like to have at least some reassurance that thereā€™s going to be better pricing, given the same compute power, later down the line.

2 Likes

thanks. so i should probably wait until the app uses up the memory before upgrading.

what about apps that use images? 4GB wouldnt be big enough.

the GBs stand for the ram, I do not know what is the container limit on storage, but it should start somewhere around 20gb, i think.

Apps that use a large number of images and other assets should upload and request their files from Amazon S3. If you do that, youā€™ll probably never exceed 1gb in storage.

Also, like @geritol said, the ā€œgbā€ on their pricing page stands for RAM. Iā€™m not sure what their storage capacity is.

@helfer @sashko How many concurrent users, on average, can a standard Galaxy instance (512mb, 0.5 ECU) support? I know it depends on how well the application is designed, but Iā€™m curious as to what kind of numbers is Galaxy currently seeing. Itā€™d be great to know this for cost estimates.

1 Like

how do we find out the storage?

Giving customers the right info seems to be a big Galaxy week point.

I do not know.
As @mz103 stated, galaxy is mainly for running apps, not for storing images.
The best is if you store the images in an amazon aws s3 server.

but some apps require storing images?

@rohit2b will probably be best informed to answer what range of connected clients weā€™re seeing. It definitely does vary a lot depending on how the app is built.

The reason we donā€™t give numbers for storage is because every now and then containers need to be moved or restarted, and the storage doesnā€™t persist in that case. We do our best not to move containers, but in some cases we have to, so you should never store anything on disk that cannot be recomputed from things that are stored persistently somewhere else. If you need anything to be stored persistently, you should store that on S3 or some other place outside of your container.

Itā€™s a bit more difficult to build apps that donā€™t rely on storing stuff on the local harddisk, but itā€™s also much more scalable and fault tolerant, which is why I would recommend that everyone do it that way. Itā€™s definitely the emerging best practices for scalable and resilient microservices. Itā€™s a bit more work to start, but youā€™ll feel much better and also sleep better at night :slight_smile:

3 Likes

@rohit2b would you be able to release information about how many concurrent users, on average, a standard Galaxy instance is currently holding?

but galaxy doesnt advertise for microservives, what about people making large scale apps? can galaxy take thousands of users?

That was exactly my point. I havenā€™t found any real or somewhat in-depth reviews and that leaves me skeptical.

Of course, itā€™s just a matter of scaling horizontally. The first bottleneck youā€™ll likely encounter is the db, not galaxy. And there are several options to get around the db issues.

1 Like

using mlab for database. hopefully that will be good enough.

How many concurrent users, on average, can a standard Galaxy instance (512mb, 0.5 ECU) support?

Since this answer very much depends on the architecture of your application, and the workload processing that application is doing per user, itā€™s hard to give an upper limit on the number of concurrent users for a contaner size. You should load test your app on a 512 MB container, and determine scaling for your app from there.

We have seen applications scale the number of concurrently connected clients in to the thousands on 1 GB (Standard) and above sized containers. Whether to use 1 GB, 2 GB (Double) or 4 GB (Quad) for the application to scale really depends on the architecture of your application.

can galaxy take thousands of users?

Yes, we have seen apps on Galaxy to thousands of concurrent users.

3 Likes

@rohit2b what would you recommend for load testing at the current moment?

I have tried Galaxy for a few months and am currently hosting my app on NodeChef.
While I loved the Galaxy interface and portal - bundling of app and DB hosting with NodeChef outweighs the nicety of the portal.

Iā€™ve not had any issues with NodeChef (or Galaxy either to be fair) at all.
Once you setup your container deployment is pretty much a single command, so it is almost just as easy as Galaxy.
Combine the fact that the DB is bundled makes it even easier, I donā€™t need to worry about mLab shutting down the free tier - or paying an extra $20 a month for Mongo hosting.

Iā€™m in Australia though so none of the current PaaS offerings are really ideal as the latency is quite highā€¦ Prior to Galaxy and NodeChef I was running DO droplets out of Singapore.
As much as I love offloading the work to someone like Galaxy or NodeChef - if DO create Australian Droplets I will likely just move back to that.

1 Like

Galaxy is going to start offer hosting in Singapore in the next few months. Mentioning it just in case itā€™s of interest to you.

1 Like

Valuable post, thanks! It seems Nodechef is great for independent developer apps, but apps that might require more scale are better off on Galaxy and some other external MongoDB hosting solution.

Personally I have a number of side projects going on and an app I hosted for my wedding.
It is too expensive to have them all on Galaxy.
NodeChef advertises the lowest tier at $9 - however most apps need more than 128Mb of RAM so you likely need the next level up - however this still works out way cheaper with the DB included.

I am just an amature dev trying to have a bit of fun. More a hobby than anything. This will never be my bread winning side of my lifeā€¦ NodeChef so far has been perfect! Just wish I didnā€™t live on an island across the planetā€¦ haha.

Galaxy was almost perfect too, it is just that taking advantage of the free mLab plan seemed only a temporary solution.

Yeah that is interesting!
Without the database I still need mLab, and with that the mLab free tier is not in Singaporeā€¦
So DBā€“>App communication would be slow.
This would probably compound the issue of being in Australia and make the overall performance much worseā€¦