pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[thelonelycoder]

I've no way to test and confirm. Hopefully this time it'll work..I just uploaded a freshly brewed new build.

You have a fresh brew? I've booked my flight to Hong Kong...
Here, that's a lot better, working now in AB-Solution 4 on my RT-AC86U:

tlc@RT-AC86U-AD60:/tmp/home/root# pixelserv-tls -v
pixelserv-tls: v2.1.0-test.2 compiled: Mar  6 2018 05:38:46
Usage: pixelserv-tls [OPTION]
options:
    ip_addr/hostname    (default: 0.0.0.0)
    -2            (disable HTTP 204 reply to generate_204 URLs)
    -c  CERT_CACHE_SIZE    (default: 100)
    -f            (stay in foreground/don't daemonize)
    -k  HTTPS_PORT        (default: 443)
    -l  LEVEL        (0:critical 1:error<default> 2:warning 3:notice 4:info 5:debug)
    -n  IFACE        (default: all interfaces)
    -o  SELECT_TIMEOUT    (default: 10s)
    -O  KEEPALIVE_TIME    (for HTTP/1.1 connections; default: 120s)
    -p  HTTP_PORT        (default: 80)
    -R            (disable redirect to encoded path in tracker links)
    -s  STATS_HTML_URL    (default: /servstats)
    -t  STATS_TXT_URL    (default: /servstats.txt)
    -T  MAX_THREADS        (default: 1200)
    -u  USER        (default: "nobody")
    -z  CERT_PATH        (default: /opt/var/cache/pixelserv)

 

[kvic]

Glad to hear it works! Two trials on the new Entware-3.x toolchain then success..I consider that not great but neither bad.

Just a reminder to RT-AC86U users, beta version is available for test if you want some fun too. May use the same script for install:

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

Note that it's 64-bit binary for Entware-3.x. So the script will quit if you only have 32-bit Entware-3.x installed. Thanks to a reminder from @Adamm.

 

[kvic]

An update on my "pixelserv-tls cluster"...

New statistics after 36 hrs of normal usage. On light workload, fewer cores with higher clock wins over more cores with lower clock.

But note that the instance on ER-X somehow receives more requests and also has a higher proportion of HTTPS in its requests (ER-X: 83% HTTPS vs RT-AC56U 73% HTTPS).

 

[kvic]

An update on my "pixelserv-tls cluster"...

New statistics after 36 hrs of normal usage. On light workload, fewer cores with higher clock wins over more cores with lower clock.

But note that the instance on ER-X somehow receives more requests and also has a higher proportion of HTTPS in its requests (ER-X: 83% HTTPS vs RT-AC56U 73% HTTPS).

The numbers now look interesting after another 1.5 hours. Somehow the load got distributed more to the 56U node. And some websites had gone bonkers that boosted total number of requests overall. See also the "krq" jumping over 1500 for ER-X, and near 1000 for 56U. Percentage of HTTPS requests, ~90%, are about the same on both nodes.

Under such workload, more cores lower clock took back the crown with an average processing time of 1ms for the ER-X node vs 4ms (not bad at all) for the 56U node.

 

[thelonelycoder]

Glad to hear it works! Two trials on the new Entware-3.x toolchain then success..I consider that not great but neither bad.

8 hours and still up, but that was during the night, so not much traffic went through it:

pixelserv-tls: v2.1.0-test.2 compiled: Mar 6 2018 05:38:46 options: 192.168.2.2 -l 3 -c 95

uts    0d 08:00    process uptime
log    3    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    11    maximum number of service threads
kvg    1.64    average number of requests per service thread
krq    21    max number of requests by one service thread
req    9913    total # of requests (HTTP, HTTPS, success, failure etc)
avg    835 bytes    average size of requests
rmx    2209 bytes    largest size of request(s)
tav    17 ms    average processing time (per request)
tmx    138 ms    longest processing time (per request)
slh    205    # of accepted HTTPS requests
slm    0    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    0    # of dropped HTTPS requests (client disconnect without sending any request)
slu    0    # of dropped HTTPS requests (unknown error)
sct    24    ssl cache: # of cached cert
sch    9767    ssl cache: # of cache hit
scm    24    ssl cache: # of cache miss
scp    0    ssl cache: # of purge to free up slots

 

[kvic]

@thelonelycoder, looks like your network isn't that quiet even at night. And your 86U seems quite busy too because after hearing all the good comments about 86U's cpu, a tav of 17ms looks fair. The lower tav and tmx does reflect a more powerful CPU in 86U.

edit:
I also notice the much higher "sch" like in @Raphie's case i.e "slh" much < "sch". Seems like you both have something in common in your environment/setup. Can't explain what's the reason. I need to think harder..

 

[thelonelycoder]

And your 86U seems quite busy too because after hearing all the good comments about 86U's cpu, a tav of 17ms looks fair. The lower tav and tmx does reflect a more powerful CPU in 86U.

I set -c to an arbitrary number, just for using the switch. 95 sounds like a neat number.
I also was expecting a lower tav but that might change during the day with more usage.

 

[XIII]

According to the script the 2.1.0-test.2 beta got installed correctly on my RT-AC86u (armv8):

Congratulations. pixelserv-tls v2.1.0-test.2 installed.

However (after restarting pixelserv-tls and AB-Solution), AB-Solution still lists 2.0.1:

ps  pixelserv-tls    [192.168.1.2] [v2.0.1]

 

[thelonelycoder]

However, AB-Solution still lists 2.0.1:

Run ps, the re-check is only done if you update through its opkg management or open the ps menu.

 

[XIII]

Run ps, the re-check is only done if you update through its opkg management or open the ps menu.

Indeed:

ps  pixelserv-tls    [192.168.1.2] [v2.1.0-test.2]

 

[thelonelycoder]

Indeed:

ps  pixelserv-tls    [192.168.1.2] [v2.1.0-test.2]

This is handled differently in the next major AB version, the string is checked every time the UI is opened.

 

[kvic]

I also notice the much higher "sch" like in @Raphie's case i.e "slh" much < "sch". Seems like you both have something in common in your environment/setup. Can't explain what's the reason. I need to think harder..

While the exact numbers as in Raphie full servstats are quite hard to reconcile, the phenomenon of much higher sch can now be fully explained:

slh is incremented after a HTTPS request is successfully processed. sch is incremented after a certificate is found in cache. The sequence of events when a client connects to pixelserv-tls:

1. pixelserv-tls tries to look up the certificate on disk. If not found, submits a command for generation asynchronously. slm is incremented.
2. next, pixelserv-tls checks the cache. If not found, load certificate from disk. scm is incremented.
3. pixelserv-tls attempts to complete TLS handshake with the client.
4. pixelserv-tls processes the request if handshake passes. slh is incremented.

For clients without a pixelserv-tls CA certificate imported, the handshake in step 3 will fail and clients disconnect.

In both gents' cases the majority of sch should be coming from one or more appliances that are without the CA cert imported but are calling home over HTTPS on a regular basis.

So new counters work as expected. From this analysis, I actually saw one more optimisation we could do in the cache algorithm and that'll come in Km-test.3.

In other news, I found there is an oversight in the original pixelserv code on handling optimisation for child sockets. It's rectified and will come in Km-test.3 as well. Both together we shall see some more speed boost in next test.

 

[Raphie]

That’s correct, there is a printer, 3 smart TV’s, a synology NAS, a PS4 With PSplus subscription and probably some other stuff I’m forgetting

I’ve only bothered to install certificates on the phones, ipads and desktops, where advertisements actually occur.

 

[jrmwvu04]

where advertisements actually occur

I can't speak for the printer and NAS, but those TVs and especially the PS4 are hitting your blocked domains, trust me.

In other news, I found there is an oversight in the original pixelserv code on handling optimisation for child sockets. It's rectified and will come in Km-test.3 as well. Both together we shall see some more speed boost in next test.

Final numbers from last night, before I started messing with Entware. I did finally roll over and purge some certs.

 

[kvic]

I can't speak for the printer and NAS, but those TVs and especially the PS4 are hitting your blocked domains, trust me.

Final numbers from last night, before I started messing with Entware. I did finally roll over and purge some certs.

The numbers look good. Now I wonder if "scp" is needed. Seems always will be "scm" - "sct" once the cache is full.

 

[elorimer]

1. pixelserv-tls tries to look up the certificate on disk. If not found, submits a command for generation asynchronously. slm is incremented.
2. next, pixelserv-tls checks the cache. If not found, load certificate from disk. scm is incremented.
3. pixelserv-tls attempts to complete TLS handshake with the client.
4. pixelserv-tls processes the request if handshake passes. slh is incremented.

Out of curiosity, why not do step #2 first? It looks like 90 to 95%+ of the https requests are being satisfied from the cache. Doesnt this mean you have to hit the USB stick each time?

 

[kvic]

Out of curiosity, why not do step #2 first? It looks like 90 to 95%+ of the https requests are being satisfied from the cache. Doesnt this mean you have to hit the USB stick each time?

You're right. Most likely the ssl cache will serve the majority of certs. Even though the disk check itself was programmed to be very fast (and most likely checking against RAM cache by Linux fs). But why not prioritise cache check first..so it'll be in Km-test.3.

 

[esco]

Guys, just tried to update to the latest beta via the script on my 86U but no luck with armv8 package:

"This armv8 beta binary won't be compatible with your router"

My guess is I have 32bit version of Entware installed (has been deployed via A-B PS option), do I need to completely remove A-B with Entware and make a new install? Thank you.

 

[thelonelycoder]

Guys, just tried to update to the latest beta via the script on my 86U but no luck with armv8 package:

"This armv8 beta binary won't be compatible with your router"

My guess is I have 32bit version of Entware installed (has been deployed via A-B PS option), do I need to completely remove A-B with Entware and make a new install? Thank you.

You have to select the correct version, option 1 "1. armv7" is what you want to install.
armv8 is for 64-bit Entware version which was not installed at the time you did install AB-Solution.
With today's changes to the AB-installer you will get the 64-bit version, but only on a new install.

 

[jrmwvu04]

Now I wonder if "scp" is needed. Seems always will be "scm" - "sct" once the cache is full.

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