You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2012/11/12 19:27:22 UTC
RE: [Issue 3980] serf increases server load
> -----Original Message-----
> From: philip@tigris.org [mailto:philip@tigris.org]
> Sent: maandag 12 november 2012 18:59
> To: issues@subversion.tigris.org
> Subject: [Issue 3980] serf increases server load
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3980
>
>
>
>
>
>
> ------- Additional comments from philip@tigris.org Mon Nov 12 09:59:19
-0800
> 2012 -------
> Using serf 1.1.x@1691 and subversion trunk@1408335 as 1.8.
> Using 1.7.7 with neon as 1.7.
> Using subversion trunk as my dataset.
>
> The server CPU and bandwidth to service one checkout:
>
> 1.7 neon client, 1.7 server
> 3.6s, 21.4MB
>
> 1.8 serf client, 1.7 server
> 2.9s, 46.9MB
>
> 1.7 neon client, 1.7 server, mod_deflate
> 5.3s, 15.4MB
>
> 1.8 serf client, 1.7 server, mod_deflate
> 5.7s, 15.9MB
>
> 1.7 neon client, 1.8 server
> 3.3s, 21.4MB
>
> 1.8 serf client, 1.8 server
> 1.6s, 44.7MB
>
> 1.7 neon client, 1.8 server, mod_deflate
> 4.8s, 15.4MB
>
> 1.8 serf client, 1.8 server, mod_deflate
> 4.1s. 14.7MB
>
> Serf greatly increases bandwidth unless mod_deflate is in use (see
> http://svn.haxx.se/dev/archive-2012-05/0343.shtml for why). Using
> mod_deflate
> solves the bandwidth problem to some extent although CPU use is
> increased.
Any idea why a 1.8 client would use more than twice the amount of data of
1.7?
It should send out less requests than a 1.7 client; especially to a 1.8
server where we avoid property requests.
Note that lgo reported mod_deflate to work against you when using ssl.
Bert
Re: [Issue 3980] serf increases server load
Posted by Branko Čibej <br...@wandisco.com>.
On 15.11.2012 15:49, C. Michael Pilato wrote:
> On 11/15/2012 08:08 AM, Branko Čibej wrote:
>> You may have a point there. The next question is, why would anyone want
>> to base64-encode a response to a simple GET? Seems like unnecessary work
>> for no good reason.
> I'm pretty sure we don't base64 our GET responses.
I can't find a codepath that would do that, indeed. Ad-hoc tests seem to
imply we don't. The difference in default compression levels between
svndiff and mod_deflate could likely be enough to account for the
difference in CPU usage.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [Issue 3980] serf increases server load
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Nov 15, 2012 at 3:49 PM, C. Michael Pilato <cm...@collab.net>wrote:
> On 11/15/2012 08:08 AM, Branko Čibej wrote:
> > You may have a point there. The next question is, why would anyone want
> > to base64-encode a response to a simple GET? Seems like unnecessary work
> > for no good reason.
>
> I'm pretty sure we don't base64 our GET responses.
>
Well, it's just been a shot in the dark ;)
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: [Issue 3980] serf increases server load
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/15/2012 08:08 AM, Branko Čibej wrote:
> You may have a point there. The next question is, why would anyone want
> to base64-encode a response to a simple GET? Seems like unnecessary work
> for no good reason.
I'm pretty sure we don't base64 our GET responses.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: [Issue 3980] serf increases server load
Posted by Branko Čibej <br...@wandisco.com>.
On 15.11.2012 13:38, Stefan Fuhrmann wrote:
> On Thu, Nov 15, 2012 at 12:36 PM, Branko Čibej <br...@wandisco.com> wrote:
>
>> On 12.11.2012 19:46, Ivan Zhakov wrote:
>>> On Mon, Nov 12, 2012 at 10:27 PM, Bert Huijben <be...@qqmail.nl> wrote:
>>>> Any idea why a 1.8 client would use more than twice the amount of
>>>> data of 1.7? It should send out less requests than a 1.7 client;
>>>> especially to a 1.8 server where we avoid property requests.
>>> svn 1.8 uses raw GET for fetching files, so it downloads uncompressed
>>> unless you have mod_deflate enabled. While neon uses svndiff format
>>> for transmitting files content which self-compressed.
>> I don't buy that argument. Generating svndiff takes CPU, too. What's
>> more, the simplest kind of svndiff is just a "new" op and
>> zlib-compressed data, effectively having the same characteristics as
>> mod_deflate.
>>
>> Why would mod_deflate use more CPU cycles per compression ratio than
>> svndiff1? Unless you're testing with mod_deflate compression level set
>> to 9, which would be silly for this kind of stream compression.
>>
> My guess / speculation without looking at the code:
>
> Neon: (txdelta against empty; almost nop) -> zip -> base64 -> send
> Serf + deflate: base64 -> zip -> send
>
> So, in neon's case, base64 is applied to less data
> then in the serf case. Since base64 inflates the
> data buffer by 1/3, serf also needs to zip more
> data then neon. The total CPU overhead would be
> somewhere between 30 and 40%.
You may have a point there. The next question is, why would anyone want
to base64-encode a response to a simple GET? Seems like unnecessary work
for no good reason.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [Issue 3980] serf increases server load
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Thu, Nov 15, 2012 at 12:36 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 12.11.2012 19:46, Ivan Zhakov wrote:
> > On Mon, Nov 12, 2012 at 10:27 PM, Bert Huijben <be...@qqmail.nl> wrote:
> >> Any idea why a 1.8 client would use more than twice the amount of
> >> data of 1.7? It should send out less requests than a 1.7 client;
> >> especially to a 1.8 server where we avoid property requests.
> > svn 1.8 uses raw GET for fetching files, so it downloads uncompressed
> > unless you have mod_deflate enabled. While neon uses svndiff format
> > for transmitting files content which self-compressed.
>
> I don't buy that argument. Generating svndiff takes CPU, too. What's
> more, the simplest kind of svndiff is just a "new" op and
> zlib-compressed data, effectively having the same characteristics as
> mod_deflate.
>
> Why would mod_deflate use more CPU cycles per compression ratio than
> svndiff1? Unless you're testing with mod_deflate compression level set
> to 9, which would be silly for this kind of stream compression.
>
My guess / speculation without looking at the code:
Neon: (txdelta against empty; almost nop) -> zip -> base64 -> send
Serf + deflate: base64 -> zip -> send
So, in neon's case, base64 is applied to less data
then in the serf case. Since base64 inflates the
data buffer by 1/3, serf also needs to zip more
data then neon. The total CPU overhead would be
somewhere between 30 and 40%.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: [Issue 3980] serf increases server load
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/15/2012 10:09 AM, Mark Phippard wrote:
> When I do a GET using a web browser or wget, the logged request is for
> something like:
>
> /svn/repos/trunk/foo.txt
>
> But when I do a checkout using Serf, the logged request is for something like:
>
> /svn/repos/!svn/ver/2/trunk/foo.txt
>
> Could we give admins the ability to not log the requests for !svn ?
We can do this today by recommending the following httpd.conf configuration:
SetEnvIf Request_URI "^" in_repos=0
SetEnvIf Request_URI "/!svn/" in_repos=1
SetEnvIf Request_Method "GET" dontlog
SetEnvIf in_repos 0 !dontlog
CustomLog logs/access_log withagent env=!dontlog
Note that we can also squeeze in other requests they might wish to not see
logged, too:
SetEnvIf Request_Method "PROPFIND" dontlog
> We would probably also want the Subversion operational logs to not
> include the get-file log entry for these files as well.
Yup.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: [Issue 3980] serf increases server load
Posted by Branko Čibej <br...@wandisco.com>.
On 15.11.2012 16:09, Mark Phippard wrote:
> On Thu, Nov 15, 2012 at 10:00 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> On 11/15/2012 08:49 AM, Joe Schaefer wrote:
>>> Sure it can be done via config directives:
>>> just set an env var whenever some request
>>> is inconsequential and server admins can
>>> configure their logging to ignore that request.
>>> We already do that for svn operation logging.
>> I've been considering the same sorts of approaches recently (as a result of
>> this thread). But one thing has me bothered: from the server's point of
>> view, there's no meaningful difference between "a GET that's part of a
>> checkout/update" and "a GET that's part of some other non-update-y operation".
>>
>> Does that mean that we give the client the power to mark particular GET
>> requests as "below radar"? That doesn't seem very ... audit-friendly.
>> (Granted, no one is forcing the server admin to ignore said GET requests.)
>>
>> If we don't feel comfortable giving the client this power, then I think our
>> only option is to advise admins to ignore all GET requests aimed at
>> Subversion repositories (which has the bonus feature of not requiring any
>> work on our part).
> When I do a GET using a web browser or wget, the logged request is for
> something like:
>
> /svn/repos/trunk/foo.txt
>
> But when I do a checkout using Serf, the logged request is for something like:
>
> /svn/repos/!svn/ver/2/trunk/foo.txt
>
> Could we give admins the ability to not log the requests for !svn ?
>
> We would probably also want the Subversion operational logs to not
> include the get-file log entry for these files as well.
Given that versioned resource URLs are predictable in HTTPv2, this
wouldn't really plug any holes if we're concerned about attackers
sneaking in DoS without them showing up in the server logs. And I think
we issue such requests for 'svn cat' as well.
Still, I can't think of any reason why administrators couldn't rotate
logs of specifically that kind of GET of versioned resources more often
than other access logs.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [Issue 3980] serf increases server load
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 15, 2012 at 10:00 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 11/15/2012 08:49 AM, Joe Schaefer wrote:
>> Sure it can be done via config directives:
>> just set an env var whenever some request
>> is inconsequential and server admins can
>> configure their logging to ignore that request.
>> We already do that for svn operation logging.
>
> I've been considering the same sorts of approaches recently (as a result of
> this thread). But one thing has me bothered: from the server's point of
> view, there's no meaningful difference between "a GET that's part of a
> checkout/update" and "a GET that's part of some other non-update-y operation".
>
> Does that mean that we give the client the power to mark particular GET
> requests as "below radar"? That doesn't seem very ... audit-friendly.
> (Granted, no one is forcing the server admin to ignore said GET requests.)
>
> If we don't feel comfortable giving the client this power, then I think our
> only option is to advise admins to ignore all GET requests aimed at
> Subversion repositories (which has the bonus feature of not requiring any
> work on our part).
When I do a GET using a web browser or wget, the logged request is for
something like:
/svn/repos/trunk/foo.txt
But when I do a checkout using Serf, the logged request is for something like:
/svn/repos/!svn/ver/2/trunk/foo.txt
Could we give admins the ability to not log the requests for !svn ?
We would probably also want the Subversion operational logs to not
include the get-file log entry for these files as well.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [Issue 3980] serf increases server load
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/15/2012 08:49 AM, Joe Schaefer wrote:
> Sure it can be done via config directives:
> just set an env var whenever some request
> is inconsequential and server admins can
> configure their logging to ignore that request.
> We already do that for svn operation logging.
I've been considering the same sorts of approaches recently (as a result of
this thread). But one thing has me bothered: from the server's point of
view, there's no meaningful difference between "a GET that's part of a
checkout/update" and "a GET that's part of some other non-update-y operation".
Does that mean that we give the client the power to mark particular GET
requests as "below radar"? That doesn't seem very ... audit-friendly.
(Granted, no one is forcing the server admin to ignore said GET requests.)
If we don't feel comfortable giving the client this power, then I think our
only option is to advise admins to ignore all GET requests aimed at
Subversion repositories (which has the bonus feature of not requiring any
work on our part).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: [Issue 3980] serf increases server load
Posted by Joe Schaefer <jo...@yahoo.com>.
Sure it can be done via config directives:
just set an env var whenever some request
is inconsequential and server admins can
configure their logging to ignore that request.
We already do that for svn operation logging.
>________________________________
> From: Mark Phippard <ma...@gmail.com>
>To: Branko Čibej <br...@wandisco.com>
>Cc: dev@subversion.apache.org
>Sent: Thursday, November 15, 2012 8:38 AM
>Subject: Re: [Issue 3980] serf increases server load
>
>On Thu, Nov 15, 2012 at 8:29 AM, Branko Čibej <br...@wandisco.com> wrote:
>
>> Question: Can we somehow mark those GETs as "less interesting" so that
>> they can be filtered out of a normal access.log for higher-granularity
>> debugging?
>
>I do not believe it can be done via configuration directives.
>However, it seems that just as log entries can be piped to a program
>like rotatelogs, they could also be piped to a program that did this
>kind of suppression. Maybe any HTTP 2xx log entries for a path with
>"!svn" could simply be suppressed by such a program?
>
>Something like this?
>
>http://serverfault.com/questions/285396/how-to-use-apache-piped-logs-to-regex-replace-out-unwanted-data-in-logs-in-real
>
>--
>Thanks
>
>Mark Phippard
>http://markphip.blogspot.com/
>
>
>
Re: [Issue 3980] serf increases server load
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 15, 2012 at 8:29 AM, Branko Čibej <br...@wandisco.com> wrote:
> Question: Can we somehow mark those GETs as "less interesting" so that
> they can be filtered out of a normal access.log for higher-granularity
> debugging?
I do not believe it can be done via configuration directives.
However, it seems that just as log entries can be piped to a program
like rotatelogs, they could also be piped to a program that did this
kind of suppression. Maybe any HTTP 2xx log entries for a path with
"!svn" could simply be suppressed by such a program?
Something like this?
http://serverfault.com/questions/285396/how-to-use-apache-piped-logs-to-regex-replace-out-unwanted-data-in-logs-in-real
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [Issue 3980] serf increases server load
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 15, 2012 at 8:29 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 15.11.2012 14:20, Mark Phippard wrote:
>> I thought the latest results show that Serf uses less server CPU? So
>> why are we still discussing this aspect? I guess we can stil make
>> Serf better here, but it is already better than Neon if this is the
>> measuring stick.
>>
>> If mod_deflate is not used, then Serf uses considerably less CPU than
>> Neon but sends significantly more data. If mod_deflate is used, it
>> uses slightly more CPU than Neon does (without mod_deflate) and sends
>> significantly less data.
>
> This is what I'd expect given HTTPv2 design.
I am trying to figure out if we are still discussing this issue or
not. It seems like the issue of CPU load on the server is RESOLVED.
Is anyone still questioning that?
I think there are still other issues that we are legitimately
discussing, such as what to recommend around compression, and these
other issues with the log and connections. But can't this issue about
server load simply be closed? I find it confusing that some of these
issues are still being discussed because it is not clear if anyone is
still debating those points.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [Issue 3980] serf increases server load
Posted by Branko Čibej <br...@wandisco.com>.
On 15.11.2012 14:20, Mark Phippard wrote:
> I thought the latest results show that Serf uses less server CPU? So
> why are we still discussing this aspect? I guess we can stil make
> Serf better here, but it is already better than Neon if this is the
> measuring stick.
>
> If mod_deflate is not used, then Serf uses considerably less CPU than
> Neon but sends significantly more data. If mod_deflate is used, it
> uses slightly more CPU than Neon does (without mod_deflate) and sends
> significantly less data.
This is what I'd expect given HTTPv2 design.
> My main concerns are areas where it may catch server admins unprepared:
>
> * Explosion in HTTP requests == explosion in log file sizes. Even
> with good log rotation, companies that need to retain their logs will
> require a lot more disk storage than they have in the past.
Question: Can we somehow mark those GETs as "less interesting" so that
they can be filtered out of a normal access.log for higher-granularity
debugging?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [Issue 3980] serf increases server load
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 15, 2012 at 6:36 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 12.11.2012 19:46, Ivan Zhakov wrote:
>> On Mon, Nov 12, 2012 at 10:27 PM, Bert Huijben <be...@qqmail.nl> wrote:
>>> Any idea why a 1.8 client would use more than twice the amount of
>>> data of 1.7? It should send out less requests than a 1.7 client;
>>> especially to a 1.8 server where we avoid property requests.
>> svn 1.8 uses raw GET for fetching files, so it downloads uncompressed
>> unless you have mod_deflate enabled. While neon uses svndiff format
>> for transmitting files content which self-compressed.
>
> I don't buy that argument. Generating svndiff takes CPU, too. What's
> more, the simplest kind of svndiff is just a "new" op and
> zlib-compressed data, effectively having the same characteristics as
> mod_deflate.
>
> Why would mod_deflate use more CPU cycles per compression ratio than
> svndiff1? Unless you're testing with mod_deflate compression level set
> to 9, which would be silly for this kind of stream compression.
See this reply from Justin earlier this year:
http://svn.haxx.se/dev/archive-2012-05/0343.shtml
"Also, keep in mind that svn and mod_deflate have different default
zlib compression level defaults (5 vs 6). Part of any skew could be
that SVN defaults to 5 and mod_deflate defaults to 6...so, it may not
be quite symmetric."
I thought the latest results show that Serf uses less server CPU? So
why are we still discussing this aspect? I guess we can stil make
Serf better here, but it is already better than Neon if this is the
measuring stick.
If mod_deflate is not used, then Serf uses considerably less CPU than
Neon but sends significantly more data. If mod_deflate is used, it
uses slightly more CPU than Neon does (without mod_deflate) and sends
significantly less data.
My main concerns are areas where it may catch server admins unprepared:
* Explosion in HTTP requests == explosion in log file sizes. Even
with good log rotation, companies that need to retain their logs will
require a lot more disk storage than they have in the past.
* Increase in HTTP requests/connections could stress authentication
systems that do not implement some kind of connection-level caching.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: [Issue 3980] serf increases server load
Posted by Branko Čibej <br...@wandisco.com>.
On 12.11.2012 19:46, Ivan Zhakov wrote:
> On Mon, Nov 12, 2012 at 10:27 PM, Bert Huijben <be...@qqmail.nl> wrote:
>> Any idea why a 1.8 client would use more than twice the amount of
>> data of 1.7? It should send out less requests than a 1.7 client;
>> especially to a 1.8 server where we avoid property requests.
> svn 1.8 uses raw GET for fetching files, so it downloads uncompressed
> unless you have mod_deflate enabled. While neon uses svndiff format
> for transmitting files content which self-compressed.
I don't buy that argument. Generating svndiff takes CPU, too. What's
more, the simplest kind of svndiff is just a "new" op and
zlib-compressed data, effectively having the same characteristics as
mod_deflate.
Why would mod_deflate use more CPU cycles per compression ratio than
svndiff1? Unless you're testing with mod_deflate compression level set
to 9, which would be silly for this kind of stream compression.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [Issue 3980] serf increases server load
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Mon, Nov 12, 2012 at 10:27 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: philip@tigris.org [mailto:philip@tigris.org]
>> Sent: maandag 12 november 2012 18:59
>> To: issues@subversion.tigris.org
>> Subject: [Issue 3980] serf increases server load
>>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3980
>>
>>
>>
>>
>>
>>
>> ------- Additional comments from philip@tigris.org Mon Nov 12 09:59:19
> -0800
>> 2012 -------
>> Using serf 1.1.x@1691 and subversion trunk@1408335 as 1.8.
>> Using 1.7.7 with neon as 1.7.
>> Using subversion trunk as my dataset.
>>
>> The server CPU and bandwidth to service one checkout:
>>
>> 1.7 neon client, 1.7 server
>> 3.6s, 21.4MB
>>
>> 1.8 serf client, 1.7 server
>> 2.9s, 46.9MB
>>
>> 1.7 neon client, 1.7 server, mod_deflate
>> 5.3s, 15.4MB
>>
>> 1.8 serf client, 1.7 server, mod_deflate
>> 5.7s, 15.9MB
>>
>> 1.7 neon client, 1.8 server
>> 3.3s, 21.4MB
>>
>> 1.8 serf client, 1.8 server
>> 1.6s, 44.7MB
>>
>> 1.7 neon client, 1.8 server, mod_deflate
>> 4.8s, 15.4MB
>>
>> 1.8 serf client, 1.8 server, mod_deflate
>> 4.1s. 14.7MB
>>
>> Serf greatly increases bandwidth unless mod_deflate is in use (see
>> http://svn.haxx.se/dev/archive-2012-05/0343.shtml for why). Using
>> mod_deflate
>> solves the bandwidth problem to some extent although CPU use is
>> increased.
>
> Any idea why a 1.8 client would use more than twice the amount of data of
> 1.7?
>
> It should send out less requests than a 1.7 client; especially to a 1.8
> server where we avoid property requests.
>
svn 1.8 uses raw GET for fetching files, so it downloads uncompressed
unless you have mod_deflate enabled. While neon uses svndiff format
for transmitting files content which self-compressed.
--
Ivan Zhakov
Re: [Issue 3980] serf increases server load
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, Nov 12, 2012 at 9:37 PM, Philip Martin
<ph...@wandisco.com>wrote:
> Stefan Fuhrmann <st...@wandisco.com> writes:
>
> >> > Using serf 1.1.x@1691 and subversion trunk@1408335 as 1.8.
> >> > Using 1.7.7 with neon as 1.7.
> >> > Using subversion trunk as my dataset.
> >> >
> >> > The server CPU and bandwidth to service one checkout:
> >> >
> >> > 1.7 neon client, 1.7 server
> >> > 3.6s, 21.4MB
> >> >
> >> > 1.8 serf client, 1.7 server
> >> > 2.9s, 46.9MB
> >> >
> >> > 1.7 neon client, 1.7 server, mod_deflate
> >> > 5.3s, 15.4MB
> >> >
> >> > 1.8 serf client, 1.7 server, mod_deflate
> >> > 5.7s, 15.9MB
> >> >
> >> > 1.7 neon client, 1.8 server
> >> > 3.3s, 21.4MB
> >> >
> >> > 1.8 serf client, 1.8 server
> >> > 1.6s, 44.7MB
> >> >
> >> > 1.7 neon client, 1.8 server, mod_deflate
> >> > 4.8s, 15.4MB
> >> >
> >> > 1.8 serf client, 1.8 server, mod_deflate
> >> > 4.1s. 14.7MB
> >>
> >
> > How long does it take to do e.g. 4 c/o in parallel
> > to some ramdisk with hot server caches? That
> > would give some indication on the server CPU usage.
>
> Those figures are the amount of CPU used by the server. In each case I
> did 10 consecutive checkouts without restarting, so 1 cold-cache and 9
> hot-cache.
Ah, I see. I had the original posting interpreted
as 'time svn co'.
> How would running checkouts in parallel add more
> information?
>
In case that the server load can't be measured,
a parallel checkout (or export) could saturate the
machine and it would address the actual server
load concern: peak load. As long as there is only
one client, the server load can be as high as it
wants to be. But no extra measurement is needed
right now.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*
Re: [Issue 3980] serf increases server load
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Fuhrmann <st...@wandisco.com> writes:
>> > Using serf 1.1.x@1691 and subversion trunk@1408335 as 1.8.
>> > Using 1.7.7 with neon as 1.7.
>> > Using subversion trunk as my dataset.
>> >
>> > The server CPU and bandwidth to service one checkout:
>> >
>> > 1.7 neon client, 1.7 server
>> > 3.6s, 21.4MB
>> >
>> > 1.8 serf client, 1.7 server
>> > 2.9s, 46.9MB
>> >
>> > 1.7 neon client, 1.7 server, mod_deflate
>> > 5.3s, 15.4MB
>> >
>> > 1.8 serf client, 1.7 server, mod_deflate
>> > 5.7s, 15.9MB
>> >
>> > 1.7 neon client, 1.8 server
>> > 3.3s, 21.4MB
>> >
>> > 1.8 serf client, 1.8 server
>> > 1.6s, 44.7MB
>> >
>> > 1.7 neon client, 1.8 server, mod_deflate
>> > 4.8s, 15.4MB
>> >
>> > 1.8 serf client, 1.8 server, mod_deflate
>> > 4.1s. 14.7MB
>>
>
> How long does it take to do e.g. 4 c/o in parallel
> to some ramdisk with hot server caches? That
> would give some indication on the server CPU usage.
Those figures are the amount of CPU used by the server. In each case I
did 10 consecutive checkouts without restarting, so 1 cold-cache and 9
hot-cache. How would running checkouts in parallel add more
information?
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [Issue 3980] serf increases server load
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Mon, Nov 12, 2012 at 7:27 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: philip@tigris.org [mailto:philip@tigris.org]
> > Sent: maandag 12 november 2012 18:59
> > To: issues@subversion.tigris.org
> > Subject: [Issue 3980] serf increases server load
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3980
> >
> >
> > ------- Additional comments from philip@tigris.org Mon Nov 12 09:59:19
> -0800
> > 2012 -------
> > Using serf 1.1.x@1691 and subversion trunk@1408335 as 1.8.
> > Using 1.7.7 with neon as 1.7.
> > Using subversion trunk as my dataset.
> >
> > The server CPU and bandwidth to service one checkout:
> >
> > 1.7 neon client, 1.7 server
> > 3.6s, 21.4MB
> >
> > 1.8 serf client, 1.7 server
> > 2.9s, 46.9MB
> >
> > 1.7 neon client, 1.7 server, mod_deflate
> > 5.3s, 15.4MB
> >
> > 1.8 serf client, 1.7 server, mod_deflate
> > 5.7s, 15.9MB
> >
> > 1.7 neon client, 1.8 server
> > 3.3s, 21.4MB
> >
> > 1.8 serf client, 1.8 server
> > 1.6s, 44.7MB
> >
> > 1.7 neon client, 1.8 server, mod_deflate
> > 4.8s, 15.4MB
> >
> > 1.8 serf client, 1.8 server, mod_deflate
> > 4.1s. 14.7MB
>
How long does it take to do e.g. 4 c/o in parallel
to some ramdisk with hot server caches? That
would give some indication on the server CPU usage.
-- Stefan^2.
--
Certified & Supported Apache Subversion Downloads:
*
http://www.wandisco.com/subversion/download
*