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

181–190 of 241 posts

Re: MangaDex infrastructure overview

#181

Post by KatKafka »

m45t3r wrote: post #177
AviKav wrote: post #94

Earlier quoted context omitted.

Virtually every chapter is served via MD@H now. Client doesn't really need much availability, as long as it can do a graceful shutdown. Even in the event of a sudden shutdown, the trust penalties are much lower than H@H and in practice go away after a trickle of traffic to raise your score

Nice, didn't know about this (there isn't much information about MD@H after the rewrite). BTW, how can I register my VPS on MD@H? Before we had a dedicated form on the page to register interest, at least after the rewrite I didn't find it. Is it only using something like Discord?

We had a dedicated page for signing up on the v3 version of the site. Currently, yes, it's via our Discord server's MD@H channels.

Re: MangaDex infrastructure overview

#182

Post by thoughtFrame »

vymague wrote: post #171
willvarfar wrote: post #58

Earlier quoted context omitted.

Excellent post, good technical content, amazing feat. That said, I echo that the amazing feat is that they can fit modern inefficient tool choices with poor mechanical sympathy into that budget. The last decade of web-dev tooling has been pushing the TCO of systems through the roof and this post is all about how to struggle against that whilst using those tools. If they went old-school they'd get another order of mag…

> If they went old-school they'd get another order of magnitude savings. Many veterans know of systems doing 10x that in 10x less cost. Remember C10K was in 1999. How to learn more about the old-school way without getting a job related to it? Like, topic or book recommendations.

I'm also curious about this, since in many areas of computing (not only webdev) the old-school guys take some stuff as so obvious that they don't even bother writing about it or explaining it beyond "This is obviously possible, dude". They know how to achieve this level of performance, but for everyone else, we have to cobble together fragmented insights. So if anyone out there reads this and thinks like the GP, please do write about it ;)

Re: MangaDex infrastructure overview

#183

Post by manigandham »

ctvo wrote: post #172
manigandham wrote: post #164

Earlier quoted context omitted.

There are plenty of people who build here on HN (more than most other sites) and the requirements are pretty clearly described in the article. While it's not as simple as a Go program on a VPS, there is certainly a lot of unnecessary overhead here. I think you underestimate just how much poor and wasteful engineering there is out there.

> While it's not as simple as a Go program on a VPS, there is certainly a lot of unnecessary overhead here. I think you underestimate just how much poor and wasteful engineering there is out there. I don't under estimate poor and wasteful engineering at all, but that's not what I saw in the article. Serving traffic is a single element of their design. They also designed for security, redundancy, and observability. Al…

My background is in adtech, which is a unique mix of massive scale, dynamic logic, strict latency requirements, and geographical distribution. I've built complete ad platforms by myself for 3 different companies now so I can confidently say that this is not a difficult scenario. It's a ready-heavy content site with very little interactivity or complexity to each page and can be made much simpler, faster and cheaper.

> "detail in depth how "

