On Wed, Mar 12, 2008, Adrian Chadd wrote:
> I'm able to push this to about 5000 req/sec, 8000 concurrent client
> connections
> (so 16,000 concurrent TCP connections on the proxy) @ ~ 335mbit full-duplex
> on my
> test setup. I'm not maxing out anything yet as my thttpd opteron server is
> runn
Bundle Buggy has detected this merge request.
For details, see:
http://squid-cache.org/bundlebuggy//request/%3C1205705885.12036.4.camel%40HenrikLaptop%3E
Robert, can you fix the bundlebuggy bug links to point to our bugzilla
instead of launchpad?
/bugs/show_bug.cgi?id=
>From what it looks this is set in bundlebuggy/templates/master.kid where
it's currently "hardcoded" to use the launchpad bug tracker.
Regards
Henrik
Henrik Nordstrom has voted approve.
Status is now: Semi-approved
Comment:
For details, see:
http://squid-cache.org/bundlebuggy//request/%3C20080314234236.GA3185%40motherbox.xtech.com.ar%3E
Henrik Nordstrom has voted approve.
Status is now: Semi-approved
For details, see:
http://squid-cache.org/bundlebuggy//request/%3C20080309114825.BBA36E9FF1%40treenet.co.nz%3E
Henrik Nordstrom has voted abstain.
Status is now: Semi-approved
Comment:
Not familiar with the fine details about templates to say if this is
good or bad.. but if it doesn't break other platforms I am fine with it.
For details, see:
http://squid-cache.org/bundlebuggy//request/%3C2008031201152
On Sun, 2008-03-16 at 23:30 +0100, Henrik Nordstrom wrote:
> Robert, can you fix the bundlebuggy bug links to point to our bugzilla
> instead of launchpad?
>
> /bugs/show_bug.cgi?id=
>
> >From what it looks this is set in bundlebuggy/templates/master.kid where
> it's currently "hardcoded" to use
bb:approve
signature.asc
Description: This is a digitally signed message part
bb:approve
signature.asc
Description: This is a digitally signed message part
On Sun, 2008-03-16 at 23:21 +0900, Adrian Chadd wrote:
> On Wed, Mar 12, 2008, Adrian Chadd wrote:
>
> > I'm able to push this to about 5000 req/sec, 8000 concurrent client
> > connections
> > (so 16,000 concurrent TCP connections on the proxy) @ ~ 335mbit
> > full-duplex on my
> > test setup.
I would like to upgrade the bzr version on squid-cache.org tomorrow.
This does not require client upgrades. Those of you with current clients
will be seeing 'Server is too old for fast get_parent_map, reconnecting.
(Upgrade the server to Bazaar 1.2 to avoid this)' when you use bzr+ssh -
the upgrade
On Mon, Mar 17, 2008, Robert Collins wrote:
> > It maxes out on my kit at the above speed; but at 32k replies it hits 3100
> > req/sec
> > and close to a gigabit. I'll whack a recent linux distro+kernel on the test
> > boxes
> > in a few days and see how it compares.
>
> Sounds like its going w
On Mon, Mar 17, 2008, Adrian Chadd wrote:
> Benchmarking allocators is easy. Benchmarking allocators in real-world
> situations
> is less easy. The whole point of this work is to provide the minimum code
> needed
> to provide efficient(!) HTTP proxy services which can then be benchmarked in a
>
On Sat, 2008-03-15 at 13:49 +0100, Henrik Nordstrom wrote:
> On Fri, 2008-03-14 at 12:34 +0900, Adrian Chadd wrote:
> > Has anyone actually committed to the bzr tree? I haven't seen any commit
> > messages.
>
> Commit works fine, but commit messages is not yet operational. Waiting
> for Robert to
This reminds me, one of the things I was thinking heavily about a few
years ago was locality of reference in N-CPU situations. That is, making
sure we don't cause thrashing unnecessarily. For instance - given
chunking we can't really avoid seeing all the bytes for a MISS, so does
it matter if proce
On Mon, Mar 17, 2008, Robert Collins wrote:
> On Sun, 2008-03-16 at 14:04 +0900, Adrian Chadd wrote:
> > Annoyingly, why the hell is the request from the client a range request?
> > Squid can't easily cache those unless it somehow fetches the entire object
> > first.
>
> FWIW -3 has about 60% of t
On Mon, Mar 17, 2008, Robert Collins wrote:
> This reminds me, one of the things I was thinking heavily about a few
> years ago was locality of reference in N-CPU situations. That is, making
> sure we don't cause thrashing unnecessarily. For instance - given
> chunking we can't really avoid seeing
On Mon, 2008-03-17 at 12:05 +0900, Adrian Chadd wrote:
> On Mon, Mar 17, 2008, Robert Collins wrote:
> > On Sun, 2008-03-16 at 14:04 +0900, Adrian Chadd wrote:
> > > Annoyingly, why the hell is the request from the client a range request?
> > > Squid can't easily cache those unless it somehow fetch
On Sun, 2008-03-16 at 15:43 +, chtsanti wrote:
> Update of cvs.devel.squid-cache.org:/cvsroot/squid/squid3/src
...
> The xThrow function is similar to the old Throw function but in addition adds
> an extra check to see if the carrent call can handle exceptions or not. In the
> second case abort
On Sun, 2008-03-16 at 02:55 +0100, Henrik Nordstrom wrote:
> Cons:
> - Not entirely sure how ICAP and ESI fits into the reply processing. But
> I hope there is no problem..
>
> The bzr branch can be found at
> http://www.henriknordstrom.net/bzr/squid3/hno/largeresp/
> (bzr only, no online viewer
On Sun, 2008-03-16 at 22:19 +, Bundle Buggy wrote:
> Bundle Buggy has detected this merge request.
>
> For details, see:
> http://squid-cache.org/bundlebuggy//request/%3C1205705885.12036.4.camel%40HenrikLaptop%3E
bb:comment
Should not these formatting changes wait for the global astyle+wrap
On Mon, Mar 17, 2008, Robert Collins wrote:
> > I've looked at the -3 stuff, and its missing about as much as the -2
> > stuff is missing. The memory store is only a small part of the overall
> > problem handling sparse objects.
> >
> > (Unless there's some code I've missed that handles other ran
On Mon, 2008-03-17 at 13:24 +0900, Adrian Chadd wrote:
>
> Yes, but I think more thought needed to go into teaching the store
> about
> sparse objects (which the backend store hooks don't cover);
They don't yet, thats definitely true.
> teaching the
> store about re-populating the memory cache
bb:approve
24 matches
Mail list logo
