Re: [fossil-users] fossil performance testing and is it possible to increase the sqlite3 timeout?
On Sep 3, 2011, at 10:11 AM, Remigiusz Modrzejewski wrote: So now, why wal is not the default? I'm having a trunk build from few days back and a freshly created repo is in delete mode… See disadvantages here: http://www.sqlite.org/draft/wal.html The biggest one is that it requires two additional files. -- Dmitry Chestnykh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil performance testing and is it possible to increase the sqlite3 timeout?
On Sep 3, 2011, at 5:15 PM, Dmitry Chestnykh wrote: So now, why wal is not the default? I'm having a trunk build from few days back and a freshly created repo is in delete mode… See disadvantages here: http://www.sqlite.org/draft/wal.html The biggest one is that it requires two additional files. Ok, but then I'd say it should be documented somewhere. For now the closest thing to documentation of this aspect (which is quite important, as seen in this thread) is mention of existence in the help of fossil rebuild. Not enough... Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil performance testing and is it possible to increase the sqlite3 timeout?
We are revisiting fossil for use in our team and I've been doing a little performance testing. One thing that we've seen is when two people access the central repo simultaneously sometimes sync can fail and you get the continue without sync: y/N question. This is benign enough and recovery is easy, just do a manual sync but it is one more thing you have to train users on. This is using the fossil serve and not the cgi server. Does anyone else run into this and are there any settings that could improve it? Will it go away with the cgi based serving? I haven't been able to get cgi to work in our environment yet but that is nothing to do with fossil. The test script simply creates and modifies some random files aproximately 2M in size and checks them in. I checked out the repository into two different directories with different .fossil files and run the scripts simultaneously. They sync, update, modify, commit and when necessary merge constantly. I'm getting about 60 syncs to the central database per minute after a day or two of running with 70k revisions in a 250Meg .fossil file. You can get my script(s) from here if interested: http://chiselapp.com/user/kiatoa/repository/testfossil I'd be very interested in hearing what kind of db access rate people see using cgi. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil performance testing and is it possible to increase the sqlite3 timeout?
On Fri, Sep 2, 2011 at 5:17 PM, Matt Welland estifo...@gmail.com wrote: We are revisiting fossil for use in our team and I've been doing a little performance testing. One thing that we've seen is when two people access the central repo simultaneously sometimes sync can fail and you get the continue without sync: y/N question. This is benign enough and recovery is easy, just do a manual sync but it is one more thing you have to train users on. This is using the fossil serve and not the cgi server. Does anyone else run into this and are there any settings that could improve it? Will it go away with the cgi based serving? I haven't been able to get cgi to work in our environment yet but that is nothing to do with fossil. You probably have your repository databases set to journal_mode=delete instead of journal_mode=wal. For example, see: http://chiselapp.com/user/kiatoa/repository/testfossil/stat Look on the last line toward the right and you see delete. That's the currently configured journal mode. If you look here: http://www.sqlite.org/src/stat You'll see the journal_mode set to WAL. WAL gives much better concurrency and greatly reduces the chance of sync collisions such as you describe above. To change to WAL mode either do: fossil rebuild --wal Or you can do: fossil sql Then enter PRAGMA journal_mode=WAL. The latter is very fast for even the largest repos. Note that fossil serve merely sets of a simple web-server that runs CGI for each inbound request. So it is no more or less efficient that running CGI off of Apache. The test script simply creates and modifies some random files aproximately 2M in size and checks them in. I checked out the repository into two different directories with different .fossil files and run the scripts simultaneously. They sync, update, modify, commit and when necessary merge constantly. I'm getting about 60 syncs to the central database per minute after a day or two of running with 70k revisions in a 250Meg .fossil file. You can get my script(s) from here if interested: http://chiselapp.com/user/kiatoa/repository/testfossil I'd be very interested in hearing what kind of db access rate people see using cgi. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
