3 ms·
> but 1000posts/day? Wow.. While a forum that gets 1000 posts/day is quite active, a database that does an INSERT ever 80s is not even moving.
by onedognight 13y ago
> but 1000posts/day? Wow..
While a forum that gets 1000 posts/day is quite active, a database that does an INSERT ever 80s is not even moving.
- eurleif 13y agoPresumably there were many SELECTs for every INSERT.
- eksith 13y agoYes. Yes there were. :) We always limited transactions for UPDATES and INSERTs that involved more than one table. It was quite the learning experience since you do have to think of different ways of working with data. You get to learn very quickly the difference between what like to store vs. what you actually need to store to get a particular functionality. But that turned to being a boon in the end because we got a much simpler forum as a result. Fewer bells and whistles meant users focused on actual discussion and not ancillary, shiny bits and bobs.
- vidarh 13y agoBut on a machine with 2GB of RAM running a forum that small, pretty much none of those selects should ever need to hit disk - it should all pretty much be in the buffer cache, unless there were lots of full text searches of the entire posting history. EDIT: And that is without any app specific caching.
- vidarh 13y agoFor comparison, 8 years ago I wrote a queuing system that did either in-memory queues, or wrote to sqlite for durability. With a little bit of tuning, the Sqlite queues could handle at the very least hundreds of thousands of messages a day - we never pushed it to it's limit.