pixelserv pixelserv - A Better One-pixel Webserver for Adblock

[Raphie]

when using the install script i get below?

This script (v0.1.3) will download and install v2.1.0-test.2 test version of pixelserv-tls.
The script will guide you through and automate the process.

The script currently only support these Entware-ng architectures:

   1. armv7  (RT-AC56U/68U/etc)  - backup prod versoin and install test v2.1.0-test.2
   2. mipsel (RT-N66U/AC66U/etc) - backup prod version and install test v2.1.0-test.2
sh: syntax error: unexpected "("

 

[Protik]

11 hours and no crash on v2.1.0-test.2! Awesome!!

 

[elorimer]

Seems to be fine, up 9 hours and the cache finally rotated a cert or two out (24 hours now, 20 certs rotated out, tav up to 24 ms)

req 2694 total # of requests (HTTP, HTTPS, success, failure etc)
avg 1113 bytes average size of requests
rmx 18407 bytes largest size of request(s)
tav 11 ms average processing time (per request)
tmx 6553 ms longest processing time (per request)
slh 1796 # of accepted HTTPS requests
slm 2 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 129 # of dropped HTTPS requests (client disconnect without sending any request)
slu 171 # of dropped HTTPS requests (unknown error)
sct 100 ssl cache: # of cached cert
sch 765 ssl cache: # of cache hit
scm 102 ssl cache: # of cache miss
scp 2 ssl cache: # of purge to free up slots

 

[kvic]

when using the install script i get below?

This script (v0.1.3) will download and install v2.1.0-test.2 test version of pixelserv-tls.
The script will guide you through and automate the process.

The script currently only support these Entware-ng architectures:

   1. armv7  (RT-AC56U/68U/etc)  - backup prod versoin and install test v2.1.0-test.2
   2. mipsel (RT-N66U/AC66U/etc) - backup prod version and install test v2.1.0-test.2
sh: syntax error: unexpected "("

v0.1.3 added an entry for armv8 but marked as "broken binary" for now.

The error had been fixed. Everyone shall be able to install for armv7 and mipsel as usual.

 

[kvic]

My organic tests have also been up for 12 hrs. So far looks good.

While doing that, I'm also toying with a cluster of pixelserv-tls. At the moment, it only has two nodes which randomly receive requests from clients.

Here is some interesting statistics.

On a future version we can let individual pixelserv-tls talk to each other in the cluster for further speed!

 

[Raphie]

Installer works perfect now, thank you!
Pixelserv itself behaves very smooth as well. Am I imagining a snappier browser experience?

 

[kvic]

I feel snappier too, especially on sites that I have visited before (hence pixelserv-tls has cached certs in memory). We can repeat this benchmark later to rationalise the feeling.

edit:
On a 7-year old Sandy Bridge, re-visiting Daily Mail popped up instantly!

 

[SMS786]

v2.1.0-test.2 has almost 11 hours of uptime on my 68u running 384.4beta1..looks great!

 

[Raphie]

beatiful

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

 

[kvic]

For Entware-3.x users on RT-AC86U, now you can install the 64-bit beta version from the same script:

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

Note that I assume everyone has picked the 64-bit Entware-3.x over 32 bit. In case, you've installed 32-bit Entware-3.x, the binary from this script won't work. I believe the forum "consensus" is to use the 64-bit version on RT-AC86U for better performance.

Edit:
It's 1.5 hr of wait (and compilation) and some work from me in between. So a very tedious process... RT-AC86U users better give it a try and provide some feedback

 

[kvic]

beatiful

The numbers look weird. Are there any mess up from cut & paste? "sch" = 3230 which is more than all possible HTTPS combined (slh+slm+sle+slc+slu)...

 

[jrmwvu04]

 

[kvic]

@jrmwvu04
you still have 5 certs to beat the cache allowed. I could never make it. I tried hard..

I noticed from outdoor activities that version Km gave me better response over VPN/WAN. I used to get ~80ms. Now it's about 30-40ms on Km.

 

[Raphie]

The numbers look weird. Are there any mess up from cut & paste? "sch" = 3230 which is more than all possible HTTPS combined (slh+slm+sle+slc+slu)...

2 hours later

pixelserv-tls: v2.1.0-test.2 compiled: Mar 4 2018 18:03:15 options: 192.168.1.2

