search for: chokepoint

I believe the load test documents state that the load tests were two test machines connected via a gigabit switch. In this sense there was no 'internet line' chokepoint: It was just machine A (server) and machine B (simulating many many listeners) both plugged into the same switch, for a straight through 1gig connection from machine A to B. In your case, with FIOS, I think the usual ((Number of listeners * your streaming bitrate) + 10% TCP overhead) type calculat...

...;free_callbacks[i+1], &h->free_callbacks[i], > + (h->nr_free_callbacks - i) * sizeof (struct free_callback)); Hmm - the use of memmove() is O(n); we'd need a different data structure (for example red-black tree or hash table) if we wanted list manipulations to not be the chokepoint. So, as long as you are already stuck with an O(n) list manipulation, using O(n) lookup is not making the problem any worse. > + > + h->free_callbacks[i].ptr = ptr; > + h->free_callbacks[i].cb = cb; > + h->free_callbacks[i].user_data = user_data; > + h->nr_free_call...

...p;h->free_callbacks[i], > > + (h->nr_free_callbacks - i) * sizeof (struct free_callback)); > > Hmm - the use of memmove() is O(n); we'd need a different data structure > (for example red-black tree or hash table) if we wanted list > manipulations to not be the chokepoint. So, as long as you are already > stuck with an O(n) list manipulation, using O(n) lookup is not making > the problem any worse. h->nr_free_callbacks is actually reasonably small in real code (usually <= 20). It's somewhat related to the number of commands in flight multiplied by...

...acks[i], >>> + (h->nr_free_callbacks - i) * sizeof (struct free_callback)); >> >> Hmm - the use of memmove() is O(n); we'd need a different data structure >> (for example red-black tree or hash table) if we wanted list >> manipulations to not be the chokepoint. So, as long as you are already >> stuck with an O(n) list manipulation, using O(n) lookup is not making >> the problem any worse. > > h->nr_free_callbacks is actually reasonably small in real code > (usually <= 20). It's somewhat related to the number of commands...

As proposed here: https://www.redhat.com/archives/libguestfs/2019-August/msg00130.html I didn't actually read Eric's replies to that yet because I've been concentrating on writing these patches all day. Anyway here they are and I'll look at what Eric said about the proposal next. Rich.