pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[kvic]

having a weird issue with chtome on my phone and pixelserv.

for some reasons when i load a page i often get part of the page displayed and 30 secs later it finishes displaying. it happens on snbforums.whenever i disable it everything is fine again. tested multiple times with the same result.

its kind of weird because it does not happen on my other devices (pc/laptop with chrome). so im not sure what could be causing that

I believe your blocking files upset those webpages. Try to use logging facility in pixelserv-tls to find out what domains might be rogue and whitelist them. Pls refer to the below post for the steps:

https://www.snbforums.com/threads/p...bserver-for-adblock.26114/page-57#post-387717

 

[kvic]

Update on my servstats. Finally I made it to 100 sch organically..

For both nodes RAM usage is 10-11MB. Looks good for me. However, knowing the reported usage from @Protik and @Raphie, I think Km-test.5 is still too aggressive on RAM. Will turn down a bit in next test version.

Done with an intensive coding session. Answers to some of the peculiar API behaviour are rare to come by and I had to dive into OpenSSL source to find out the answers. I believe people will be amazed by performance improvements in next test version.

Bad news is rc1 will be delayed (and you'll have to get hold of four new counters! lol). Good news is Km-test.6 will be available in 10 hrs if it doesn't crash.

 

[Protik]

I have some interesting update. Today morning RAM usage went up to 8%. I checked couple of hours later and the usage was 2%! I checked and the service is running well without any crash. Right now the RAM usage is 2.4%. The usage goes like this:

 4.19pm, 11 March - 7.2%
11:00pm, 11 March - 7.4%
11:56pm, 11 March - 7.5%
12.34am, 12 March - 7.6%
06:35am, 12 March - 8.0%
08:57am, 12 March - 2.0%
11.45am, 12 March - 2.4%

I am really curious on what is going on here.

 

[SMS786]

Server like pixelserv-tls is expected to run for months if not years. Hence, a simple moving average across the whole time horizon is pretty much useless. We're interested in more 'recent measurements' where EMA comes to help.

To look at the problem in a simpler way, consider that the most recent 500 measurements of request processing shall preferably weigh more than the previous 500 measurements. That's more interesting average value for people taking an observation of tav now.

Makes sense, thank you.

 

[SMS786]

Seems quite snippy. Just running a regular old 1gb 2.0 usb stick here on my 68U.

 

[Raphie]

Just ordered this stick too, let’s see of the RT-AC5300 can hold up.

AC86u, SanDisk Ultra Fit 3.0 in ASUS 3.0 USB port

CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.googletagservices.com
 1. load cert from disk: 4.829 ms
 2. load cert from disk: 4.793 ms
 3. load cert from disk: 4.892 ms
 4. load cert from disk: 4.776 ms
 5. load cert from disk: 4.819 ms
 6. load cert from disk: 4.780 ms
 7. load cert from disk: 4.812 ms
 8. load cert from disk: 4.795 ms
 9. load cert from disk: 4.767 ms
10. load cert from disk: 4.774 ms
average: 4.821 ms

tav 8 ms average processing time (per request)
tmx 167 ms longest processing time (per request)

 

[jrmwvu04]

The final numbers as we sign off to load the new fork release. htop MEM% 5.8 for both processes.

uts    2d 08:28    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    34    maximum number of service threads
kvg    2.81    average number of requests per service thread
krq    200    max number of requests by one service thread

req    8587    total # of requests (HTTP, HTTPS, success, failure etc)
avg    930 bytes    average size of requests
rmx    21740 bytes    largest size of request(s)
tav    14 ms    average processing time (per request)
tmx    10003 ms    longest processing time (per request)

slh    3576    # of accepted HTTPS requests
slm    334    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    282    # of dropped HTTPS requests (client disconnect without sending any request)
slu    158    # of dropped HTTPS requests (unknown error)
sct    100    ssl cache: # of cached cert
sch    2156    ssl cache: # of cache hit
scm    110    ssl cache: # of cache miss
scp    10    ssl cache: # of purge to free up slots

 

[kvic]

I have some interesting update. Today morning RAM usage went up to 8%. I checked couple of hours later and the usage was 2%! I checked and the service is running well without any crash. Right now the RAM usage is 2.4%. The usage goes like this:

 4.19pm, 11 March - 7.2%
11:00pm, 11 March - 7.4%
11:56pm, 11 March - 7.5%
12.34am, 12 March - 7.6%
06:35am, 12 March - 8.0%
08:57am, 12 March - 2.0%
11.45am, 12 March - 2.4%

I am really curious on what is going on here.

Thanks for taking the detailed records.

It's Linux memory management at play. At around 8.0% time, other tasks in your router needs RAM, Linux allocates RAM to these tasks. Hence, it's unlikely that pixelserv-tls is leaking memory.

As mentioned before Km-test.5 is a still bit aggressive on RAM usage. This has been addressed in Km-test.6.

 

[kvic]

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

Thanks again for all the GREAT testing and GREAT feedback.

This version includes quite a few changes not to be repeated and detailed here. You can read all the changes and details on kazoo.ga/pixelserv-tls.

I would recommend everyone on previous test versions to try this one!

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]

