Don't Bet on Moore Saving Your Ass

http://jeremy.zawodny.com/blog/archives/010841.html

by prakash • 18 years ago

82 78 18 years ago

jeremy.zawodny.com

nihilocrat• 18 years ago

Does anyone know if PostgreSQL has this similar multicore bottleneck?

mdasen4• 18 years ago

PostgreSQL is much better at using multiple cores, but it doesn't matter (at least not for web applications).

Web applications don't have a problem handling one person. They have a problem handling 1,000 people who all want to load a page at the same time. That means that you're not worried about using all your server resources for one query. You're going to have 1,000 queries and so 250 go to each core in a quad-core box and you don't care that MySQL (InnoDB really) doesn't do the multi-core thing because it's not like PostgreSQL would benefit from it since it's just easier to do different queries using a different core.

Multi-core capabilities could help when you are running fewer concurrent queries than you have processor cores. However, once you get to 4-8 concurrent users, you don't need to worry about it so much because you'll saturate all the cores through the different queries and when you're below 4-8 concurrent users you don't need to worry about it because it's easy to serve few users.

Now, for data warehousing and other applications, multi-core capabilities can be the difference between a query taking 1 hour and a query taking 4 hours. But that's not a web application. In fact, using MySQL for data warehousing is just a bad idea.

The author is totally right that you shouldn't just expect technology to save you (and I personally think DHH is taking the "wait until it is a problem. if becomes a problem and new hardware can solve it, do that. if not, then deal with it" approach rather than simply expecting a solution). However, web applications are about running many things at once, not running one big thing.

P.S. Databases usually aren't CPU constrained. It's almost always memory or disk that slows you down. Spend the money on more RAM or better disks and don't worry about the CPU so much.

P.P.S. Both MySQL and PostgreSQL are wonderful databases for web applications so let's not turn this into some silly flame war, please?

Retric2• 18 years ago

Your ignoring the issue of locking, which can effectively transform your multi core CPU in a single core. Secondly databases can be limited depending on what your asking them to do not just what type of work your doing. IMO the largest advantage to multi core CPU's is handing a longer list of requests the the disk controller so it can better optimize the the head's path.

sounddust2• 18 years ago

PostgreSQL is much better at using multiple cores, and it absolutely does matter for web applications.

When you have 1,000 people who all want to load a page at the same time, you're only going to hit the database once for that.

What you will have instead is 5,000 people who want to go to 1,000 different pages, some of them updating data and some of them retrieving it, and you will have 1,000 different queries that are either selects or updates.

Now, PostgreSQL was designed from the start to be robust enough to handle this type of concurrency - to allow the minimum amount of data to be locked while updating, to free the selects from being blocked by those writes. As a result of being built on such a solid foundation, it has been easy to optimize over the years, and has supported the emergence of commmon multi-core computing quite well.

MySQL, on the other hand, was designed to return queries extremely quickly, with as little getting in the way of doing so as possible. Unfortunately, their model did not scale as well. When you have 500 reads and 1 write, and you lock the entire table for that write, it's not a big deal because the write takes no time and you're unblocked again. But when you have an array of hundreds of simultaneous reads and writes, it becomes a mess if you don't have fine-grained locking capabilities. That having been said, MySQL is progressing as well.

But I think (not trying to start a flame war) that PostgreSQL did things slow and right in the beginning and it's paying off pretty well.

Finally, I disagree that databases are not CPU constrained. Any website with decent traffic will have the database entirely cached in RAM at all times, with the only disk activity being the journaling.

andrewf• 18 years ago

Sun has previously demonstrated Postgres scaling well on their 32-way (8 cores x 4 threads/core) hardware. http://it.toolbox.com/blogs/database-soup/postgresql-publish...

russell2• 18 years ago

I think all kinds of components and applications are going to hit the wall. The python interpreter doesn't even support multiple real threads let alone multiple cores. Programmers don't know how to write the code. Here is an article musing about the problems in Java: http://www.devwebsphere.com/devwebsphere/2006/11/multicore_m... Do we all need to learn erlang?

ramchip• 18 years ago

Clojure has put a major emphasis on fixing multithreading for Java - I don't know about garbage collection and problems with the JVM itself, though.

stcredzero3• 18 years ago

I'd rather have some sort of support for multiple cores without real threads.

Stackless seems like a good alternative to Erlang.

Take the two statements above as standalone.

russell2• 18 years ago

I agree that Stackless is better. Threads are very heavyweight. The problem is that the underlying C interpreter works on only one core. If Stackless can work with multiple interpreters then it may be the greatest thing since sliced bread. I haven't been following it closely enough to say for sure.

likpok2• 18 years ago

I seem to recall a benchmark that showed Erlang as much faster than Stackless (for an admittedly relatively arbitrary problem).

Retric2• 18 years ago

One of the few things I liked about Java was how easy it was to do multi-threaded programming. Granted it's clunky but Java network apps are much simpler than doing the same thing in C / C++.

