> Le 28 déc. 2017 à 13:51, Richard Hipp <[email protected]> a écrit :
>
> On 12/28/17, Olivier Mascia <[email protected]> wrote:
>>
>> Is "fossil server" generally deemed sufficient for a small LAN (lab) of
>> let's say < 10 developers each with their own clone ?
>> Or should a proper HTTP server be used as front end to SCGI mode of fossil?
>
> The "fossil server" command *should* be sufficient for this. However,
> it doesn't get used that much. Most people run from a proper HTTP
> server of some kind. Consequently, it is possible for bugs to linger
> in "fossil server" without anybody noticing. One such performance
> bug, that had been in the code for over 10 years, was fixed just
> before Chrismas
> (https://www.fossil-scm.org/fossil/info/05ec15cad53e8176). That
> particular fix applies to unix systems only, but there might be
> similar problems on the windows side.
>
> As a test of last weeks' fix, I am currently running a clone of the
> Fossil self-hosting repository using the "fossil server" command in a
> datacenter near Paris on a machine that is approximately equal to a
> Raspberry Pi. The clone is internet-facing
> (http://www4.fossil-scm.org/) and so far seems to be holding up fine.
>
> I just took a peek at the code for "fossil server" on windows.
> (Unlike most other commands in fossil, the "fossil server" command
> requires a separate implementation in windows.) I am reminded that
> windows is not the ideal platform on which to host a web server and
> that compromises had to be made in the implementation. It *should*
> work. And it does work fine for things like "fossil ui". But if you
> start hitting it with any kind of load, I can see that it might easily
> bog down. Probably it will take someone with more windows-foo than me
> to fix that.
>
> So if you are having problems using "fossil server" on Windows, you
> might do well to set up a Raspberry PI (or the equivalent) in the
> corner of the room and run "fossil server" there instead, using the
> latest "trunk" version of Fossil that contains the Christmas-eve patch
> for the "fossil server" inefficiency.
Thanks a lot Richard for this insider view on the matter.
I'll not get down to Raspberry PI (which I really like by the way) but spawn a
common linux VM for the task and I'm confident, reading your comments, that it
will be just fine.
By the way, in between, the clone completed successfully. Here is the display
at end (project ids and password removed).
Round-trips: 250 Artifacts sent: 0 received: 102700
*** time skew *** server is slow by 106.6 seconds
Clone done, sent: 85932 received: 2249557802 ip: 10.32.1.6
Rebuilding repository meta-data...
100.0% complete...
Extra delta compression...
Vacuuming the database...
I'll have a close look in the next weeks at the source code of the Windows
server feature of Fossil. The warning "*** time skew *** will certainly be an
interesting starting point.
Hopefully I might be able to bring something in that area. Our own software is
actually much like Fossil: single process, multi-usages, with its own HTTPS
embedded server (using OpenSSL). (Albeit currently only available on Windows,
so we have good experience in that area of HTTP serving on Windows using custom
C/C++ code).
For information, my strange experience today was running this code (on both
server and cloner side):
This is fossil version 2.5 [f4a9df4dd0] 2017-12-23 04:21:41 UTC
Compiled on Dec 27 2017 16:08:53 using msc-19.11 (64-bit)
--
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
