<div dir="auto"><span style="font-family:sans-serif;font-size:12.8px">Hi</span><div dir="auto" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="auto" style="font-family:sans-serif;font-size:12.8px">It's possible that in some cases they will run concurrently, however not in my setup. The ICAPs are chained. If the chain doesn't guarantee it please let me know since I rely on it. </div><div dir="auto" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="auto" style="font-family:sans-serif;font-size:12.8px">Regarding what you said about things that can happen in parallel, I'm OK with it since what I care the most is the extra time my ICAPs add to the user latency and this is what I would like to measure.</div><div dir="auto" style="font-family:sans-serif;font-size:12.8px"><br></div><div dir="auto" style="font-family:sans-serif;font-size:12.8px">Thanks</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 15, 2021, 20:47 Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/14/21 3:04 PM, Moti Berger wrote:<br>
<br>
> I have the followings in squid.conf:<br>
> <br>
>     logformat metrics %icap::tt %adapt::all_trs %adapt::sum_trs<br>
>     %{service_req_a}adapt::sum_trs %{service_resp_a}adapt::sum_trs<br>
>     %{service_req_b}adapt::sum_trs %{service_resp_b}adapt::sum_trs<br>
>     access_log daemon:/var/log/squid/metrics.log metrics<br>
> <br>
>  <br>
> <br>
>     icap_service service_req_a reqmod_precache bypass=1 on-overload=wait<br>
>     routing=1 icap://a.y:12345/request<br>
>     icap_service service_req_b reqmod_precache bypass=1 on-overload=wait<br>
>     icap://b.y:10101/request<br>
>     adaptation_service_chain svcRequest service_req_a service_req_b<br>
>     adaptation_access svcRequest deny manager<br>
>     adaptation_access svcRequest allow all<br>
>     icap_service service_resp_a respmod_precache bypass=1<br>
>     on-overload=wait routing=1 icap://a.y:12345/response<br>
>     icap_service service_resp_b respmod_precache bypass=1<br>
>     on-overload=wait icap://b.y:10101/response<br>
>     adaptation_service_chain svcResponse service_resp_a service_resp_b<br>
>     adaptation_access svcResponse deny manager<br>
>     adaptation_access svcResponse allow all<br>
> <br>
> <br>
>  I see in metrics.log lines like this:<br>
> <br>
>     4 4,180 4,180 4 180 - -<br>
> <br>
> <br>
> Now I wonder how come the value of %icap:tt isn't at least as the sum of<br>
> all the numbers appear on %adapt::all_trs or %adapt::sum_trs (assuming<br>
> no failed transactions)?<br>
<br>
There is probably a bug somewhere, but please note that %icap:tt may not<br>
be the sum of individual transaction response times (in _some_ cases)<br>
even after that bug is fixed because those individual transactions may<br>
run _concurrently_ (i.e. partially overlap in time).<br>
<br>
<br>
> If %icap:tt isn't at least the sum of all ICAPs processing time, what is?<br>
<br>
Bugs notwithstanding, it is approximate time a master transaction spent<br>
doing adaptation (including checking whether adaptation is necessary).<br>
This stopwatch ticks when adaptation_access ACLs are checked and also<br>
when at least one adaptation transaction associated with that master<br>
transaction is in progress.<br>
<br>
Please note that a master transaction can do a lot of different things<br>
at once or in parallel. For example, it can communicate with an HTTP<br>
client while communicating with an FTP server while communicating with<br>
an eCAP REQMOD adaptation service while communicating with a DNS server<br>
to decide whether to start communicating with an ICAP RESPMOD service.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank" rel="noreferrer">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>