Seems quite snippy. Just running a regular old 1gb 2.0 usb stick here on my 68U.

1gb usb 2.0 stick must be quite old indeed. Nevertheless, the numbers are not bad at all.

In Km-test.6, the benchmark will do both cert generation and loading. '-B' does not require an argument but can take one if provided.

Below is my run on SanDisk Ultra Flair USB 3.0 on RT-AC56@1.2GHz. I won't recommend it to anyone who needs speed. The write is only fast in the first ~30s. Then the chip starts frying and its embedded firmware slows it down (In other words, SanDisk cheats in this product).

$ pixelserv-tls -B
CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.bing.com
 1. generate cert to disk: 496.893 ms    load from disk: 9.976 ms
 2. generate cert to disk: 697.799 ms    load from disk: 9.926 ms
 3. generate cert to disk: 640.280 ms    load from disk: 10.210 ms
 4. generate cert to disk: 389.483 ms    load from disk: 10.122 ms
 5. generate cert to disk: 435.186 ms    load from disk: 9.925 ms
 6. generate cert to disk: 393.154 ms    load from disk: 9.971 ms
 7. generate cert to disk: 638.674 ms    load from disk: 9.934 ms
 8. generate cert to disk: 461.701 ms    load from disk: 9.930 ms
 9. generate cert to disk: 653.679 ms    load from disk: 10.105 ms
10. generate cert to disk: 580.715 ms    load from disk: 10.001 ms
generate to disk average: 538.756 ms
  load from disk average: 10.010 ms

 

[kvic]

The final numbers as we sign off to load the new fork release. htop MEM% 5.8 for both processes.

uts    2d 08:28    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    34    maximum number of service threads
kvg    2.81    average number of requests per service thread
krq    200    max number of requests by one service thread

req    8587    total # of requests (HTTP, HTTPS, success, failure etc)
avg    930 bytes    average size of requests
rmx    21740 bytes    largest size of request(s)
tav    14 ms    average processing time (per request)
tmx    10003 ms    longest processing time (per request)

slh    3576    # of accepted HTTPS requests
slm    334    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    282    # of dropped HTTPS requests (client disconnect without sending any request)
slu    158    # of dropped HTTPS requests (unknown error)
sct    100    ssl cache: # of cached cert
sch    2156    ssl cache: # of cache hit
scm    110    ssl cache: # of cache miss
scp    10    ssl cache: # of purge to free up slots

5.8% is about 14.8MB on RT-AC1900P. It will look better in Km-test.6. Maximum TLS session cache size and time both reduced to half of that in previous versions.

In Km-test.6, also the most frequently used 3/4 certs (instead of 2/3 in previous versions) will be saved on exit for prefetch on next startup. This will make better use of cache history as well as prefetch on startup.

 

[SMS786]

1gb usb 2.0 stick must be quite old indeed. Nevertheless, the numbers are not bad at all.

In Km-test.6, the benchmark will do both cert generation and loading. '-B' does not require an argument but can take one if provided.

Below is my run on SanDisk Ultra Flair USB 3.0 on RT-AC56@1.2GHz. I won't recommend it to anyone who needs speed. The write is only fast in the first ~30s. Then the chip starts frying and its embedded firmware slows it down (In other words, SanDisk cheats in this product).

