Hi guys,
I feel like sharing some findings about heroku vs galaxy. Its the first experience I am making with deployment to real servers, so do NOT take it too seriously. I am just sharing my thoughts.
Comparision
In my app I have a place where I insert 160 docs into a mongo-collection. I am using Collection2 and have some custom() { } checks that do some checks against other collections to keep the data healthy.
Some more facts… good to know:
- On my macbook it takes 2 seconds to insert those documents.
- Oh and in the cloud I am using ATLAS M10 for 80 $ per month to host mongo in the same datacenter.
- On galaxy I am running the smallest container (512MB 0.5 CPU) for 40$ a month (including PRO features).
- On heroku I am running the FREE dyno, which is available in the “hobby”-package for 7$ per month (512 MB and 1 CPU??).
OK here come some numbers:
On my macbook it takes 2 seconds to insert.
On Galaxy it takes 31 seconds to insert (!!!)
On Heroku it takes 10 seconds to insert.
So for my usecase the FREE (7$) Heroko container is 3x faster than the 40$ galaxy container.
Thats kind of shocking to me.
I have NOT checked how the Standard Galaxy-container (80$ a month) compares, but I feel like MDG should give some more CPU power for this price.
Yes, I guess there are some improvement options to make those inserts faster.
And yes, I am starting to worry about my programming skills… 150 inserts - 30 seconds??? WOHHHHHHHHHHHH. But like I said, there are some other Collection2 custom(){}-checks happening.But here are
Still I have decided to stay with galaxy for now, as Heroku does NOT have kadira and I am still in very early stage of my project.
Are you sure the time is spent on CPU and not on the network?
Sequential database operations, however close the database is to your application, do take a lot of time.
Now I gather you’re mixing in some checks (through your custom validation) so the load may indeed be separated between cpu and network io.
You can try profiling the application, but I guess it would be harder than creating isolated benchmarks.
Perhaps, you may want to create a database independent, cpu intensive test case, deploy that and measure the time to execution.
In any case, I’ve seen many apps suffering from database latency because they’ve been designed to traverse (and join) multiple collections (you see, even sequential reads can be very detrimental).
Well, I am just sure that ALL components (Galaxy/Heroku/Atlas-Mongo) are hosted in the same datacenter (EU-west / Ireland). On galaxy I have IP-whitelisting enabled, which I did NOT have on heroku (simply allowed ALL IPs to access my db).
What performant setup do you recon to kill latency? (if it is the reason)
I just did something funny: I upgraded my galaxy container to STANDARD (PRO - 80$ per month).
Now I get 13-16 seconds on galaxy. Still 3-6 seconds slower than the cheap 7$ heroku dyno.
Well, “same datacenter” does not always mean “same amount of latency”, and sequential db operations in the order of 100s might indeed add up to that kind of difference.
In any case, most of your operation time should be getting spent on network, not CPU.
There are strategies around this problem.
First of all, avoid it if you can, which usually means structuring your database and application logic accordingly.
You can use batch inserts for bulk insert operations.
For reads, you can try things like caching which can be done externally on something like redis, or internally by creating dedicated read views/aggregations for your data, which in fact is a key part of a rather more sophisticated design pattern called CQRS.
3 Likes
@serkandurusoy: Thanks a lot for your help man! You summed it up really nice as always!
It would be really interesting to compare CPU power of galaxy vs. heroko and like you said I agree, that it should be tested by PURE CPU tests. But right now I need to move on and ship my product. Right now I am with galaxy and hopefully (once the money comes in) can affort to stay there.
By the way: A while back I have created a helper-package related to the CQRS approach, which I am using in my own project. https://github.com/thebarty/meteor-denormalized-views.
1 Like
Nice one, good job!
You might also want to take a look at https://atmospherejs.com/space/event-sourcing for some more inspiration if you want to move forward with that pattern.