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
