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

My £4 a month server can handle 4.2M requests a day

mark.mcnally.je

Post reply on HN
Print view View original

321–330 of 479 posts

Re: My £4 a month server can handle 4.2M requests a day

#321

Post by codebolt »

danudey wrote: post #90
nostrademons wrote: post #20

People tend to severely underestimate how fast modern machines are and overestimate how much you need to spend on hardware. Back in my last startup, I was doing a crypto market intelligence website that subscribed to full trade & order book feeds from the top 10 exchanges. It handled about 3K incoming messages/second (~260M per day), including all of the message parsing, order book update, processing, streaming to we…

A lot of that is due to absolutely lousy code. We had a system management backend at my last company. Loading the users list was unbearably slow; 10+ seconds on a warm cache. Not too terrible, except that most user management tasks required a page reload, so it was just wildly infuriating. Eventually I took a look at the code for the page, which queried LDAP for user data and the database for permissions data. It did…

I'd also add that groups and permissions are probably constant and can be cached with a long timeout.

Re: My £4 a month server can handle 4.2M requests a day

#322

Post by skrebbel »

noduerme wrote: post #310
elcomet wrote: post #303

Earlier quoted context omitted.

He's a frickin genius because he found ways to break the law with impunity for his own profit ? I'm surprised by HN sometimes.

Uh, excuse me, but this whole story demonstrates that I went to extreme lengths to never break any laws , no matter how large or small the jurisdiction. Had I been willing to bend laws, I'd surely be a lot richer today.

Come on, cURL'ing to a foreign server to get a random number and not just reading /dev/urandom is logically identical. It's a hack, just like calling into GPL'ed code over HTTP is a hack to avoid "linking" the GPL'ed code. It doesn't really suddenly turn a site from gambling site into a non-gambling site.

