Next week there will be a test build of next version KL for download on Github.
Changes include:
Support HTTP/1.1 persistent connections
Add option 'O' for specifying timeout of persistent connections
Add new counters kcc, kmx and krq related to service threads (of persistent connections)
Add support for TCP Fast Open (require Linux kernel >= 3.16)
Support HTTP POST method for graceful processing
Double message buffer for more efficient processing of lengthy requests
Correct/enhance ring buffer handling in certificate generations
For feedback to current version Kk or future test versions, ppl have a choice to leave comments here, on the pixelserv-tls page or issuing a Github ticket.
All feedback will be read and thoroughly considered.
Both the "POST" and "Exit recv loop" are debug messages that will be removed in the final release or moved to only appear in a higher level of verbosity of logging.
Oct 10 07:54:08 pixelserv[28676]: POST Content-Length: 94
Oct 10 07:54:08 pixelserv[28676]: POST expect length: 0
The first line indicates a POST request is received and the client indicates a message of length 94 bytes. The second line indicates all 94 bytes are received in the very first message, and hence we expect no more from the client.
Another example: Oct 10 07:54:16 pixelserv[28676]: POST Content-Length: 6856
Oct 10 07:54:16 pixelserv[28676]: POST expect length: 2512
Oct 10 07:54:16 pixelserv[28676]: POST recv length: 2512; errno: 0
The first line indicates a POST message of length 6856 bytes. We received more than 3kb in the first message, and only expect 2512 bytes from the client. The third line indicates all 2512 bytes received successfully (hence errno = 0 = success).
The Exit recv loop is logged when a "service thread" finishes and kills itself.
fd is the socket descriptor which are very likely re-used and repeated. "errno: 0" indicates the client proactively closes the connection. "num_req" indicates how many requests are serviced by this thread aka known as HTTP/1.1 persistent connection.
HTTP/1.1 persistent connections help in speeding up the processing. This is especially apparent for HTTPS connections as TLS handshakes are no longer repeated for every single request. Nevertheless it helps both HTTP/S.
Max number of threads 67 indicates at its highest load 67 ad requests are being simultaneously serviced. Some websites are just crazy!
From my run so far only between 1 and 2 requests are serviced by one service thread or http/1.1 connection on average. It's registered in the kvg counter. This though varies with websites people visit.
Do you plan to make any more switch changes for Kl or is '-l level' the last you add before stable release?
I ask because I add them to the AB options.
Do you plan to make any more switch changes for Kl or is '-l level' the last you add before stable release?
I ask because I add them to the AB options.
In KL, it's only for syslog. People shall upgrade to syslog-ng from Entware-ng so that they can better manage with dedicated files. There is a thread on syslog-ng on this forum.
The new log facility will allow adding options of writing to a text file or maybe a sql db in a future version.
Yes, I mentioned in this thread before. But not recommended so I won't repeat here. Because ppl only need a small set of domains for daily use. It's a waste of resources to pre-generate certificates for close to 100K domains.
For a new domain, only first requests fails. It only takes 500ms to generate a certificate on a slow machine such as Cortext A9 800MHz CPU.
I've cloned the git repository onto a linux box I use for a dns server already. It is amd64. After linking all the libraries and doing the make amd64 im not sure what to do next. make install doesnt work. Help?
Every request is answered by spawning a process. A process is a heavy weight beast which requires significantly more resource (memory and time) to create and destroy.
in pixelserv-tls
When pthread was instroduced in pixelserv-tls, every request is answered by spawning a thread. A thread is also known as light weight process which is much more efficient to work with.
The question is why do we have to create a new process/thread to serve one single request and then kill off the process/thread?
We don't have to, and it's also not HTTP/1.1 compliant.
in version KL
pixelserv-tls will introduce HTTP/1.1 persistent connection. _cough_. A single thread can serve as many requests in burst as clients insist.
The screenshot below registers 102 in counter 'krq' - one single thread serves 102 ad requests (i.e. to the same ad server). That totally blows my mind away. Ads on some websites are simply gone mad.
