What's new

pixelserv pixelserv - A Better One-pixel Webserver for Adblock

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Take your time. I believe ABS users are anxiously waiting for v4. :)

Not sure if you have charting feature planned like in Pi-Hole. I believe the '/servstats.txt' counters could be well illustrated as charts. With pixelserv-tls logging full-time, further charts could be drawn. You'll then beat Pi-Hole by miles as Pi-Hole cannot properly classify more than half of its traffic (in HTTPS)...

Not sure if Pi-Hole users are in this thread and aware of that. It's high time to advocate pixelserv-tls to your beloved Pi-Hole authors. Or get over taken by other better solutions...

Ditto!
 
If people wake up to find out your Google Drive, Gmail accounts and other Google services stop working...

Check if you have "www.googleapi.com" blocked and whitelist it.

I also wrote a little story on my blog to record and share the fantastic experience in using pixelserv-tls to help me spot the issue and figure out another 'wrongly blocked' domain.

pixelserv-tls Found Unexpected Gmail Login Failure

Have fun!
 
Take your time. I believe ABS users are anxiously waiting for v4. :)
Believe me, so do I!
Not sure if you have charting feature planned like in Pi-Hole. I believe the '/servstats.txt' counters could be well illustrated as charts. With pixelserv-tls logging full-time, further charts could be drawn. You'll then beat Pi-Hole by miles as Pi-Hole cannot properly classify more than half of its traffic (in HTTPS)...
This is planned for the AB4.x Web UI version. Development on this version will continue from where I left off once AB4.0 (SSH UI only) is released and stable.
 
This is planned for the AB4.x Web UI version. Development on this version will continue from where I left off once AB4.0 (SSH UI only) is released and stable.

Plenty of time. Enjoy the process. :)

The logging speed isn't SUPER fast in pixelserv-tls at the moment when log LEVEL = 4 or beyond. 'cos the logging workload is huge due to heavy adverts on most websites.

There is room to make it faster. So that leaving log LEVEL=4 or beyond on full time will have little impact on response time. I shall find some time later this year to get it up to speed in v2.x.
 
Documentation beta for v2.1 release

Thanks again for all the GREAT feedback on the Km cycle. Now we're trying to update a few official manuals.

On GitHub you may find these updated:
See if the updated docs help you understand pixelserv-tls more and hence make better use of it.

Will appreciate any feedback.
 
For the documentation, one thing I didn't at all appreciate was that some (one?) CLI options have URI equivalents. My routine was to ssh in, go into ab-s, change the options, restart, exit, see what happened, fix it, then go back into ab-s, change the options, restart, exit, etc.

The URI method for logging works on the fly; two windows, side by side.

I think that could be useful in the documentation.
 
For the documentation, one thing I didn't at all appreciate was that some (one?) CLI options have URI equivalents. My routine was to ssh in, go into ab-s, change the options, restart, exit, see what happened, fix it, then go back into ab-s, change the options, restart, exit, etc.

The URI method for logging works on the fly; two windows, side by side.

I think that could be useful in the documentation.
At a quick glance, I don’t see any mention of it. Probably just a simple oversight because that feature has been that way for as long as I can remember. Though it used to be only an on/off toggle instead of the handful of logging options it is today.
 
After 3d 15 hours,

Update my two instances of 2.1.0-rc.2 at 4d 13h...

RAM usage
1d9h: n1 8.2MB n2 6.5MB
2d16h: n1 13.9MB n2 11MB
3d15h: n1 15.2MB n2 13MB
4d13h: n1 17.9MB n2 17MB

Seeing the RAM usage pattern gets me thinking how some of it is managed inside OpenSSL library...

On the brighter side, cnn, foxnews and daily mail are all instant pop-up for me though I haven't access them in the past >12 hours.
 
Update my two instances of 2.1.0-rc.2 at 4d 13h...

RAM usage
1d9h: n1 8.2MB n2 6.5MB
2d16h: n1 13.9MB n2 11MB
3d15h: n1 15.2MB n2 13MB
4d13h: n1 17.9MB n2 17MB

Seeing the RAM usage pattern gets me thinking how some of it is managed inside OpenSSL library...

On the brighter side, cnn, foxnews and daily mail are all instant pop-up for me though I haven't access them in the past >12 hours.

I suspect it's not a memory leak per se. Rather some component of the running service is not offloading the unused certs/sessions from the memory.
 
I suspect it's not a memory leak per se. Rather some component of the running service is not offloading the unused certs/sessions from the memory.