uts 0d 11:08 process uptime
log 1 critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc 1 number of active service threads
kmx 52 maximum number of service threads
kvg 1.38 average number of requests per service thread
krq 25 max number of requests by one service thread
req 6794 total # of requests (HTTP, HTTPS, success, failure etc)
avg 1162 bytes average size of requests
rmx 34617 bytes largest size of request(s)
tav 108 ms average processing time (per request)
tmx 4737 ms longest processing time (per request)
slh 1080 # of accepted HTTPS requests
slm 3 # of rejected HTTPS requests (missing certificate)
sle 0 # of rejected HTTPS requests (certificate available but bad)
slc 1364 # of dropped HTTPS requests (client disconnect without sending any request)
slu 32 # of dropped HTTPS requests (unknown error)
sct 96 ssl cache: # of cached cert
sch 5956 ssl cache: # of cache hit
scm 96 ssl cache: # of cache miss
scp 0 ssl cache: # of purge to free up slots
nfe 430 # of GET requests for server-side scripting
gif 13 # of GET requests for GIF
ico 0 # of GET requests for ICO
txt 223 # of GET requests for Javascripts
jpg 2 # of GET requests for JPG
png 2 # of GET requests for PNG
swf 0 # of GET requests for SWF
sta 8 # of GET requests for HTML stats
stt 0 # of GET requests for plain text stats
ufe 30 # of GET requests /w unknown file extension
opt 13 # of OPTIONS requests
pst 305 # of POST requests
hed 0 # of HEAD requests (HTTP 501 response)
rdr 102 # of GET requests resulted in REDIRECT response
nou 0 # of GET requests /w empty URL
pth 0 # of GET requests /w malformed URL
204 0 # of GET requests (HTTP 204 response)
bad 23 # of unknown HTTP requests (HTTP 501 response)
tmo 37 # of timeout requests (client connect w/o sending a request in 'select_timeout' secs)
cls 1327 # of dropped requests (client disconnect without sending any request)
cly 143 # of dropped requests (client disconnect before response sent)
clt 0 # of dropped requests (reached maximum service threads)
err 0 # of dropped requests (unknown reason)

 

[kvic]

2 hours later

Thanks for the numbers! I need to think about ..what could have happened in your case.

 

[elorimer]

I would also have expected that slh would have equaled sch+scm. In my case slh is much higher, so there accepted https requests that neither went from the cache nor missed the cache.

 

[kvic]

I would also have expected that slh would have equaled sch+scm. In my case slh is much higher, so there accepted https requests that neither went from the cache nor missed the cache.

sch is incremented only if a HTTPS connection has to be re-established. Those "extra" slh in your case came from the benefit of persistent connections (specified in HTTP/1.1) and got implemented in pixelserv-tls v2.0.

edit: To elaborate further..

sch is incremented when a "new" connection is initiated by a client (Alice the PC browser) on a given ad domain. This connection could be 1) totally new from Alice or 2) could be a recurring visit from Alice. The ssl cert, if found in cache, could have be cached due to a) by another client visiting the same ad domain previously or b) by a previous visit from Alice.

So now there are couple of combinations of scenarios that will have various degree of benefits from the SSL cache. The best speed up for Alice is 2b where a full computationally intensive SSL handshake is eliminated. The next runner up for Alice is 1a.

A persistent connection in pixelserv-tls v2.0 is aka service thread. Option "-O" can adjust how long a connection is kept alive (hence in a sense persistent). It's not totally up to pixelserv-tls because a client can shutdown the connection proactively for whatever reason. Chrome makes aggressive use of persistent connections. Safari not so. Higher "-O" numbers may give better performance at the expensive of using slightly more system resource. The default is 120s. Maybe worth trying 300s.

 

[Adamm]

Note that I assume everyone has picked the 64-bit Entware-3.x over 32 bit. In case, you've installed 32-bit Entware-3.x, the binary from this script won't work. I believe the forum "consensus" is to use the 64-bit version on RT-AC86U for better performance.

I think you would be better off detecting what repo the user has installed via scanning "/opt/etc/opkg.conf"

Assuming users make the logical choice has a tendency to backfire

 

[thelonelycoder]

Edit:
It's 1.5 hr of wait (and compilation) and some work from me in between. So a very tedious process... RT-AC86U users better give it a try and provide some feedback

Using pixelserv-tls.armv8.ent.performance.dynamic I still get the same error:

user@RT-AC86U-AD60:/tmp/home/root# pixelserv-tls -v
pixelserv-tls: error while loading shared libraries: pixelserv-tls: unsupported version 0 of Verneed record

 

[kvic]

Using pixelserv-tls.armv8.ent.performance.dynamic I still get the same error:

user@RT-AC86U-AD60:/tmp/home/root# pixelserv-tls -v
pixelserv-tls: error while loading shared libraries: pixelserv-tls: unsupported version 0 of Verneed record

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