This thing seems to be little more than a very complex API and SPA sitting on top of Elasticsearch. These frontend/backend sites are almost always a poor choice compared to a simple server-side framework that just generates pages. ES itself is probably unnecessary depending on the requirements of their search (it doesn't seem to be actual full text indexing of the content but just the metadata). The security and observability also tends to be a problem of their own making and a symptom of too much complexity.

Re: MangaDex infrastructure overview

#184

Post by ctvo »

manigandham wrote: post #183
ctvo wrote: post #172

Earlier quoted context omitted.

> While it's not as simple as a Go program on a VPS, there is certainly a lot of unnecessary overhead here. I think you underestimate just how much poor and wasteful engineering there is out there. I don't under estimate poor and wasteful engineering at all, but that's not what I saw in the article. Serving traffic is a single element of their design. They also designed for security, redundancy, and observability. Al…

My background is in adtech, which is a unique mix of massive scale, dynamic logic, strict latency requirements, and geographical distribution. I've built complete ad platforms by myself for 3 different companies now so I can confidently say that this is not a difficult scenario. It's a ready-heavy content site with very little interactivity or complexity to each page and can be made much simpler, faster and cheaper.…

> My background is in adtech, which is a unique mix of massive scale, dynamic logic, strict latency requirements, and geographical distribution. I've built complete ad platforms by myself for 3 different companies now so I can confidently say that this is not a difficult scenario. It's a ready-heavy content site with very little interactivity or complexity to each page and can be made much simpler, faster and cheaper.

I don't dispute this or your credentials. You've built critical systems in a space where it was a core of the business. If given time, and resources, I have no doubt you could build a custom solution to their problem that was more efficient.

Unstated in this is the type of business MangaDex is, which I have the following assumptions about. I don't think it's unfair to assume that we're mostly on the same page here:

- Small to mid size, at most

- Small engineering team. Need to develop, deploy, support, and maintain solutions.

- Lacks deep systems expertise, or is unable to attract talent that has that expertise ($)

These characteristics are very common in our space. To solve their technical problems, most of the time, they reach for an open source solution (after examining the alternatives like a service).

Now the question is given those constraints, and their other business requirements, how do they best optimize for dimensions they care about? Everything is a trade-off. Everyone who builds knows this. It's unkind to pretend this is a purely technical exercise. And after reading their article, it's obvious they know some of trade-offs they're making, so it's unkind to suggest a naive solution that does nothing but make you feel smarter. I'm not saying you did the above, but some of these comments are outrageous.

Re: MangaDex infrastructure overview

#185

Post by golergka »

radicalbyte wrote: post #116
maxk42 wrote: post #112

Earlier quoted context omitted.

lol > In general the less moving parts you have in a system the more reliable, secure, efficient and cheaper the system becomes. 100% agreed. This is not my first high-traffic site, nor even the highest. (I built the analytics system for a an Alexa top-10 site in 2010, reaching some 30 billion writes / day off of a mere 14 small ec2 instances.) I've never seen a k8s implementation in production that was necessary. I…

Interesting, wouldn't mind having a chat outside of HN if you're interested (see my profile for mail). I've spent much of my career working on systems with active users from the hundreds to low thousands, but which process a huge number (50k/sec scale) jobs/tasks. It's a totally different kettle of fish, and if I'm totally honest I'm shocked at how badly "web" scales and how common these naive and super inefficient i…

> I've spent much of my career working on systems with active users from the hundreds to low thousands, but which process a huge number (50k/sec scale) jobs/tasks.

MMO games, by any chance?

Re: MangaDex infrastructure overview

#186

Post by probotect0r »

maxk42 wrote: post #145
maxk42 wrote: post #132

Earlier quoted context omitted.

My approach to what?

(1) Simple beats complex. (2) You can spend weeks building complex infrastructure or caching systems only to find out that some fixed C in your equation was larger than your overhead savings. In other words: Measure everything. In other other words: Premature optimization is the root of all evil. (3) Fewer moving parts equals less overhead. (Again: Simple beats complex.) It also makes things simpler to reason about.…

Can you share how you do logging/monitoring/alerting for your site?

Re: MangaDex infrastructure overview

#188

Post by chaorace »

vymague wrote: post #154
germanjoey wrote: post #93

Many manga fans have a love/hate relationship with mangadex. On one hand, it's provided hosting for countless hours of entertainment over the years. Their "v3" version of the site was basically perfect from a usability point of view, to the point that the entire community chose to unite itself under its flag. On the other hand, directly because of the above, their hasty self-inflicted take down earlier this year near…

> their hasty self-inflicted take down earlier this year nearly killed the entire hobby It won't kill the hobby. Because these scanlators are making mad money from ads, patreon, crypto mining. I'll never get why they don't get more aggressive take down notices from Chinese/Japanese/Korean publishers.

I suspect it's because the international market for print manga (the primary cash cow) is rather anemic, particularly compared to anime.

Publishers see the loss as minimal and creators see piracy as free advertising to drum up enthusiasm for anime adaptations, which actually do drum up decent profits internationally (the committee keeps the streaming licensing fees, not the animation studio).

Re: MangaDex infrastructure overview

#189

Post by clambordan »

tristan9 wrote: post #151
jiggawatts wrote: post #147

Earlier quoted context omitted.

You're basically dumping down a database to the web browser, including all of the internal metadata that's likely irrelevant to rendering the HTML. For example, user role memberships: { "id": "c80b68c5-09ae-4a50-a447-df7c5a4a6d01", "type": "user", "attributes": { "username": "kinshiki", "roles": [ "ROLE_MEMBER", "ROLE_GROUP_MEMBER", "ROLE_POWER_UPLOADER" ], "version": 1 } } Also record timestamp dates like created/ch…

As I said, it's not so much that we ask that data to be fetched -- it is there in the first place, and pulled from Elasticsearch, not a SQL database Because of this model, we also make sure that Elasticsearch merely works a search cache, not as an authoritative content database (hence everything we add in there is considered public, on purpose, and what isn't meant to be public is just not indexed in ES) However the…

You can query Elastic for specific fields only: https://www.elastic.co/guide/en/elasticsearch/reference/curr...

Edit: As you said, there may be reasons on the backend not to filter things out of the query. Though it seems likely that the web response could be trimmed down.

Re: MangaDex infrastructure overview

#190

Post by kmeisthax »

jiggawatts wrote: post #147
tristan9 wrote: post #141

Earlier quoted context omitted.

> The real problem is that generating that much JSON is very "heavy" on servers. Lots and lots of small object allocations, which gives the garbage collector a ton of work to do. It's also expensive to decode on the browser for similar reasons. For what it's worth, this isn't generated live but a mix of existing entity documents Most of it is page filenames which indeed could be made optional and fetched only by the…

You're basically dumping down a database to the web browser, including all of the internal metadata that's likely irrelevant to rendering the HTML. For example, user role memberships: { "id": "c80b68c5-09ae-4a50-a447-df7c5a4a6d01", "type": "user", "attributes": { "username": "kinshiki", "roles": [ "ROLE_MEMBER", "ROLE_GROUP_MEMBER", "ROLE_POWER_UPLOADER" ], "version": 1 } } Also record timestamp dates like created/ch…

This seems less like a performance problem and more of a security issue. Especially considering that this is a website that hosts unlicensed translations. How much of this information is actually intended to be made public?
Post reply on HN