Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

success.heroku.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#31

Post by georgeorwell »

dblock wrote: post #17
minimax wrote: post #16

No offense to the Art.sy team, but this is just Heroku marketing copy. It lacks the detail we typically see on these sorts of high scalability "how we did it" posts. Non-trivial applications scale non-trivially, and when someone comes along claiming they have solved the scalability problem with the push of a button I am instantly skeptical. I would really like to see more details about their architecture, especially…

I wrote a blog post on our overall tech stack here: http://artsy.github.com/blog/2012/10/10/artsy-technology-sta... Our MongoHQ integration is very straightforward - MongoHQ provides us with a replica set and we configure it as any other MongoDB database. Feel free to ask any specific questions.

I realize this is off-topic but just as a bug report, I tried to search for "cezanne watercolor" and it didn't understand, despite that you have watercolors by Cézanne. Also it wasn't clear whether watercolors were best found under "paintings" or "works on paper". I think you need to make it easier for non-computer people to find specific types of image.

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#32

Post by dblock »

redguava wrote: post #28
continuations wrote: post #27

Earlier quoted context omitted.

> we use SendGrid and MailChimp to send e-mail. Why do you use both SendGrid and MailChimp for email? Can you talk about the different use cases that require using the different email services?

I don't know about how they do it, but I use both currently. SendGrid for one-off emails (ie. a user signs up for an account, their welcome email). MailChimp for email marketing (we send newsletters via them). MailChimp has since released Mandrill that caters to the one-off emails, but we were already with SendGrid by then.

Same thing for us at Art.sy. We have humans doing targeted emails, with MailChimp.

Sendgrid is an SMTP relay with high deliverability. That's all it does. You can find who received what on the website, too. With MailChimp you have to setup lists and all that unnecessary stuff.

There's one big drawback to using both: we currently have to sync our users to MailChimp and sync MailChimp unsubscribes back. Hence we're going to get rid of MC eventually when we can build good enough UI to manage mass emails.

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#33

Post by dblock »

mh- wrote: post #29
dblock wrote: post #5

Earlier quoted context omitted.

dblock from Art.sy here. The analytics comment is totally fair - we spent a lot of time looking at all kinds of stats as we keep experimenting and it needs to be trimmed down to 1 (or none :)). Our average API response is 380ms. It's about 20x too long as far as I am concerned. It's not Heroku's fault to be fair, there's a mix of Ruby code, database queries and some not so easy to optimize math in some cases. It's de…

my first (cold cache) load of the homepage took about 7-8 seconds to be usable but the rest feels fluid. don't be discouraged, after the initial load it performs better than most sites that look this nice.

Thanks for the kind words. We load 1GB of CSS and JS. OK, maybe I am exaggerating :) It's a constant struggle between "it looks and feels amazing" and "it's super fast".

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#34

Post by bigiain »

dblock wrote: post #5
jcampbell1 wrote: post #3

I'd read this with a grain of salt. I remember looking at art.sy via the NYTimes link and thinking the site was terribly slow. I still find it moderately slow. I am not sure they really need mixpanel, google analytics, and kissmetrics, on every click and the api calls should take less than the 1-4 seconds I am seeing.

dblock from Art.sy here. The analytics comment is totally fair - we spent a lot of time looking at all kinds of stats as we keep experimenting and it needs to be trimmed down to 1 (or none :)). Our average API response is 380ms. It's about 20x too long as far as I am concerned. It's not Heroku's fault to be fair, there's a mix of Ruby code, database queries and some not so easy to optimize math in some cases. It's de…

I suspect I'm well outside your target demographic, but I'm seeing ~22 whole seconds to onload (according to Firebug) here in Sydney, Australia (as 52 requests comprising 1.6Meg of data.)

That certainly seems excessive for a non-logged-in user on your main landing page.

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#35

Post by dblock »

georgeorwell wrote: post #31
dblock wrote: post #17

Earlier quoted context omitted.

