need more tests and I'll be back to you
for feedback
the problem I found is that it doesn't use the default php path at least for ubuntu
jt console uses /opt/php/php-fpm.sock whereas the default ubuntu 20.04 LTS uses /run/php/ph-fpm.sock
I had to symlink that to make it work
extra tiny step but worth noting
other than that great job timblians
just for the record my system is ubuntu 20.04 ondrej/nginx dockerized mysql 5.7.31 php7.4.9 maybe that helps
Making some very nice progress on caching indeed.
This is a mason command line script, that can revalidate the pages cache, either revalidating the whole cache (--force) but it can also do so incrementally or, for a single url if you provide the url.
what tool is mason? all I found is masonry is it the same thing?
you are mainly a php expert other timblians do the frontend stuff right @johanjanssens ?
understood sir
efficiency to the extreme
https://www.fastly.com/blog/supercharging-server-timing-http-trailers playing with this one right now
everperf. performance never ends.
but I have a question.
Why does start time begin only when request reaches the middlebox (in this case fastly) ?
Why does start time begin only when request reaches the middlebox (in this case fastly) ?
because thats the only time they can start from, other middleware can add it's own timing
done, framework is not outputting the total server time for each request.
that make sense but just to be sure. Couldn't they add the time it took from client to the middle box to have a complete overview of the the real tota time? If it took X sec to reach the middlebox and Y sec from middlebox to server then Z sec from server to middlebox and N from middlebox to client the real total time should be X+Y (time to server) + (Z + N) (time from server) right? oversimplifying just to be clear and simple
so passionate you can't stop coding