3 ms·
No, you still have a problem in your database. Running a database smoothly with large datasets is the main performance problem for web applications. As fast as
by pytrin 14y ago
No, you still have a problem in your database. Running a database smoothly with large datasets is the main performance problem for web applications. As fast as you can get with smart DB architecture, DB calls still take the bulk of the time compared to code running time.
- jasonlotito 14y agoI think the point is the problem isn't with the database, but with the code not cacheing results. This isn't some new problem. The database shouldn't be the problem because you should be cacheing results.
- pytrin 14y agoCache is a not a solve-all solution. It is useful only for commonly used data, otherwise you just transfer the database problem to a caching problem.
- prodigal_erik 14y agoIf you squint, every database problem is a caching problem. The only reason we store the relations in their up-to-date form is that it's too expensive to continually replay the transaction log from the beginning of time.
- jdub 14y agoSorry, but that simply isn't true for plenty of applications, particularly if they happen to be built on relatively slow platforms like PHP, Ruby, Python, etc. That's even before we get to the bulky frameworks built on top of those! If your data store structure and queries (SQL or otherwise) are designed to perform and scale, you can get in and out very quickly (milliseconds or less), after which you'll spend most of your time turning the data into something useful. (That's even before we talk about caching so you don't have to talk to the data store at all...) Facebook didn't write HipHop (and reduce CPU utilisation by 50%) because their database queries were slow!