> On Fri, Aug 22, 2008 at 7:47 PM, Bruno Moreira Guedes > <[EMAIL PROTECTED]>wrote: > >> Hello, >> >> I have an application which uses SQLite. The program open a sqlite >> database, and have about five instances running at the same time. For >> each instance, it waits for user commands(where the 'user' is another >> application), and for each command it executes some queries(about 10). >> Currently, the user sends a little number of commands(I don't know the >> numbers exactaly, but about 3 or less) per second, and it runs very >> whell. But, it'll be used on a environment where the number of >> commands per time will increase at least 10x!!! The program's answer >> to command need to be very fast. >> >> So, do you think I need to care about performance?? Do you think >> SQLite should be the best choice(or even a 'good choice')?? >> I also need some idea about the best way to manage the high number of >> access to the application. What's better to do to improve >> performance?? Reducing the number of queries and increasing the number >> of program instances should help(e.g. creating some views to reduce >> the number of selects, reducing the number of sqlite3_exec calls)?? >> >> I haven't detailed yet, but sometimes(rarely) data writes should be >> done(update/delete/insert). But it's too short data, and it's less >> then 0.01% of the database access(it stores some access rules). >> >> When I researched about performance in SQLite, I found some >> information about the concurrency, saying that SQLite is not the best >> choice when I have concurrency. But I want to know if the concurrency >> being only about selects change this idea(as I think the database >> don't get locked when I do just SELECTs). >> >> Thank you all, >> Bruno M Guedes >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > > 2008/8/22 Tomas Gold <[EMAIL PROTECTED]>: > Bruno, > > I'm quite new to sqlite but I believe that concurrency may be an issue only > for data changes which require db locking. As long as you go with SELECTs, > there's not much to worry about. > > Tomas > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Tomas, Thank you by the answer. I'll try to improve it as possible, but I won't worry too much about this. As you said, it doesn't require db locking. And even with too many 'locking concurrency', I've done some stress testing and SQLite still very well. I've thrown the SQLITE_BUSY errors to a retry algorithm, which waits a random time in a time range and try again until a high number of retries. Using it, I've wrote a program which writes data forever on the database, and get the data again. So, I get to run 8 instances of this testing program and the database seems to answer very well. But even with this tests, something seems to be wrong for me, and I'm researching to ensure everything will be nice on the new environment. I'll improve the database layout for better performance too. Thank you again! --Bruno M Guedes _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