$ pixelserv-tls -B
CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.bing.com
 1. generate cert to disk: 496.893 ms    load from disk: 9.976 ms
 2. generate cert to disk: 697.799 ms    load from disk: 9.926 ms
 3. generate cert to disk: 640.280 ms    load from disk: 10.210 ms
 4. generate cert to disk: 389.483 ms    load from disk: 10.122 ms
 5. generate cert to disk: 435.186 ms    load from disk: 9.925 ms
 6. generate cert to disk: 393.154 ms    load from disk: 9.971 ms
 7. generate cert to disk: 638.674 ms    load from disk: 9.934 ms
 8. generate cert to disk: 461.701 ms    load from disk: 9.930 ms
 9. generate cert to disk: 653.679 ms    load from disk: 10.105 ms
10. generate cert to disk: 580.715 ms    load from disk: 10.001 ms
generate to disk average: 538.756 ms
  load from disk average: 10.010 ms

Just loaded Km-test.6. Updated benchmark on my 68U with my 1gb usb 2.0 stick..only about ~2ms slower than the 3.0 drives.. ¯\_(ツ)_/¯

I take it as a testament to how efficiently the code must be written..kudos @kvic!

CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.bing.com
 1. generate cert to disk: 712.528 ms   load from disk: 11.750 ms
 2. generate cert to disk: 632.346 ms   load from disk: 11.826 ms
 3. generate cert to disk: 1016.902 ms  load from disk: 11.718 ms
 4. generate cert to disk: 372.315 ms   load from disk: 11.681 ms
 5. generate cert to disk: 515.230 ms   load from disk: 11.751 ms
 6. generate cert to disk: 941.555 ms   load from disk: 11.693 ms
 7. generate cert to disk: 522.335 ms   load from disk: 12.137 ms
 8. generate cert to disk: 711.322 ms   load from disk: 11.808 ms
 9. generate cert to disk: 1048.739 ms  load from disk: 11.760 ms
10. generate cert to disk: 716.034 ms   load from disk: 12.592 ms
generate to disk average: 718.931 ms
  load from disk average: 11.872 ms

 

[Raphie]

with v6


CERT_FILE: _.googletagservices.com
1. generate cert to disk: 583.286 ms load from disk: 8.369 ms
2. generate cert to disk: 280.791 ms load from disk: 8.489 ms
3. generate cert to disk: 355.932 ms load from disk: 8.393 ms
4. generate cert to disk: 322.649 ms load from disk: 8.338 ms
5. generate cert to disk: 465.341 ms load from disk: 8.432 ms
6. generate cert to disk: 354.176 ms load from disk: 8.842 ms
7. generate cert to disk: 894.336 ms load from disk: 8.412 ms
8. generate cert to disk: 574.277 ms load from disk: 8.666 ms
9. generate cert to disk: 370.298 ms load from disk: 8.421 ms
10. generate cert to disk: 623.625 ms load from disk: 8.353 ms
generate to disk average: 482.471 ms
load from disk average: 8.471 ms

 

[kvic]

Just loaded Km-test.6. Updated benchmark on my 68U with my 1gb usb 2.0 stick..only about ~2ms slower than the 3.0 drives.. ¯\_(ツ)_/¯

CERT_PATH: /opt/var/cache/pixelserv
CERT_FILE: _.bing.com
 1. generate cert to disk: 712.528 ms   load from disk: 11.750 ms
 2. generate cert to disk: 632.346 ms   load from disk: 11.826 ms
 3. generate cert to disk: 1016.902 ms  load from disk: 11.718 ms
 4. generate cert to disk: 372.315 ms   load from disk: 11.681 ms
 5. generate cert to disk: 515.230 ms   load from disk: 11.751 ms
 6. generate cert to disk: 941.555 ms   load from disk: 11.693 ms
 7. generate cert to disk: 522.335 ms   load from disk: 12.137 ms
 8. generate cert to disk: 711.322 ms   load from disk: 11.808 ms
 9. generate cert to disk: 1048.739 ms  load from disk: 11.760 ms
10. generate cert to disk: 716.034 ms   load from disk: 12.592 ms
generate to disk average: 718.931 ms
  load from disk average: 11.872 ms

Spot on! Bear in mind that the benchmark tool is more towards crypto combined with disk access. I shall emphasise that majority of the time is spent on computationally intensive subroutines (even on loading certs) that this benchmark and everyday pixelserv-tls operations share.

