I also use web2py and sqlite in my low traffic website, serving for less than 10 people. In most cases it works great. But when a user wants to open a statistics page which generated by a query of thousands of records (and then rendered as 7 flash charts), there is a 5%~10% chance that the browser keeps "loading" but no content shows up, yet at the same time the server has NO load. A refresh in the browser usually bypass the problem. I am not sure the problem is caused by the concurrency limit of sqlite db, or the concurrency limit of web2py's CherryPyWSGIServer (if any).
Thank Beerc for sharing the post (http://stackoverflow.com/questions/ 54998/how-scalable-is-sqlite). It is very informative, especially its first (highest ranked) answer. So I think sqlite should be capable for a site for 10 people, but might need some tweak. Further more, at the end of this post (http://www.sqlite.org/ whentouse.html), it mentions sqlite uses reader/writer lock. So here comes my first question, perhaps mainly for Massimo: When a user click on our web2py app which contains a db=SQLDB("sqlite://mydb.sqlite"), does that mean we already open the db, create a transaction, therefore the whole sqlite db is locked by writer lock, until the current user request is finished? If so, that means even two crud.read() request can not be served at the same time. By the way, this post (http://www.sqlite.org/threadsafe.html) mentions three thread modes of sqlite. Do you know which mode is python 's built-in sqlite uses? Is it the "default Serialized mode"? If so, that means even two crud.read() request can not be served at the same time. Thanks in advance for any feedback. Sincerely, Iceberg On Apr2, 7:50pm, Beerc <berces.las...@fomi.hu> wrote: > See http://stackoverflow.com/questions/54998/how-scalable-is-sqlite > > [...] there is nothing that prevents using an Sqlite database in a > multi-user environment, but every transaction (in effect, every SQL > statement that modifies the database) takes a lock on the file, which > will prevent other users from accessing the database at all. > > So if you have lots of modifications done to the database, you're > essentially going to hit scaling problems very quick. If, on the other > hand, you have lots of read access compared to write access, it might > not be so bad. > > On Apr 2, 12:00 pm, Sven <svenstrin...@gmail.com> wrote: > > > > > Hi, > > > I programmed a psychological experiment in flash and store answers/ > > results in a sqlite database using web2py (behind nginx server + > > fastcgi) and pyamf. Everything seems to be all right when I test it, > > but with as few as 2 simultaneous users I (sometimes) run into > > trouble. A try with seven simultaneous users resulted in only 2 > > succesfully stored experimental data.sets > > I find it very hard to debug, since there are no tickets in web2py. > > Flash does sometimes produce a remoting error in that situation, but > > without too much information. > > > I seems to me there is some kind of concurrency problem, but I assumed > > web2py/sqlite would take care of that for me. Or should I explicitly > > deal with this? Explicitly commit, check if inserts and updates were > > successful and if not try again? > > > Any suggestions, comments ideas would be really appreciated. > > > Thanks. > > > Sven -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
