I just saw this from last month from Stefan Fritsch and Niklas Edmundsson: The fact that the client ip shows up on all threads points to some >> potential optimization: Recently active threads should be preferred, >> because their memory is more likely to be in the cpu caches. Right >> now, the thread that has been idle the longest time will do the work. >> >> Ah, virtually guaranteeing that the thread with the coldest cache gets to > do the work...
I definitely agree on the potential for improvement here, you would most > likely want to select either the thread that processed this request last > time, or the most recently active idle thread. These two conditions kinda > collides though, so the challenge is probably to come up with some rather > cheap selection algorithm that is good enough. > Which CPU memory caches are you referring to? 1. For stack, on a new request, you're writing a new call stack, the prior request's stack was unwound. 2. For heap, you're creating a new request pool, so you will be popping an apr memnode from the head of the allocator's free list. It may even be the same memnode that was pushed onto the free list when the prior request's apr pool was freed. 3. On a new request, the next code/instructions it will execute will be the functions that reads the http request and populates the request_rec. That's different code than happened at the end of the prior request (serving the request, logging the request, etc.). So, I'm not convinced a thread selection algorithm is needed.
