pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[elorimer]

I had the same thought looking at it. I wondered if it was simply a sanity check.

Or the other way round. How often was a purge required to make room.

 

[hervon]

More than 11h uptime with pixelserv-tls: v2.1.0-test.2 on 64bit merged entware with ab-solution on a 86U. At first pixelserv would crashed after 5 mins or so... After many trials and errors I got it fixed. I don't know what exactly fixed it but on my last attempt I 'Purge generated pixelserv certificate" in ab-solution.

 

[kvic]

More than 11h uptime with pixelserv-tls: v2.1.0-test.2 on 64bit merged entware with ab-solution on a 86U. At first pixelserv would crashed after 5 mins or so... After many trials and errors I got it fixed. I don't know what exactly fixed it but on my last attempt I 'Purge generated pixelserv certificate" in ab-solution.

Interesting. Thanks for reporting. I don't expect a difference in disk data between 32-bit and 64-bit but I also don't have a RT-86U to check. Pls help to watch if such crash is repeatable.

 

[kvic]

New beta version Km-test.3 aka v2.1.0-test.3

Thanks again for all the testing on the prior versions.

This version includes improvements in ssl caching and a few other optimizations for speed. Also added a new option "-A" to specify a "admin" port on command line.

For details in this test version and the upcoming v2.10 release, pls read the latest on kazoo.ga/pixelserv-tls.

Entware (ARMv7, mipsel, ARMv8) users can use the one liner below as usual or otherwise to install.

sh -c "$(wget -qO - https://kazoo.ga/pixelserv-tls/install-beta.sh)"

Will appreciate any feedback.

 

[kvic]

Forgot to mention that from my stress test on Km-test.2, with 100 certs filling up the cache and accessing from many clients, pixelserv-tls consumes roughly 10MB RAM (though they'll be freed up by the system when necessary).

In Km-test.3, pixelserv-tls will proactively purge expired sessions to free up RAM. Under similar workload, on average pixelserv-tls should be using less RAM.

So pls focus on stressing & crashing Km-test.3 in addition to your other interests in pixelserv-tls

 

[kvic]

Also worth mentioning on the client side.

On desktop, both Chrome and Firefox support two favours of SSL session resume. Both are supported by pixelserv-tls. And I could see the more advanced one is used during my tests. Great for pixelserv-tls since it consumes less RAM.

Previous SSL sessions will not kick in once you shutdown your browser completely. For modern day browsers, you shall really let it run always. Old habit of shutdown/re-launch of programs (and PC and routers...) should let go..

On Android, if you ditch Chrome/Firefox from RAM, then SSL session before shutdown won't kick in.

On iOS, I think Safari is always on. Great. But Safari on all platforms only supports a less server-friendly form of session resume. Hence, demanding quite a bit more RAM on pixelserv-tls. Nevertheless, as said in my previous post the worst in the stress test case as described used about 10MB.

 

[Raphie]

Installed test3, so far so good

 

[kvic]

Installed test3, so far so good

Nice. Pls try your best to abuse it, crash it and report abnormal RAM usage if any.

 

[thelonelycoder]

Nice. Pls try your best to abuse it, crash it and report abnormal RAM usage if any.

test3 working great on three routers here, no issues so far. Neither did test2 on the 86U but I had to restart it often for tests that have nothing to do with pixelserv-tls.

 

[Raphie]

I get more cache misses on v3 (about 1/3rd) while not browsing any new sites, just revisiting the usual ones. not sure if this is a problem?


slh 890 # of accepted HTTPS requests
slm 79 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 26 # of dropped HTTPS requests (client disconnect without sending any request)
slu 133 # of dropped HTTPS requests (unknown error)
sct 35 ssl cache: # of cached cert
sch 643 ssl cache: # of cache hit
scm 114 ssl cache: # of cache miss
scp 0 ssl cache: # of purge to free up slots

 

[elorimer]

@Raphie, that definitely looks wrong to me. Your cache miss looks to be the sum of the cached certs and the missing certificates. If I follow the new form, pixelserv goes to the cache, sees a certificate isn't there, and then is not loading it from disk or not generated a new one.

I'm not showing this behavior after 2 hours on .3:

slh 467 # of accepted HTTPS requests
slm 0 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 161 # of dropped HTTPS requests (client disconnect without sending any request)
slu 0 # of dropped HTTPS requests (unknown error)
sct 67 ssl cache: # of cached cert
sch 343 ssl cache: # of cache hit
scm 67 ssl cache: # of cache miss
scp 0 ssl cache: # of purge to free up slots

So in my case, pixelserv has gone to the cache and 67 times has not found a cert, so it loaded the cert into cache. I wonder if it would be different if you wiped your certs and started over.

 

[kvic]

Counter scm indeed has issue. In Km-test.3, scm is double counting slh. It'll be fixed in next test version. Thanks @Raphie.

 

[Raphie]

Seems scm = sct + slm ?

slh 1177 # of accepted HTTPS requests
slm 95 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 544 # of dropped HTTPS requests (client disconnect without sending any request)
slu 651 # of dropped HTTPS requests (unknown error)
sct 63 ssl cache: # of cached cert
sch 1352 ssl cache: # of cache hit
scm 158 ssl cache: # of cache miss
scp 0 ssl cache: # of purge to free up slots

 

[Protik]

Using v2.1.0-test.3.

slh    5879    # of accepted HTTPS requests
slm    4    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    916    # of dropped HTTPS requests (client disconnect without sending any request)
slu    300    # of dropped HTTPS requests (unknown error)
sct    69    ssl cache: # of cached cert
sch    2271    ssl cache: # of cache hit
scm    73    ssl cache: # of cache miss
scp    0    ssl cache: # of purge to free up slots

 

[jrmwvu04]

For a more aggressive test, processing times and especially tav is exceptionally low. I’ll let it go organically as I have little time to test today.

Seems scm = sct + slm ?

Does seem to be the case.

 

[hervon]

test 3 here too. Running fine. Stats :

slh    148    # of accepted HTTPS requests
slm    42    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    962    # of dropped HTTPS requests (client disconnect without sending any request)
slu    2096    # of dropped HTTPS requests (unknown error)
sct    58    ssl cache: # of cached cert
sch    33492    ssl cache: # of cache hit
scm    100    ssl cache: # of cache miss
scp    0    ssl cache: # of purge to free up slots

 

[Makaveli]

Test 3

18 hours in no issues.

 

[SMS786]

Just hit 16 hours here on my 68U running 384.4_beta2..test 3 buzzing along like a bee..

 

[kvic]

Thanks for all the feedback *and* lovely screenshots.

"scm double counting slm" is fixed in Km-test.4 which will be available in the next 12 hours. There is also further fine tuning in the ssl cache.

 

[kvic]

For a more aggressive test, processing times and especially tav is exceptionally low. I’ll let it go organically as I have little time to test today.

Low tav is great. Under such test/usage condition, the HTTP/1.1 persistent connections are at play and reduce *lots* of latency in responses.

In chronological order of additions into pixelserv-tls, we have

• cache certificates on disk (~2.5 yrs ago; initial version)
• cache connections as persistent connections (~3 mths ago; v2.0)
• cache certs and TLS sessions in the latest ssl cache

Looking back we've got quite a bit of sophisticated technologies in pixelserv-tls yet the binary is only about 40KB and RAM usage is under tight control.