James Mills <[EMAIL PROTECTED]> wrote: > Hi Folks, > > I'm wanting to use SQLite in an embedded web application > that will serve as a proxy and possible serve up many > connections at once. I'm talking here of high-traffic > through this web app. > > Question is, how will SQLite perform under these kinds > of conditions ? I've been speaking to a few of the Trac > developers, and they inform me that SQLite uses a global > writer meaning that only a single thread can write at > any one point in time. This would explain why trac-hacks.org > is so slow at times to load up. > > Thoughts/Comments ? > > (btw) I really don't want to be using a server-client > rdbms such as MySQL or Postgresql because of the small > overheads in having a server. >
No question about it - a client/server database will give you much better concurrency. The price of that concurrency is, of course, increased complexity and administrative overhead. There is a tradeoff here. You need to decide what is most important to you - easy of setup and operation or high concurrency. I do not know why the Trac people are having problems with SQLite. I have not looked at their code. But I find it hard to believe that a bug tracking website could exceed the concurrency capabilities of SQLite. SQLite should have plenty enough concurrency to support any bug database that human bug-fixers are able to keep up with. What do you mean by "high-traffic"? The SQLite website itself runs on a 200MHz slice of a virtual server and handles an average of 1 hit/second on weekdays. It is backed by a version 2 SQLite database and seems to work just fine. Requests often take multple seconds to fulfill, so at any given moment in time, there are multiple requests pending. The trick is, not every request uses the database. And requests that write to the database (Wiki pages updates, creating new tickets, etc.) are fewer still. So SQLite has no problem handling the load even on a rather slow virtual server slice. The SQLite website was written by me (of course) and I understand the concurrency issues in SQLite better than most. So I was careful to make sure that the website does not hold exclusive locks on the database for more than a fraction of a second. The fact that the Trac team has problems with SQLite suggests to me that they have not been nearly so careful. If you want the freedom to do long transactions without having to worry about locking out other clients, and you are not concerned about ease of installation and administration (and the Trac team clearly is not concerned about ease of administration from what I have seen) then you should definitely consider a client/server database instead of SQLite. But if you need a self-contained application that does not require any database administration and you are willing to take the extra care in coding your app that such a database requires, then SQLite could well be your best choice. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
