> "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
>> > "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
>>
BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
>> >> >> gzip on this computer, on one CPU, reach about 18 Mbyte/s
In response to "Anders Boström" <[EMAIL PROTECTED]>:
> > "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
>
> BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
> >> >> gzip on this computer, on one CPU, reach about 18 Mbyte/s. bacula with
> >> >> gzip only reach ~7.7 Mbyte/s. This lea
> "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
>> >> gzip on this computer, on one CPU, reach about 18 Mbyte/s. bacula with
>> >> gzip only reach ~7.7 Mbyte/s. This leads me to believe that there are
>> >> room for improvement.
>>
In response to "Anders Boström" <[EMAIL PROTECTED]>:
> >> gzip on this computer, on one CPU, reach about 18 Mbyte/s. bacula with
> >> gzip only reach ~7.7 Mbyte/s. This leads me to believe that there are
> >> room for improvement.
>
> BM> Again, the story changes. Above, you indicate that ta
> "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
>> > "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
>>
BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
>> >> I did some new performance-tests:
>> >>
>> >> All operati
Hi,
On 10/12/2006 3:43 PM, Anders Boström wrote:
>>"AL" == Arno Lehmann <[EMAIL PROTECTED]> writes:
>
>
> AL> Still the network is being used and that always involves latencies,
> AL> syncronization times, etc.
> >>
> >> Yes, and that might be the problem. But if it is about latencies
In response to "Anders Boström" <[EMAIL PROTECTED]>:
> > "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
>
> BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
> >> I did some new performance-tests:
> >>
> >> All operations are against a directory-tree with 7,255,659,224 bytes
> >>
> "BM" == Bill Moran <[EMAIL PROTECTED]> writes:
BM> In response to "Anders Boström" <[EMAIL PROTECTED]>:
>> I did some new performance-tests:
>>
>> All operations are against a directory-tree with 7,255,659,224 bytes
>> data in 98,025 files.
>>
>> | test1 | test2 | test3 |
>> --
In response to "Anders Boström" <[EMAIL PROTECTED]>:
> I did some new performance-tests:
>
> All operations are against a directory-tree with 7,255,659,224 bytes
> data in 98,025 files.
>
> | test1 | test2 | test3 |
> +---+--
In response to "Anders Boström" <[EMAIL PROTECTED]>:
> > "AL" == Arno Lehmann <[EMAIL PROTECTED]> writes:
>
> AL> Still the network is being used and that always involves latencies,
> AL> syncronization times, etc.
> >>
> >> Yes, and that might be the problem. But if it is about latenci
> "AL" == Arno Lehmann <[EMAIL PROTECTED]> writes:
AL> Still the network is being used and that always involves latencies,
AL> syncronization times, etc.
>>
>> Yes, and that might be the problem. But if it is about latencies
>> and/or synchronization, then it is a bacula performance pro
Hi again!
I did some new performance-tests:
All operations are against a directory-tree with 7,255,659,224 bytes
data in 98,025 files.
| test1 | test2 | test3 |
+---+---+---+
bacula-fd, no compression, md5: | 10:25 | 10:
On Tue, 10 Oct 2006, Ryan Novosielski wrote:
> That's not the behavior I've seen however. THAT I understand, and if I'm
> not mistaken, it is per spec. However, what I've seen is many cases
> where I said to our telecomm staff "please leave that port at
> autonegotiate" and then hooked up equipmen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Moran wrote:
> In response to Ryan Novosielski <[EMAIL PROTECTED]>:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>> Though there are probably 10-20 performance pitfalls, the two big problems
>>> of
>>> performance that I have seen
In response to Ryan Novosielski <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> > Though there are probably 10-20 performance pitfalls, the two big problems
> > of
> > performance that I have seen are:
> >
> > - Poorly tuned Catalog database -- insertion of Bacula at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Though there are probably 10-20 performance pitfalls, the two big problems of
> performance that I have seen are:
>
> - Poorly tuned Catalog database -- insertion of Bacula attributes in the
> database tends to be slow. There are probably 5 or te
Hello,
On 10/10/2006 11:30 AM, Anders Boström wrote:
>>"AL" == Arno Lehmann <[EMAIL PROTECTED]> writes:
>
>
> Hi!
>
> AL> On 10/10/2006 9:59 AM, Anders Boström wrote:
> >>> "KS" == Kern Sibbald writes:
> >>
> >>
> KS> From the statistics you show, the backup does not appear slow
> "AL" == Arno Lehmann <[EMAIL PROTECTED]> writes:
Hi!
AL> On 10/10/2006 9:59 AM, Anders Boström wrote:
>>> "KS" == Kern Sibbald writes:
>>
>>
KS> From the statistics you show, the backup does not appear slow to
KS> me. The reason you might think it is slow is because you are
KS
On Tuesday 10 October 2006 09:59, Anders Boström wrote:
> > "KS" == Kern Sibbald writes:
>
> KS> From the statistics you show, the backup does not appear slow to
> KS> me. The reason you might think it is slow is because you are
> KS> comparing apples and oranges.
>
> KS> On the one hand,
Hi,
On 10/10/2006 9:59 AM, Anders Boström wrote:
>>"KS" == Kern Sibbald writes:
>
>
> KS> From the statistics you show, the backup does not appear slow to
> KS> me. The reason you might think it is slow is because you are
> KS> comparing apples and oranges.
>
> KS> On the one hand, you
> "KS" == Kern Sibbald writes:
KS> From the statistics you show, the backup does not appear slow to
KS> me. The reason you might think it is slow is because you are
KS> comparing apples and oranges.
KS> On the one hand, you measure the time to to a non-compressed tar
KS> on a local machin
>From the statistics you show, the backup does not appear slow to me. The
reason you might think it is slow is because you are comparing apples and
oranges.
On the one hand, you measure the time to to a non-compressed tar on a local
machine sending the output down an extremely hi-speed bit b
22 matches
Mail list logo