I wrote a blog post on our overall tech stack here: http://artsy.github.com/blog/2012/10/10/artsy-technology-sta... Our MongoHQ integration is very straightforward - MongoHQ provides us with a replica set and we configure it as any other MongoDB database. Feel free to ask any specific questions.

I realize this is off-topic but just as a bug report, I tried to search for "cezanne watercolor" and it didn't understand, despite that you have watercolors by Cézanne. Also it wasn't clear whether watercolors were best found under "paintings" or "works on paper". I think you need to make it easier for non-computer people to find specific types of image.

It's an interesting observation. We built a full text semantic search in 2011 by reverse-indexing art search results from popular search engines and it could do things like "Cezanne watercolors" at ease.

We showed it to people and we found that one could easily trick the system with things like "Worst American Art Ever". That generates results, but shows the limits of a general semantic search in a narrow context.

Happy to hear any suggestions about how to make something like this both useful and not too easy to make look really silly.

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#36

Post by dblock »

bigiain wrote: post #34
dblock wrote: post #5

Earlier quoted context omitted.

dblock from Art.sy here. The analytics comment is totally fair - we spent a lot of time looking at all kinds of stats as we keep experimenting and it needs to be trimmed down to 1 (or none :)). Our average API response is 380ms. It's about 20x too long as far as I am concerned. It's not Heroku's fault to be fair, there's a mix of Ruby code, database queries and some not so easy to optimize math in some cases. It's de…

I suspect I'm well outside your target demographic, but I'm seeing ~22 whole seconds to onload (according to Firebug) here in Sydney, Australia (as 52 requests comprising 1.6Meg of data.) That certainly seems excessive for a non-logged-in user on your main landing page.

China and Australia are the worst regions right now in terms of content delivery speed by a factor of 3.

I suspect with a new AWS data center in Australia Cloudfront delivery will become better there soon, and we're looking at Akamai medium term.

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#37

Post by thelarry »

I think this article can be a little misleading. Sure, with cloud tech you can easily spool up more instances. And yes, it is great to not have to worry about configuring a load balancer (I guess). But just because adding more instances sort of fixes a problem doesn't mean it is a good thing to do. Not "having to do calculations" is a very bad attitude. You should know where the bottle necks are, and if adding instances is actually necessary or just some scotch tape. Bad architecture and coding can bite you in ways that adding hardware cannot fix.

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#38

Post by georgeorwell »

dblock wrote: post #35
georgeorwell wrote: post #31

Earlier quoted context omitted.

I realize this is off-topic but just as a bug report, I tried to search for "cezanne watercolor" and it didn't understand, despite that you have watercolors by Cézanne. Also it wasn't clear whether watercolors were best found under "paintings" or "works on paper". I think you need to make it easier for non-computer people to find specific types of image.

It's an interesting observation. We built a full text semantic search in 2011 by reverse-indexing art search results from popular search engines and it could do things like "Cezanne watercolors" at ease. We showed it to people and we found that one could easily trick the system with things like "Worst American Art Ever". That generates results, but shows the limits of a general semantic search in a narrow context. Ha…

Well surely each of them is tagged with both 'cezanne' and 'watercolor', can't you just match search substrings to tags?

Re: How Art.sy survived a NYTimes.com homepage launch with Heroku + MongoHQ

#39

Post by dblock »

georgeorwell wrote: post #38
dblock wrote: post #35

Earlier quoted context omitted.

It's an interesting observation. We built a full text semantic search in 2011 by reverse-indexing art search results from popular search engines and it could do things like "Cezanne watercolors" at ease. We showed it to people and we found that one could easily trick the system with things like "Worst American Art Ever". That generates results, but shows the limits of a general semantic search in a narrow context. Ha…

Well surely each of them is tagged with both 'cezanne' and 'watercolor', can't you just match search substrings to tags?

It only works in that case. What if there's another work that is called "Cezanne's Favorite Watercolor", and we're just in the beginning of search hell :)
Post reply on HN