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:
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.
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.
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
@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.
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.
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.
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.
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ā¦