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
running
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=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:
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=id
From what it looks this is set in bundlebuggy/templates/master.kid where
it's currently hardcoded to use the
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'm not
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
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 well. I'd
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
real
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 set up
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
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 the work
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 all
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 fetches the
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 aborts
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+wrapper
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
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
23 matches
Mail list logo
