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

The appeal of serving your web pages with a single process

utcc.utoronto.ca

Post reply on HN
Print view View original

21–30 of 63 posts

Re: The appeal of serving your web pages with a single process

#21

Post by stackskipton »

Aurornis wrote: post #19
AlotOfReading wrote: post #7

Earlier quoted context omitted.

In a former job, I wrote a static PWA to do initial provisioning for robots. A tech would load the page, generate a QR code, and put it in front of the camera to program the robot. When I looked into having this static page hosted on internal infra, it would have also needed minimum two dedicated oncalls, terraform, LB, containerization, security reviews, SLAs, etc. I gave up after the second planning meeting and put…

> When I looked into having this static page hosted on internal infra, it would have also needed minimum two dedicated oncalls, terraform, LB, containerization, security reviews, SLAs, etc. In my experience there are two kinds of infrastructure or platform teams: 1) The friendly team trying to help everyone get things done with reasonable tradeoffs appropriate for the situation 2) The team who thinks their job is to…

Having work as Ops person at second place, most of time it ends up like that because Ops become dumping ground so they throw up walls in vain attempt to stem the tide. Application throwing error logs? Page out Ops. We made a mistake in our deploy. Oh well, page out Ops so they can help us recover. Security has found a vulnerability in a Java library? Sounds like Ops problem to us.

Re: The appeal of serving your web pages with a single process

#23

Post by simonw »

stana wrote: post #22

Would love to explore this in Python. But would it be correct to assume single process service would not be as performant due to GIL?

The GIL means you only get to use a single core for your code that's written in Python, but that limit doesn't hold for parts that use C extensions which release the GIL - and there are a lot of those.

The GIL is also on the way out: Python 3.13 already shipped the first builds of "free threading" Python and 3.14 and onwards will continue to make progress on that front: https://docs.python.org/3/howto/free-threading-python.html

And honestly, a Python web app running on a single core is still likely good for hundreds or even thousands of requests a second. The vast majority of web apps get a fraction of that.

Re: The appeal of serving your web pages with a single process

#24

Post by nine_k »

the__alchemist wrote: post #18
benoau wrote: post #15

Earlier quoted context omitted.

They went from leading / pioneering horizontal scalability and database deploying and scaling and orchestration to "quiet-quitting" 15 years ago and doing almost nothing ever since - today they're barely worthy of mention in any discussion on any tech that solves these problems.

We define worth. I mention Heroku as a great way to make web applications at various scales. Reliable, and easy to use.

Heroku was / is like a mainframe. You get provisioning, scaling, configuration, etc all sorted out for you, as long as you pay through the nose.

Re: The appeal of serving your web pages with a single process

#25

Post by no_protocol »

theideaofcoffee wrote: post #17

Then why not go to the extreme and just build a static version and serve that? Why do you need any dynamic content at all? Then you won't need shared state, then you won't need a database, then you won't need 90% of the stuff that dynamically driven pages need. Be the l33t h4x0r you are and just go static, save the complexity for your build process, because that shows the true hacker spirit. Hell, you may even be abl…

The traditional pattern seen here of serving pages under a hierarchy called `~cks` indicate this is the personal site of someone who is affiliated with the university. Unless otherwise noted you should probably assume all the content is from "cks", not an army of dozens of coders.

Re: The appeal of serving your web pages with a single process

#29

Post by wmf »

fsckboy wrote: post #28

what was that superfast web server, opensource of some sort, from about 25 years ago, single process, single thread? it just raced around a loop taking care of many queued i/o streams

You might be thinking of Nginx.

Today I would not recommend single threading since it won't be able to use multiple cores.

Re: The appeal of serving your web pages with a single process

#30

Post by geewee »

Lord_Zero wrote: post #4

I guess it depends on what world you live in. For example, using ASPNET Core, I just drop in this https://learn.microsoft.com/en-us/aspnet/core/performance/ra... and boom I have rate limiting and I do not have to stress about threads or state or whatever.

That's almost certainly per server instance though, there's no mention of any type of synchronization across multiple instances, so if you e.g run many small ones or run the service as a lambda I'd be surprised if it worked like you expected.
Post reply on HN