timf3• 18 years ago

Java has a very nice available tool for scaling out a webapp: terracotta.org

eru• 18 years ago

Languages (e.g. Haskell) which support transactional software memory can also be useful.

d0mine3• 18 years ago

`multiprocessing` module is in the Python's stdlib.

timf3• 18 years ago

The parent's statement is still technically right:

"python interpreter doesn't even support multiple real threads let alone multiple cores"

multiprocessing allows you to have the interpreter start another entire OS process (another interpreter). It mimics the threading API.

It's useful and it does allow you to take advantage of multiple cores without unfamiliar APIs which I take it is your point...

You can see in the PEP that for many situations the overhead of processes is not a big concern:

http://www.python.org/dev/peps/pep-0371/

samuel• 18 years ago

Python uses native threads which can be scheduled by the OS to multiple cores. It's just that can't run the interpreter at the same time (C-coded extensions can, and most of them release the lock).

Yeah, not a big difference really.

mattmaroon3• 18 years ago

A website can grow a lot faster than Moore's law would account for.

raghus• 18 years ago

Zuckerberg's Law?

mattmaroon3• 18 years ago

Though I suppose Moore's law has a head start, and grows faster than the overall population. At some point, if it continued indefinitely, databases would become powerful enough to serve 100% of the human population for a typical app on a single server.

icey• 18 years ago

All this Moore's law talk is driving me insane. Improvements in performance are only a side effect of Moore's law.

Moore's law only states that the density of transistors on a chip will double every 2 years. This will fail because of the Zeno's paradox-like effect of limited miniaturization.

At some point, transistors will have to become molecule size, and then atomic, at which point it should be theoretically impossible to get any smaller.

(Sorry for the derailment, and yes, I also go bonkers over centrifugal vs centripetal.)

Finally, DHH may be amazing at writing frameworks, but he is just about the absolute last person I would trust with anything that resembled math.

stcredzero3• 18 years ago

One thing to make note of: if you are in a space where you have massive concurrency, the right kind of hardware can help you out. There was a time in the mid 90's when mainframes with CPUs we would regard as quaintly slow could still achieve I/O throughput that could dwarf the throughput of a PC with an order of magnitude faster CPU.

axod12• 18 years ago

Quite a few webapps just shouldn't be using a db for most things. It's lazy programming.

bmj• 18 years ago

Care to expand on this?

mixmax• 18 years ago

What then?

Asking out of curiosity/ignorance, not trolling

mynameishere• 18 years ago

I think this website (hacker news) just uses persisted hash tables. I'm not sure why he thinks databases indicate "lazy programming" though.

omouse• 18 years ago

You have to be more specific. What do you mean exactly by "db"? a relational DBMS? a file-based one? a tree-based one? document-oriented maybe? column-oriented?

axod12• 18 years ago

Most websites are likely to be using mysql/postgresql.

ruby_roo• 18 years ago

I'm very interested in book recommendations for scaling websites from hundreds of users to millions of users. I'm interested in both database and web server configurations as well as hardware details, and war stories from the trenches. Also, I'd like to know if there bits of wisdom I can incorporate into my 1.0 codebase to make scaling easier should I be fortunate enough to have that problem.

Ideas from the HN crowd?

alecthomas• 18 years ago

Reading articles and watching videos from the engineering teams of big sites is interesting, though not always easily applicable.

For example, the Facebook Engineering Blog (http://www.facebook.com/eblog) or Google Tech Talks (http://au.youtube.com/results?search_query=google+tech+talk+...).

mdasen4• 18 years ago

http://oreilly.com/catalog/9780596102357/

Building Scalable Websites by the Flickr guy.

joshwa• 18 years ago

http://highscalability.com/

likpok2• 18 years ago

One other thing: Moore's law is fundamentally limited. Remember that the limit of the exponential function as t-> infinity is infinity.

This should be enough to show you that at some point, Moore's law will end. It is less important right now (there is still some development going, and new paradigms in the far future) , but the world is not limitless.

zandorg2• 18 years ago

I only just starting using MySQL to store tables of around 100,000 entries. But MySQL would take literally > 30 seconds (sometimes taking minutes) for a query that PostgreSQL (which I installed after it) can handle in 10 seconds.

It seems like MySQL is therefore dreck. I can't see any reason not to use PostgreSQL.

zmimon2• 18 years ago

There's something terribly horribly wrong with either your database setup or your queries. 100,000 entries is miniscule. Do you have indexes on the join columns in your queries?

(But do use Postgres, it's better than MySQL for most cases!)

zandorg2• 18 years ago

I learned SQL at University, but that was 5 years ago so I'm a bit rusty. There's 1 table with a primary key (a string ID), which is used for rows with duplicate ID's, so in theory MySQL should be quick with it.

Thanks for the info, I'll have to dig further, but at least now I know it should be fast even in MySQL.

Don't Bet on Moore Saving Your Ass

Related Stories