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

MangaDex infrastructure overview

mangadex.dev

Post reply on HN
Print view View original

81–90 of 241 posts

Re: MangaDex infrastructure overview

#81

Post by uyt »

urlgrey wrote: post #6

I'm amazed that their architecture doesn't include a CDN. These days I expect nearly all high traffic websites to make use of a CDN for all kinds of content, even content that's not cached. They cited Cloudflare not being used due to privacy concerns. It'd be interesting to hear more about that, as well as why other CDNs weren't worth evaluating too.

What they are doing is unfortunately not legal. There were precedents of Cloudflare ratting out manga site operators before which have led to arrests [1] (the person who ran mangamura got a 3 year sentence and a $650k fine [2]). And at some point they were going after mangadex via the same way too [3].

A lot of their infrastructure design choices should be viewed with OPSEC constraints in mind.

[1] https://torrentfreak.com/japan-pirate-site-traffic-collapsed...

[2] https://torrentfreak.com/mangamura-operator-handed-three-yea...

[3] https://torrentfreak.com/mangadex-targeted-by-dmca-subpoena-...

Re: MangaDex infrastructure overview

#82

Post by winrid »

genewitch wrote: post #42
jiggawatts wrote: post #40

What kills me is that this was a rather pedestrian outcome on a much cheaper 2-core virtual machine back in 2007 or so. I easily got 3K requests / sec out of my laptop at the same time, and it was not a trivial app! People's expectations have shifted so much it's absurd. If you look at the TechEmpower benchmarks, ordinary VMs can easily push 100K requests per second, no sweat, even with managed languages. Trivial stu…

In 2011 a company i contracted for was testing some new dell 1U servers with around 1-2TB of ram. There was a postgres database with 4000qps that could fit into tmpfs, and so i restricted postgres to 640Kb of memory and we got replication working, it took about 6 hours of babysitting. We threw the switch and watched as postgres, with 640Kb of ram and a tmpfs backed store proceeded to handle all of the query traffic.…

Postgres handles low memory situations well. It'll kill memory intensive queries before it crashes. I wonder if your application was getting a lot of errors back instead of successful queries :)

Re: MangaDex infrastructure overview

#83

Post by KingOfCoders »

IncRnd wrote: post #45
robertwt7 wrote: post #24

I had nothing but respect for the whole team. Dedicating their time to build everything from scratch, not to mention that they maintain everything for free.. It's a cool project, not sure if there's a way for anyone to contribute. I"ll join the discord afterwork to see if they need any extra hand. Gee, how do these people find other people online to work on all of the cool projects. I would love to join rather than p…

Okay, but isn't most of their content stolen? Why would you want to contribute to that?

Yes of course it is stolen. And people claiming otherwise are the same people who come here and ask "What can I do, some Chinese company ripped of my website?!?!?!"

Re: MangaDex infrastructure overview

#84

Post by Hamuko »

dharmab wrote: post #29
TekMol wrote: post #28

My cheap $20/month VPS serves tens of thousands a user per day without breaking much of a sweat. Using a good old LAMP stack (Linux, Apache, MariaDB, PHP). I don't know how many requests per second it can handle. Trying a guess via curl: time curl --insecure --header 'Host: www.mysite.com' https://127.0.0.1 > test This gives me 0.03s So it could handle about 30 requests per second? Or 30x the number of CPUs? What do…

Does it serve 20-40 hi resolution images and uploads per user?

Hosting static files isn't really that hard. I used to host a website that at its best served around 1000 GB of video content in 24 hours. Of course, it wasn't the fastest without a CDN but it was just 25 €/month.

Re: MangaDex infrastructure overview

#85

Post by sofixa »

bawolff wrote: post #25
urlgrey wrote: post #6

I'm amazed that their architecture doesn't include a CDN. These days I expect nearly all high traffic websites to make use of a CDN for all kinds of content, even content that's not cached. They cited Cloudflare not being used due to privacy concerns. It'd be interesting to hear more about that, as well as why other CDNs weren't worth evaluating too.

What's the benefit of a cdn if nothing is cacheable? Slightly lower latency on the tcp/tls handshake? That seems pretty insignificant.

In their case (manga), seems like the vast majority of the content is cacheable.

Re: MangaDex infrastructure overview

#86

Post by bob1029 »

