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

Use one big server

specbranch.com

Post reply on HN
Print view View original

591–600 of 601 posts

Re: Use one big server

#591

Post by hamandcheese »

thayne wrote: post #556
nightshift1 wrote: post #377

Earlier quoted context omitted.

Unless your storage is already mirrored off-site. Ex: EMC srdf

so say the disk fails on your main DB. or for some reason a customer needs data from 6 months ago, which is no longer in your local snapshots. In order to restore the data, you have to transfer the data for the full database back over. With multiple databases, you only have to transfer a single database, not all of your data.

pg_dump has an option to output one-table-per-file. You can use this for selective restores later.

Re: Use one big server

#592

Post by up2isomorphism »

The author missed the most important factor why cloud is dominating the world today. It is never about the actual hardware cost. It is the cost of educating people be able to use that big server. I can guarantee you you will need to pay at least $40k a month to hire someone to be able to write and deploy softwares that can actually realize the performance he claims on that big server. And your chance to be able to find one in 2 month is closed to 0, at least in today’s job market. Also even if you find one , he can leave you in one year to some others places, and your business will be dead.

Re: Use one big server

#593

Post by bretthoerner »

adam_arthur wrote: post #554
julianbuse wrote: post #506

Earlier quoted context omitted.

I'm not sure if you know this, and it might not be useful to you even if you do, but workers can interact with the cache directly: https://developers.cloudflare.com/workers/runtime-apis/cache...

Yes, but the worker is in front of the cache (have to pay for an invocation even if cached), and the worker only interacts with the closest cache edge node, not the entire CDN. But yeah, there are a few hacky ways to work around things. You could have two different URLs and have the client check if the item is stale, if so, call the worker which updates it. I'm doing something similar with durable objects. I can get…

I don't think you should need a cron and an alarm, you should be able to just set (and re-set) an alarm in your Durable Object(s)?

Re: Use one big server

#594

Post by NorwegianDude »

maxbond wrote: post #537
NorwegianDude wrote: post #259

Earlier quoted context omitted.

Hitting the front page of reddit is insignificant, it's not like you'll get anywhere near thousands upon thousands of requests each second. If you have a somewhat normal website and you're not doing something weird then it's easily handled with a single low-end server. If I get so much traffic that scaling becomes a problem then I'll be happy as I would make a ton of money. No need to build to be able to handle the w…

"Hitting the front page of Reddit" is a metanym for, "today you suddenly have many multiples of the previous day's traffic banging down your door, for reasons entirely outside of your control or ability to foresee." I agree this is a huge revenue opportunity - but if you can't stay up, you may not be able to capitalize on it. This & sibling comments seem to imagine that every application is some special case of stati…

What makes you think people are talking about static pages?

Even in the MMORPG case it should be no problem at all if you get a few thousand new players(that would be some insane conversion ratio on reddit/HN traffic). Even cheap servers are fast.

Re: Use one big server

#595

Post by hnlmorg »

spopejoy wrote: post #585
hnlmorg wrote: post #496

Earlier quoted context omitted.

> This is a problem of having succeeded beyond your expectations, which is a problem only unicorns have. Nope. I've worked on a few projects that are not "unicorns" yet have legitimately hit that wall. Particularly around on line gaming and gambling.

Maybe unicorn is not the right word? If your app has millions of DAUs choking your DB, you should at least be tacking your next big investment round or some other success milestone. Otherwise, your product is on it's way to failure, so good thing you did One Big DB...

You’re thinking too Silicon Valley.

These services didn’t need additional rounds of funding and aren't the kind of thing that would scale like a unicorn.

Some services might only been transient (like services based around a particular sports league or TV series) or be regional (like government sites or, also, sports leagues).

Not every service out there has aspirations to “change the world”. Some exist to fill a niche. But sometimes that “niche” still covers millions of people.

Re: Use one big server

#596

Post by sirobg »

zhoujianfu wrote: post #208

10 years ago I had a site running on an 8GB of ram VM ($80/mo?) that ran a site serving over 200K daily active users on a completely dynamic site written in PHP running MySQL locally. Super fast and never went down!

Could you share how long you maintained this website? No problem with the db (schema updates, backups, replication, etc...)? No problem with your app updates (downtime, dependencies updates, code updates)? Did you work alone, or with a team? Did you setup a CI/CD? ...

I wrote down some questions, but in fact I just think it would be interesting to understand what was your setup in a bit more detailed fashion. You probably made some concessions and it seems they worked well for you. Would be interesting to know which ones!

Thanks

Re: Use one big server

#597

Post by GordonS »

hiepph wrote: post #479
fleddr wrote: post #331

Our industry summarized: Hardware engineers are pushing the absolute physical limits of getting state (memory/storage) as close as possible to compute. A monumental accomplishment as impactful as the invention of agriculture and the industrial revolution. Software engineers: let's completely undo all that engineering by moving everything apart as far as possible. Hmmm, still too fast. Let's next add virtualization an…

> The mouse that I'm using right now (an expensive one) has a 2GB desktop Electron app that seems to want to update itself twice a week. I'm using a Logitech MX Master 3, and it comes with the "Logi Options+" to configure the mouse. I'm super frustrated with the cranky and slow app. It updates every other day and crashes often. The experience is much better when I can configure the mouse with an open-source driver [^…

I use Logi Options too, but while it's stable for me, it still uses a bafflingly high amount of CPU. But if I don't run Logi Options, then mouse buttons 3+4 stop working :-/

It's been like that for years.

Logitech's hardware is great, so I don't know why they think it's OK to push out such shite software.

Re: Use one big server

#598

Post by GordonS »

pclmulqdq wrote: post #167
porker wrote: post #23

I like One Big (virtual) Server until you come to software updates. At a current project we have one server running the website in production. It runs an old version of Centos, the web server, MySQL and Elasticsearch all on the one machine. No network RTTs when doing too many MySQL queries on each page - great! But when you want to upgrade one part of that stack... we end up cloning the server, upgrading it, testing…

Containers are your friend here. The sysadmin tools that have grown out of the cloud era are actually really helpful if you don't cloud too much.

What about kernel updates on the host?

Re: Use one big server

#599

Post by adam_arthur »

bretthoerner wrote: post #593
adam_arthur wrote: post #554

Earlier quoted context omitted.

Yes, but the worker is in front of the cache (have to pay for an invocation even if cached), and the worker only interacts with the closest cache edge node, not the entire CDN. But yeah, there are a few hacky ways to work around things. You could have two different URLs and have the client check if the item is stale, if so, call the worker which updates it. I'm doing something similar with durable objects. I can get…

I don't think you should need a cron and an alarm, you should be able to just set (and re-set) an alarm in your Durable Object(s)?

Yes you can do that, and it's what I'm doing. But you have to make a request to the durable object first to instantiate it to set the alarm loop

Re: Use one big server

#600

Post by GordonS »

londons_explore wrote: post #234

Hybrid! If you are at all cost sensitive, you should have some of your own infrastructure, some rented, and some cloud. You should design your stuff to be relatively easily moved and scaled between these. Build with docker and kubernetes and that's pretty easy to do. As your company grows, the infrastructure team can schedule which jobs run where, and get more computation done for less money than just running everyth…

Clouds potentially make this an expensive option because of their silly egress bandwidth fees.
Post reply on HN