cmullaparthi
Add support for {max_uses, integer()} to persistent connections
I'd like to compare the performance difference between setting non-default garbage collection settings (via worker_process_options) and simply closing a persistent connection after N uses. Generally speaking, I'm expecting the latter to be better if closing a persistent connection results in exiting of the connection's worker process and creating a new process.
Before attempting to implement this feature, I would like to hear if you have any thoughts and/or existing experience with such a feature.
This would be an interesting test to do. I have heard about performance degradation when having persistent connections, so it would be good option to have.
On 13 November 2012 07:07, Joseph Wayne Norton [email protected]:
I'd like to compare the performance difference between setting non-default garbage collection settings (via worker_process_options) and simply closing a persistent connection after N uses. Generally speaking, I'm expecting the latter to be better if closing a persistent connection results in exiting of the connection's worker process and creating a new process.
Before attempting to implement this feature, I would like to hear if you have any thoughts and/or existing experience with such a feature.
— Reply to this email directly or view it on GitHubhttps://github.com/cmullaparthi/ibrowse/issues/80.
I'm also wondering if support for {max_heap_size, integer()} might be effective too?
This limit could be compared against the worker's total_heap_size.
{total_heap_size, Size}:
Size is the total size in words of all heap fragments of the process. This currently include the stack of the process.
It is worth a try in my opinion.
On 14 November 2012 01:29, Joseph Wayne Norton [email protected]:
I'm also wondering if support for {max_heap_size, integer()} might be effective too?
This limit could be compared against the worker's total_heap_size.
{total_heap_size, Size}: Size is the total size in words of all heap fragments of the process. This currently include the stack of the process.
— Reply to this email directly or view it on GitHubhttps://github.com/cmullaparthi/ibrowse/issues/80#issuecomment-10351684.
Was any work ever done on this? If not, I will take a crack at it; it would be useful for managing some of our long running connections and balancing of work.
I have begun work on this on the here: benjaminplee/ibrowse@2b075b8d22fca8737d9fe7195c09df1ea26a1c14 off of the max_requests branch. Work was done as a quick spike without tests so far to vet the implementation against our test server.