colesantiago wrote: post #65
jiggawatts wrote: post #40

What kills me is that this was a rather pedestrian outcome on a much cheaper 2-core virtual machine back in 2007 or so. I easily got 3K requests / sec out of my laptop at the same time, and it was not a trivial app! People's expectations have shifted so much it's absurd. If you look at the TechEmpower benchmarks, ordinary VMs can easily push 100K requests per second, no sweat, even with managed languages. Trivial stu…

Not just you, but if it works for them, that's completely fine. But there are many ways to achieve 20K RPS without this type architecture and especially without k8s, for less than $1,500.

>20k RPS.

If this metric is what you are chasing, there are ways to reliably break 1 million RPS using a single box if you don't play the shiny BS tech game. The moment you involve multiple computers and containers, you are typically removed from this level of performance. Going from 2,000 to 2,000,000 RPS (serialized throughput) requires many ideological sacrifices.

Mechanical sympathy (ring buffers, batching, minimizing latency) can save you unbelievable amounts of margin and time when properly utilized.

Re: MangaDex infrastructure overview

#87

Post by sofixa »

baybal2 wrote: post #20
urlgrey wrote: post #6

I'm amazed that their architecture doesn't include a CDN. These days I expect nearly all high traffic websites to make use of a CDN for all kinds of content, even content that's not cached. They cited Cloudflare not being used due to privacy concerns. It'd be interesting to hear more about that, as well as why other CDNs weren't worth evaluating too.

Properly tuned NGINX on a physical server can handle incomparably large load for static content than some of the "cloud" storages around. The "trick" has really been known for a decade, or more. Have as many things static as possible, and only use backend logic for the barest minimum.

That's the raison d'être of nginx, so it is performant for this kind of thing. However, the advantage of a CDN is that they have points of presence around the world, so your user in Singapore doesn't have to do a trip around the world to get to your nginx on a physical box in Lisbon.

Re: MangaDex infrastructure overview

#88

Post by sofixa »

jprupp wrote: post #73

This is complexity for complexity's sake. Pay no attention to the disclaimer at the start of the article. They threw every buzzword-heavy bit of tech they could find at it, creating a Frankenstein monster.

Completely disagree. How would you do it in a simpler way, while keeping the features like redundancy ( including storage), logs, metrics, etc?

Re: MangaDex infrastructure overview

#89

Post by hsn915 »

I don't understand. Why is 2k requests/sec supposed to be massive?

Try this yourself: write a simple web server in Go, host it on a cheap VPS provider, let's say at the option that costs $20/mo. Your website will be able to handle more than 1k/s requests with hardly any resource usage.

ok, let's assume you're doing some complicated things.

So what? You can scale vertically, upgrade to the $120/mo server. Your website now should be able to comfortably handle 5k req/s

Looking at the website itself, mangadex.org, it doesn't even host the manga itself. The whole website is just an index that links to manga on external websites. All you are doing is storing metadata and displaying it as a webpage. The easiest problem on the web.

So, I really don't understand the premise behind the whole post.

The problem statement is:

> In practice, we currently see peaks of above 2000 requests every single second during prime time.

This is great in terms of success as a website, but it's underwhelming in terms of describing a technical problem.

Re: MangaDex infrastructure overview

#90

Post by neonbones »

IncRnd wrote: post #45
robertwt7 wrote: post #24

I had nothing but respect for the whole team. Dedicating their time to build everything from scratch, not to mention that they maintain everything for free.. It's a cool project, not sure if there's a way for anyone to contribute. I"ll join the discord afterwork to see if they need any extra hand. Gee, how do these people find other people online to work on all of the cool projects. I would love to join rather than p…

Okay, but isn't most of their content stolen? Why would you want to contribute to that?

The world of scanlations is always on edge. Usually, when publishers announce official translations of manga titles, fans drop translations of this title. It's not rare that publishers hire fans who were translating this title before for free as an official team.

To be more precise, the real reason why such sites are alive is that they delete titles that got licenses in Europe and the USA. Still, publishers can measure the popularity of titles and buy legal rights to publish it, because it's popular enough. It's harder to find manga "raws" than translated versions.

And by that, they're not 100% "illegal" for the western world, and asian companies are not so interested in fighting with scanlations because they need to combat piracy in their part of the world.

Post reply on HN