The disk access is perhaps 1% of the total time. Hence, I've renamed the feature to "Benchmark crypto and disk" with emphasis on crypto rather than disk.

Also added a disclaimer on my blog, and repeated below, in order not to mislead people:

 

[kvic]

with v6


CERT_FILE: _.googletagservices.com
1. generate cert to disk: 583.286 ms load from disk: 8.369 ms
2. generate cert to disk: 280.791 ms load from disk: 8.489 ms
3. generate cert to disk: 355.932 ms load from disk: 8.393 ms
4. generate cert to disk: 322.649 ms load from disk: 8.338 ms
5. generate cert to disk: 465.341 ms load from disk: 8.432 ms
6. generate cert to disk: 354.176 ms load from disk: 8.842 ms
7. generate cert to disk: 894.336 ms load from disk: 8.412 ms
8. generate cert to disk: 574.277 ms load from disk: 8.666 ms
9. generate cert to disk: 370.298 ms load from disk: 8.421 ms
10. generate cert to disk: 623.625 ms load from disk: 8.353 ms
generate to disk average: 482.471 ms
load from disk average: 8.471 ms

Looks good as before.

Note that people shall not be too worried about the "huge" time on cert generation. Generating a cert is considered very rare event in pixelserv-tls, and is handled asynchronously. Hence, nothing is waiting. The first HTTPS request is quickly rejected, subsequent HTTPS requests on the same domain start to work after the cert is automatically generated.

Load time is way more frequently experienced. With SSL cache feature added in v2.1, it's less critical than it used to be.

On Km-test.6, pls also help to watch out on RAM usage as well as snappiness on page loads like Daily Mail etc. Personally I found that DM is snappier than test.5.

 

[pattiri]

test 6 running good on my router for about 5 hours.

Just a question; is this normal?

 

[kvic]

test 6 running good on my router for about 5 hours.

Just a question; is this normal?

View attachment 12273

The number of rows with "pixelserv-tls" are pthreads or in servstats page's terminology "service threads" (kcc). The total number of service threads adapt dynamically to the workload from clients on your LAN. Hence, this part is normal.

The RAM usage is about 14MB in your screenshot. It seems to me a bit more than I would expect. However, it depends on the recent and current workload from LAN clients. Can you attach the servstats numbers for diagnosis?

 

[pattiri]

The number of rows with "pixelserv-tls" are pthreads or in servstats page's terminology "service threads" (kcc). The total number of service threads adapt dynamically to the workload from clients on your LAN. Hence, this part is normal.

The RAM usage is about 14MB in your screenshot. It seems to me a bit more than I would expect. However, it depends on the recent and current workload from LAN clients. Can you attach the servstats numbers for diagnosis?

Here;

http://prntscr.com/iqk5wg

 

[kvic]

Here;

http://prntscr.com/iqk5wg

Km-test.6 runs well on your router. Just be aware of that "slc" is very high. That indicates some devices on your LAN (or VPN server) have intensive browsing activities but without the CA cert (generated your AB-Solution) imported.

Given that "sst" is 222 which indicates cached TLS sessions, 14MB RAM used perhaps not much to worry yet. You can use the following formula to do a rough estimation:

• sst * 50 / 1024 + 3 = expected RAM usage in MB by pixelserv-tls

Pls help me to monitor your "sst" value. Jot down "sst" value right before your LAN is about to sleep, and then again the following morning before your LAN wake up to a busy day.

 

[pattiri]

Km-test.6 runs well on your router. Just be aware of that "slc" is very high. That indicates some devices on your LAN (or VPN server) have intensive browsing activities but without the CA cert (generated your AB-Solution) imported.

Given that "sst" is 222 which indicates cached TLS sessions, 14MB RAM used perhaps not much to worry yet. You can use the following formula to do a rough estimation:

• sst * 50 / 1024 + 3 = expected RAM usage in MB by pixelserv-tls

Pls help me to monitor your "sst" value. Jot down "sst" value right before your LAN is about to sleep, and then again the following morning before your LAN wake up to a busy day.

I'm not sure if it is related but there are 366 files under "\var\cache\pixelserv" and sst is now 444

Tonight I need to keep my laptop turned on but my other devices will be turned off I'll let you know tomorrow morning. here it's 15:30 so I have lots of time