It's not memory leak. I've confirmed with valgrind. It's dirty 4k pages still marked as owned by pixelserv-tls that system can take back if it wants.

However, they're not re-used right away either by pixelserv-tls or other processes. That makes wonder how internally OpenSSL and glibc manage RAM (aka heap memory).
 
The URI method for logging works on the fly; two windows, side by side.

I think that could be useful in the documentation.
that feature has been that way for as long as I can remember. Though it used to be only an on/off toggle instead of the handful of logging options it is today.

Good idea, thanks. I've added a section "Supported URI/API" in the man page.
/log=LEVEL
Change the log LEVEL without restarting pixelserv-tls. LEVEL is an
integer between 0 and 5 inclusive. The same definitions as in command
line option `-l LEVEL`. See above.

The URI '/log' was indeed supported long ago. Used to be 0 and 1 only and expanded to 0-5 in v2.0.
 
2 days 14 hours up on rc.2

Code:
pixelserv-tls 2.1.0-rc.2 (compiled: Mar 20 2018 21:11:49) options: 192.168.1.3 -l 2

uts    2d 14:08    process uptime
log    2    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    16    maximum number of service threads
kvg    1.35    average number of requests per service thread
krq    116    max number of requests by one service thread
req    9559    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1185 bytes    average size of requests
rmx    6127 bytes    largest size of request(s)
tav    6 ms    average processing time (per request)
tmx    340 ms    longest processing time (per request)
slh    858    # of accepted HTTPS requests
slm    36    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    6899    # of dropped HTTPS requests (client disconnect without sending any request)
slu    1677    # of dropped HTTPS requests (other TLS handshake errors)
sct    76    cert cache: # of certs in cache
sch    8313    cert cache: # of reuses of cached certs
scm    7    cert cache: # of misses to find a cert in cache
scp    0    cert cache: # of purges to give room for a new cert
sst    6    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    464    sess cache: # of reuses of cached TLS sessions
ssm    31    sess cache: # of misses to find a TLS session in cache
ssp    0    sess cache: # of purges to give room for a new TLS session

Memory usage 5.1%
 
2 days 14 hours up on rc.2

Memory usage 5.1%

thanks for the update.

I'm running my 3rd instance of rc.2. A new build for testing a different mem mgt strategy. Look forward to interesting findings.
 
Code:
uts    5d 02:01    process uptime
log    1    critical (0) error (1) warning (2) notice (3) info (4) debug (5)
kcc    1    number of active service threads
kmx    43    maximum number of service threads
kvg    3.91    average number of requests per service thread
krq    8204    max number of requests by one service thread

req    25298    total # of requests (HTTP, HTTPS, success, failure etc)
avg    1453 bytes    average size of requests
rmx    29964 bytes    largest size of request(s)
tav    4 ms    average processing time (per request)
tmx    3615 ms    longest processing time (per request)

slh    17245    # of accepted HTTPS requests
slm    400    # of rejected HTTPS requests (missing certificate)
sle    0    # of rejected HTTPS requests (certificate available but bad)
slc    106    # of dropped HTTPS requests (client disconnect without sending any request)
slu    3936    # of dropped HTTPS requests (other TLS handshake errors)

sct    100    cert cache: # of certs in cache
sch    4666    cert cache: # of reuses of cached certs
scm    124    cert cache: # of misses to find a cert in cache
scp    24    cert cache: # of purges to give room for a new cert
sst    9    sess cache: # of cached TLS sessions (for older non-RFC5077 clients)
ssh    650    sess cache: # of reuses of cached TLS sessions
ssm    100    sess cache: # of misses to find a TLS session in cache
ssp    0    sess cache: # of purges to give room for a new TLS session
 
Does using the "http://pixelserv ip/ca.crt" method work for 2.0.1?
I've tried it with FF, Chrome on W10 and with iOS and I just get a blank page with no prompts.
 
Does using the "http://pixelserv ip/ca.crt" method work for 2.0.1?
I've tried it with FF, Chrome on W10 and with iOS and I just get a blank page with no prompts.

yes I have no problem doing it in FF 59.0.1 (64-bit)
 
I thought the URI method came from 2.1.0.test7
 
Does using the "http://pixelserv ip/ca.crt" method work for 2.0.1?
I've tried it with FF, Chrome on W10 and with iOS and I just get a blank page with no prompts.

The feature is going to be added from v2.1. This is currently available from the test version 7 of v2.1. So you won't get it from v2.0.1.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top