Hacker News Reader

Hacker News

Comment by Supermancho | Hacker News Reader

Full thread

Supermancho

Most interesting bit for me was to hear

---

Most of our sites use the following as a base:

Nginx

PHP

MySQL

Memcached and/or Redis

View on HN

Another former developer here [1][2]; the memcached cluster is what keeps the entire thing afloat.

We used to have dedicated 50 Gbps fiber connections straight between the web and memcached nodes, but now the caching is done locally on the web servers with a lot more of them. I would say there's probably something like 100+ servers, 128/256GB RAM each.

All the pages are server-side rendered. Every DB query, every DAO object instantiated, every partial/full page HTML render, even some functions at times, gets put into cache. We weren't really afraid of high traffic, that scaled almost on its own... instead we were afraid of infrastructure maintenance or bad manipulations, because too much of the cache could disappear at once.

The most incredible part to me was the storage and delivery of the video content. Try to picture 7000 petabytes [3] :)

[1] https://www.pornhub.com/humans.txt [2] https://github.com/nitrix [3] https://www.pornhub.com/insights/2019-year-in-review

> All the pages are server-side rendered

I should add that this wasn't out of optimisation, just "old-school" PHP+Html with an MVC framework to serve the rendered page.

Still can't beat that in my view.

> The most incredible part to me was the storage and delivery of the video content

That was the fun bit, I still remember the logistic of opening a new origin for the CDN back in 2010 (11 maybe?). Flying hard drives, can't beat that bandwidth.

(Former developer here as well, however from before this humans.txt was introduced)

Former Ashley Madison here with basically the same tech stack.

Hello fellow former PH dev. ;)

At risk of making a useless comment: "nice".

Local memcached's? local caches or still distributed cache?

What did you find interesting about this? Seems like a typical stack to me.

The stack of a major site could include words you haven't heard yet, prompting urgent studying. Or it could be a bunch of traditional stuff like here, implying a whole lot of new tech could be overhyped. If they can do it with PHP and MySQL, why not your project? :-)

I worked at the second largest adult content network about 10 years ago. They used the same stack mentioned in the article. The design philosophy was about simplicity and continuity above all. They didn't want to use newer technology because it's hard to find people to support it. They didn't even like you to use regular expressions when case statements could be used. Regex is too conceptually complicated.

If you can host and serve porn on a LAMP stack from a traditional bare metal server data center, the guy on the other end doesn't care as long as it's reliable.

I work at a large tech company now and it amazes me how terribly executed and unnecessarily complex most development efforts are. There was a very strong results-oriented culture at the adult media company.

It's funny how in 2020 PHP use is a sharply bimodal signal—it either means your tech leadership is clueless/absent/hopelessly-terrible, or they are among the few who've achieved true enlightenment.

PHP is a very robust, debugged, proven, workhorse language, with millions of pages of documentation, tens (probably hundreds) of thousands of seasoned developers, huge libraries and communities of support, decades of experience, strong, universal, server support, and is used on a lot of "big pipe" servers.

Like C++, it's not going anywhere, anytime soon; despite all the kvetching about it.

That said, I don't especially like the language, but I knew that I needed to use it, if I wanted to design an infrastructure system that I could throw over the wall to be taken over by a bunch of other people.

I was right.

There's that old urban myth about the fancy space pen, vs. the pencil.[0]

[0] https://www.scientificamerican.com/article/fact-or-fiction-n...

In many ways I preferred PHP4. Can't stand all the pseudo-Java in PHP5+.

You can still (mostly) code in PHP4 style and ignore all the new cruft and syntactic sugar they added over the years. And you get the performance boost of 7.x for "free".

Yes, I suppose what really worries me about the "Modern PHP" movement how it looks down on anything that isn't Java-style OO. Procedural PHP is now considered to be some kind of unwashed Cinderella. I cringe when I look at a typical PSR-compliant page of PHP with its K&R braces, blank lines between each line of code and fanfold doc comments. You're lucky if you get more than a handful of lines of business logic on a screen.

I never learned Java until late in my career (when I learned up on Android). I started as an EE, and my programming has been primarily self-taught.

PHP is a kind of crappy OO language, but it is sufficient. I think Java is a better language, for OO. PHP 7+ is lot better than it was, before 5.

A lot of Java programmers came out of school, and started to create PHP chimeras. I feel as if that results in unnecessarily complex code. Things are complex enough, without applying UI-style MVC to server backend systems.

I wrote PHP for around twenty years, starting off procedural and mixed into HTML pages, to OO-based pure PHP systems.

I stopped a couple of years ago. This was my final PHP project[0][1]. It was sort of a "dissertation." No one is actually interested in using it, but it was developed in order to practice my architectural skills. It's a pretty intense system.

[0] https://riftvalleysoftware.com/work/open-source-projects/#ba...

[1] https://github.com/RiftValleySoftware/basalt/tree/master

It's crazy how conservative most high-reliablity high-volume stuff is on the technical side. And yet, especially the porn industry, is quite on the fore front of other tech, like VR, DVD, VCR,...

