> Simon Slavin <mailto:slavins at bigfraud.org> > 19 f?vrier 2015 08:54 > > It may be a note in whentouse.html should distinguish between > situations where the database is frequently written-to and situations > where you have data which is rarely changed. The lack of writes means > that a lot of advantages of client/server systems give little > advantage. The SQLite web site is a good example.
yes, that's why it would be interesting that there is a writing in the database at each visit of page, to see if SQLite can handle it. With WAL mode and good material, this may be possible. This can be done by step, so as not to bring down the site. For example, at first, a write every 100 page visits, then if there is no problem, 80, etc. Sqlite is known and famous now. But his multi-user capabilities, WAL mode, are *much* less known. On the side of marketing, it is its weak point. I think it is important to raise awareness of the possibilities of WAL mode. And what better way than to show a real website with thousands of writing every day at the same time that hundreds of thousands of reading? Many developers (there are idlers everywhere!) need to show to their hierarchy of actual usage examples. Otherwise, the hierarchy will take a decision on the only reputation of the product: very good single-user database. They will be very reluctant to any other type of use. > I have an example where I have a completely static 40 Gigabyte (sic.) > SQLite web-facing database which is accessed using PHP. It doesn't > have as many reads as the SQLite web site but it's a great test of a > 40 Gig database file and shows no bad affects related to its size. And > SQLite searches billions (sic.) of rows so quickly that one frequent > user suspected it wasn't working properly and I had to explain > tree-based indexes to him. Interestingly, thank you Simon! Maybe on the SQLite website, a page might list these cases of actual use, to show that SQLite can handle a variety of situations. Olivier > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > Olivier <mailto:paxdo at mac.com> > 19 f?vrier 2015 08:31 > Hello all, > > https://www.sqlite.org/whentouse.html : > "The amount of web traffic that SQLite can handle depends on how > heavily the website uses its database. Generally speaking, any site > that gets fewer than 100K hits/day should work fine with SQLite. The > 100K hits/day figure is a conservative estimate, not a hard upper > bound. SQLite has been demonstrated to work with 10 times that amount > of traffic. > > The SQLite website (https://www.sqlite.org/) uses SQLite itself, of > course, and as of this writing (2015) it handles about 400K to 500K > HTTP requests per day, about 15-20% of which are dynamic pages > touching the database. Each dynamic page does roughly 200 SQL > statements. This setup runs on a single VM that shares a physical > server with 23 others and yet still keeps the load average of below > 0.1 most of the time." > > ------ > > it would be interesting to put *all* sqlite.org pages in the database, > even if it is useless. This would test with 500K HTTP requests per > day. It will then be possible to modify this paragraph and indicate > that Sqlite smoothly manages the 500K HTTP requests per day of this > website, thus about 100 000K SQL statements per day. > > And why not test with writing on each visit, and even every page > visit? If Sqlite accept the charge, it would be impressive. it would > also demonstrate the interest of WAL mode. > > With the evolution of Sqlite and materials evolution (SSD, > microprocessors ...), it might be possible. > > Olivier > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