I mean, I have mad respect for the hustle with the former MP etc. I agree with what you say in that you did not actually break the law - because you found a loophole (made a loophole? hustled it? again, I'm impressed). You ran a gambling site from IoM though :-)

Re: My £4 a month server can handle 4.2M requests a day

#323

Post by theptip »

benhoyt wrote: post #165
danudey wrote: post #90

Earlier quoted context omitted.

A lot of that is due to absolutely lousy code. We had a system management backend at my last company. Loading the users list was unbearably slow; 10+ seconds on a warm cache. Not too terrible, except that most user management tasks required a page reload, so it was just wildly infuriating. Eventually I took a look at the code for the page, which queried LDAP for user data and the database for permissions data. It did…

Yeah, I see this a lot. I think it's especially easy to introduce this kind of "accidentally quadratic" behaviour using magical ORMs like Django's, where an innocent-looking attribute access like user.groups can trigger a database query ... access user.groups inside a loop and things get bad quickly. In the case of groups and permissions there's probably only a few of each, so fetching all of them is probably fine. B…

I’m coming around to considering Django-seal to be mandatory for non-trivial applications. It will “seal” a query set so that you can’t make accidental DB lookups after the initial fetch. That way you can be more confident that you are doing the right joins in the initial query, and you are safe from the dreaded O(N) ORM issue.

SqlAlchemy has this as part of the ORM, it should really be part of Django IMO.

Re: My £4 a month server can handle 4.2M requests a day

#324

Post by noduerme »

bcrosby95 wrote: post #315
noduerme wrote: post #268

When I launched my former bitcoin casino in 2011 (it's gone, but it was a casino where all games, even roulette tables were multiplayer, on a platform built from scratch starting in '08), I handled all web requests through a server in Costa Rica that cost about $6/mo. Where I had a shell corporation for $250/year. Once the front end -- the bullet containing the entire casino code, about 250kb -- loaded, from Costa Ri…

Why go through IoM at all? Why not Costa Rica -> Switzerland, rather than Costa Rica -> IoM -> Switzerland?

Good question. The original plan was to take normal payment methods (Visa/MasterCard) but it became apparent after Bush passed the ban on online poker that Costa Rica was going to follow suit (or that visa/mc would soon start holding up payments from CR casinos... in which case we might be stuck with debt we couldn't use to pay winnings). Setting up a CR bank acct as a shell requires you to hand over power of attorney to a CR citizen, and also given how shady the entire corporate structure there was and the legal outfit we hired (who thought we could take $100 deposits as payments through their fake real estate portal) I evaluated other routes. These included landing funds in Cyprus and processing through Israeli banks at a 10% markup, and other shady sounding things. I had begun to give up on my little side code project when Bitcoin showed up. The benefit of the Isle of Man was that all funds could be landed there - in a Bitcoin wallet, on a caged dedicated server - without triggering any other financial issues. the only trouble was randomness and gambling.

Re: My £4 a month server can handle 4.2M requests a day

#325

Post by tinus_hn »

cuu508 wrote: post #225
benhoyt wrote: post #201

Earlier quoted context omitted.

Thanks. Yeah, I think I used that years ago when I first ran into this problem, and it worked well. Whether one uses an ORM or not, one needs to know how to use one's tools. My problem (not just with Django, but with ORMs in general) is how they make bad code look good. Like the following (I don't know Django well anymore, but something like this): users = User.objects.all() for u in user: print(u.name, len(u.comment…

users = User.objects.all() for u in user: print(u.name, len(u.comments)) This is fine if you are working with a small data set. It is inefficient, but if it's quick enough, readability trumps efficiency IMHO. Django ORM has a succinct way of doing the "SELECT COUNT(*)" pattern: users = User.objects.all() for u in user: print(u.name, u.comments.count()) And you can use query annotations to get rid of the N+1 query iss…

> This is fine if you are working with a small data set. It is inefficient, but if it's quick enough, readability trumps efficiency IMHO.

And this is how you end up with the problems the parent is describing. During testing and when you setup the system you always have a small dataset so it appears to work fine. But when it’s real work the system collapses.

Re: My £4 a month server can handle 4.2M requests a day

#327

Post by Cthulhu_ »

elcomet wrote: post #303
Gepsens wrote: post #286

Earlier quoted context omitted.

You're a fricking genius.

He's a frickin genius because he found ways to break the law with impunity for his own profit ? I'm surprised by HN sometimes.

No laws were broken, else they'd be in jail. It's how the big companies that HN worships get away with not paying taxes.

Morally dubious? For sure.

Re: My £4 a month server can handle 4.2M requests a day

#328

Post by disgruntledphd2 »

paulluuk wrote: post #301
b9a2cab5 wrote: post #188

Earlier quoted context omitted.

Abstractions almost always end up leaky. Spark SQL, for example, does whole-stage codegen which collapses multiple project/filter stages into a single compiled stage, but your underlying data format still needs to be memory friendly (i.e. linear accesses, low branching, etc.). The codegen is very naive and the JVM JIT can only do so much. What I've seen is that you need people who deeply understand the system (e.g. S…

What's wrong with relying on data engineers for data engineering?

Spark is very very odd to tune. Like, it seems (from my limited experience) to have the problems common to distributed data processing (skew, it's almost always skew) but because it's lazy, people end up really confused as to what actually drives the performance problems.

That being said, Spark is literally the only (relatively) easy way to run distributed ML that's open source. The competitors are GPU's (if you have a GPU friendly problem) and running multiple Python processes across the network.

(I'm really hoping that people will now school me, and I'll discover a much better way in the comments).

Re: My £4 a month server can handle 4.2M requests a day

#329

Post by Cthulhu_ »

nostrademons wrote: post #20

People tend to severely underestimate how fast modern machines are and overestimate how much you need to spend on hardware. Back in my last startup, I was doing a crypto market intelligence website that subscribed to full trade & order book feeds from the top 10 exchanges. It handled about 3K incoming messages/second (~260M per day), including all of the message parsing, order book update, processing, streaming to we…

They really do, and because of that they reach for over-engineered infrastructure solutions. I mean I get that you'd like to have some redundancy for your webserver and database, maybe some DDOS mitigation, off-site backup, etc, but you don't need an overblown microservices architecture for a low-traffic CRUD application. That just creates problems, instead of solving problems you WISH you had, and it's slower than starting simple.

Re: My £4 a month server can handle 4.2M requests a day

#330

Post by Cthulhu_ »

hypertele-Xii wrote: post #227
Waterluvian wrote: post #191

Earlier quoted context omitted.

What reminded me of this the other day is how MacOS will grow your cursor if you “shake” it to help you find it on a big screen. I was thinking about how they must have a routine that’s constantly taking mouse input, buffering history, and running some algorithm to determine when user input is a mouse “shake”. And how many features like this add up to eat up a nontrivial amount of resources.

Simply moving my USB mouse consumes 10% of my CPU. Computers these days...

Back in the day, moving your mouse made things look like they were processing faster.
Post reply on HN