Tested "rofl0r:threads" as reverse proxy on freetz (mips) by changing the make file and patches.

Works as expected but the memory footprint is high. A config option for this purpose is recommended..

Works as expected but the memory footprint is high. A config option for this purpose is recommended..

thanks for testing. could you provide some comparison numbers before/after with the same MaxClients setting in the config file ?

btw in src/child.c, there's this block:

                if (pthread_attr_init(&attr) == 0) {
                        attrp = &attr;
                        pthread_attr_setstacksize(attrp, 256*1024);
                }

                if (pthread_create(&child->thread, attrp, child_thread, child) $
                        sblist_delete(childs, sblist_getsize(childs) -1);
                        free(child);
                        goto oom;
                }

in the line with pthread_attr_setstacksize(attrp, 256*1024);, a stack size of 256 KB is set per client. this value was chosen as a really conservative value that should work on any C library implementation, even the worst. i plan to make this a configurable setting. if you want, you could try out some lower values there, if you're using a musl-libc based linux such as openwrt, a value as low as 8*1024 might be sufficient. going even lower than that could potentially lead to crashes.

Tested this on MacOS:

       if (pthread_attr_init(&attr) == 0) {
                    attrp = &attr;
                    pthread_attr_setstacksize(attrp, 256*1024);
            }

            if (pthread_create(&child->thread, attrp, child_thread, child) $
                    sblist_delete(childs, sblist_getsize(childs) -1);
                    free(child);
                    goto oom;
            }

It works with 64*1024 Bytes, it crashes at lower values.

After restart the memory footprint (no matter which setting for 'MaxClients') is:

old model - Virtual memory size (932 kB) - Resident set size (400 kB)
threaded model - Virtual memory size (1160 kB) - Resident set size (420 kB)

After calling the same URLs from outside the memory footprint for the old model stays the same.
For the threaded model (all measurements with 256kB):

MaxClients, Virtual memory size, Resident set size
20, 2468 kB, 588 kB
50, 2992 kB, 636 kB
100, 2460 kB, 584 kB
150, 2732 kB, 628 kB
200, 2728 kB, 604 kB

I will try to change the stack size value later...

Sorry i think i have forgotten the worker for the old model. Every worker consumes 940 kB of extra memory.

This means that the footprint of the threaded model is lower than the old model?
Coz i have only 1 process of 3332 kB with the threaded model but i have 6032 kB with old model (with 5 StartServers).

This means that the footprint of the threaded model is lower than the old model?

yeah, my expectation was that the threaded model would use less memory, if the stacksize is set to a low value and a reasonable MaxClient limit is set, because the old model uses fork() which needs a complete copy of the address space of the parent per worker.

@rofl0r do you have time frame when will be merged ?

@rofl0r do you have time frame when will be merged ?

after sufficient testing. this is a quite intrusive PR and i want to get the details right before merging it into master. results like those from @harryboo are very important to get the full picture.

totally awesome!

Hello,
We have issue with proxy loop, so we are testing this branch on our prod, 10000 clients to proxy, I can do a feedback then.
Regards,
Nicolas

@limbo127: have you been able to do memory usage comparisons ?

15920 would be KBs, right ? so rougly 16 MB? that's not so bad given that each of the 3000 clients has a separate thread (in the old model, many clients would share a pre-forked process)

it seems to block tinyproxy thread

can you elaborate ? i have no idea what "it" is nor which thread, nor what is being blocked.

it does not answer to request

is that new ? it seems you were quite happy with this branch a couple weeks ago.
if so, what changed in your setup?

What is the status of this branch? I made a comparison between the current stable version and this branch and found that this solution works without throwing connection timeouts and connection refused errors. The current stable build has some unexpected behaviour when servers are under load.

Config I used (for the current stable build):
MaxClients: 100, MinSpareServers: 5, MaxSpareServers: 20

What is the status of this branch

it's quite complete and master will be switched to this branch soon. just need to find time to revise the SIGHUP config reloading system which could potentially interfere in unexpected ways with the running threads.

Hello,
tinyproxy does not proces request anymore, after some times
ERROR Oct 03 08:20:34 [2053]: opensock: Could not retrieve info for https
ERROR Oct 03 08:21:50 [2053]: read_buffer: read() failed on fd 3: Connection reset by peer

Regards,
Nicolas

tinyproxy does not proces request anymore, after some times

after how much time?

can you maybe post contents of /proc/$pid/status when this happens, where $pid is tinyproxy's pid ?

merged as 69c86b9...cd005a9. this branch is now the new master branch targetting 1.11.0, master has been renamed to tp-1.10.x and will only receive bugfixes.

I'm also having random read_buffer: read() failed on fd 8: Connection reset by peer, is a fixed newer version outhere? working on ubuntu 18.04, tinyproxy 1.8.4

@talishka: in order to get the benefits of this branch you need to compile git master from source. there is no release containing the changes yet. if you have further questions/issues, please open a new issue here, thanks.