They don't seem any different from other industries in this respect. A lot of banks still run on systems originally designed in the 60s. So they are conservative from an operations perspective. But most of the big ones have no issues pumping money into the latest financial fad, so they are pretty flexible from a product perspective.

Their content is relatively cheap to produce and it tends to be churned out at a high frequency. There's almost no industry out there that matches the frequency of content they produce, except maybe radio (and now YouTube). And with new technology, the limiting factor is almost always content creation.

So it makes sense that they'd put aside a few dollars buy some new equipment for some trend. Doing a VR shoot probably involves a new camera and a plugin for Premiere.

i truly believe that a lot of devs make stuff often much more difficult than necessary JUST for the sake of it. reason is probably that the main product is boring af, so you need some distraction to keep it interesting :-)

> They didn't even like you to use regular expressions when case statements could be used.

I'm confused. How are those two related? Case statements can replace if statements and can be used for exhaustiveness checking. Regexes are for parsing strings.

I think the point was that even within the codebase, simplicity and reduced complexity was preferred over perhaps a "cleaner" or more advanced approach.

So managing a bunch of hard-coded code paths via a switch instead of using a regex to pattern-match.

It's less future-proof, but even an entry-level dev can reason about a switch statement and update it as needed.

This is exactly it. The nuances of regex patterns can be misconstrued. Obviously if the regex used for flow control cannot be sensibly translated to more traditional conditional statements, then they are permitted. Even in that case, the "simplest" regex was preferred.

All of the stuff you can do with regexes can be done with some hand written code. Since thst code often implements the FSM for the regex, it contains a fair share of case statements.

The benefit is that the regex library costs a lot in hidden complexity - debugging why a particular regex works slowly or eats lots of memory is hard. If a similar problem pops up in hand written code, you can use your standard profilers and other tools to see what's happening.

I can't begin to imagine how much MORE complicated reproducing a regex long-hand might be. They were invented to solve real problems.

The corresponding FSM usually isn't too bad. I've personally never really used regexes that much in production code, but I guess I don't work with strings very often.

It's actually pretty easy to hardcode a regex. Most CS degrees expose students to how finite state machines work and that's all that's needed.

It's not always simple. Regexes have inherent complexity because the equivalent FSM is, in general case, nondeterministic. This implies it cannot always be easily simulated.

So you either drag this complexity into your code or dump it on the regex library. It's a trade-off.

Well, I read Jeffrey Friedl's "Mastering Regular Expressions" two or three times since the 2nd edition was released and I can tell you there's no way anything more than a simple regex is going to be easier to grok when converted to some FSM, especially with look-behind or lazy operators and significant backtracking. I'm referring to the Perl/PCRE regular expression flavour which is the only variant that matters to me. Perl regexen are NFA so I'm not sure your assumptions about FSMs apply.

> debugging why a particular regex works slowly

I encountered one of these once. A user decided to enter this in the middle of their post:

  ------------------------------

It triggered catastrophic backtracking, and IIRC, 16 characters was right around where you could see noticeable delay, then at about 19 was when it ran so long it never returned.

Because my resume needs new tech buzzwords to look good to recruiters/hiring managers.

Very true, which is why I, as a manager, ask senior devs during interviews why they made those choices and how they integrated and deployed the changes. In a lot of cases it turns out their flashy new tech choices were for one-off greenfield projects that were support systems and not primary production systems. I'm usually more interested in how they improved prod systems using the existing stack. This helps me figure out if they're into maintenance work or if they're only interested in tinkering with shiny new things. Both activities have their places on dev teams, but I take it consideration for the actual role I'm filling.

Yeah, reading too much HN might make you think that the only way to write a scalable website is to write your backend in Rust, use Kubernetes, Cassandra w/ PostgreSQL, Kafka, and Hadoop, and TypeScript w/ Webpack and complex functions compiled to WASM.

The K8 cult annoys me most. When Kubernetes and Docker hit the scene YAGNI was the idiomatic response to any scaling scenario which involved less than a massive fleet of servers. Now every solo dev looking to launch his tiny Node app on AWS is expected to use Docker and Kubernetes. Utter madness.

I'm curious is if there was experimentation or not, and what's their attitude towards this.

It totally makes sense to use PHP and MySQL as it's what already works, and because there's a team who knows how to use those correctly in this kind of environment.

I just wonder if they have a research-oriented team that could experiment with whatever they see as a potential fit and see if they can improve performance, developer experience (without sacrificing performance) or both. Or if they don't (and if so - why?)

Facebook is kind of famous for this, as they came up with HipHop VM and Hack.

We experimented with HHVM, had a preview version of it very early on but ultimately the extension support was too bad and the performance gain just not impressive enough to justify moving away from the existing stack.

We didn't have a research-oriented team per say, but myself and a colleague (I was Lead Dev and he Senior) did spend a lot of time experimenting with things like Redis (back when it was very early and "unproven"), varnish, PHP engine tweaks, custom extensions, ... We still did feature work and regular stuff too.

I worked at SG years back (~2005) and that was the stack sans-redis.

On my resume I don’t list the company name. In its place it says “social network centered around ‘art’” because we weren’t allowed to call it porn.

Reply on news.ycombinator.com