Blog

programmng labo.

 

Thunderbirdで送受信できない

Thunderbird 78.5.1 (32 ビット)で送受信していたメールが、2020/12/01からぴったり送受信できなくなった。

Thunderbird自体のセキュリティについての変更(TLS1.0の非対応)による症状は2020/07の時点であるし、2020/12からというのはどうもおかしい。

と情報集めると、どうやらESETのウィルスチェッカのファイアウォールが悪さをしているとの情報が。

  1. タスクトレイのESETを右クリックし、詳細設定を選択


  2. 詳細設定画面の左ペインの「WEBとメール」を選択し、右ペインの「対象外のアプリケーション」の編集をクリック
  3. 対象外のアプリケーションで「追加」ボタンをクリックし、Thunderbirdを選択しOK

でThunderbirdでの送受信が今まで通り可能になった。

ESETの情報を見てみると

とまぁ2020/12/03ビルドが三つほどあるので、どれかが悪さをしていたのだろう。

 

 

» no reactions

Chrome 87 のタイマー その3

まず、setInterval

<!DOCTYPE html>
<html lang="jp">
<head>
<meta charset="utf-8"/>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
<script type="text/javascript">
    $(document).ready(function(){
        const dt = new Date();
        var cnt=0;
        setInterval(function(){
            let dt2 = new Date();
            let elapsed = Math.floor((dt2 - dt) / 1000);
            $('.test').replaceWith('<p class="test">start = ' + dt.toLocaleString() + '<br/>'
                + 'now = ' + dt2.toLocaleString() + '<br/>'
                + 'elapsed = ' + elapsed + '<br/>'
                + 'count = ' + cnt + '</p>');
            cnt ++;
        }, 1000);
    });
</script>
</head>
<body>
JavaScript::setInterval
<p class="test">スタート</p>
</body>
</html>

とし背後で5分以上経過させた後に表示した結果は、

こんな感じ。止まってない。

 

次はsetTimeout

<!DOCTYPE html>
<html lang="jp">
<head>
<meta charset="utf-8"/>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
    const dt = new Date();
    var cnt=0;
    var func = function(){
        let dt2 = new Date();
        let elapsed = Math.floor((dt2 - dt) / 1000);
        $('.test').replaceWith('<p class="test">start = ' + dt.toLocaleString() + '<br/>'
            + 'now = ' + dt2.toLocaleString() + '<br/>'
            + 'elapsed = ' + elapsed + '<br/>'
            + 'count = ' + cnt + '</p>');
            cnt++;
            setTimeout(func, 1000);
    };
    func();
});
</script>
</head>
<body>
JavaScript::setTimeout
<p class="test">スタート</p>
</body>
</html>

とし背後で5分以上経過させた後に表示した結果は、

おぉぉぉ??、なんかそれっぽいぞ!、setTimeoutでネストさせるとこういう調子になるわけね。

だがsetTimeoutでは5分とか必要なく、背後になったらすぐカウントに差がでてくる風だなぁ。10秒後あたりでタブ選択すると既にカウントが5くらい遅れてる。

ネストが5以上にひっかかるのか、4秒あたりで表示してもカウント1くらい遅れるしな。まぁこの辺の仕組みは気にしないことにする。

ちなみに同scriptをFireFoxで背後のタブで動かすと、setInterval / setTimeoutの両方とも多少の遅れは出てくるが、大きく止まったりすることはないようだ。

» no reactions

Chrome 87のタイマー その2

Chrome 87 のJavaScriptのタイマーwake-upについて、

https://docs.google.com/document/d/11FhKHRcABGS4SWPFGwoL6g0ALMqrFKapCk5ZTKKupEk/view#heading=h.iwgd72egb5s1

に書いてあった。

---

Policy

In a Window whose top Window has been hidden for 5 minutes and which is not opted out from intensive wake up throttling, a timer task with non-zero timeout can run:

 

  • on a 1-second aligned wake up if:
    • the timer task's nesting level is < 5, or,
    • the Window is same-origin with the top Window and at least 1 minute has elapsed since the last timer task with nesting level  >= 5 has run in any Window in the tree that is same-origin with the top Window
  •  on a 1-minute aligned wake up, otherwise.


Any timer task with nesting level >= 5 has a non-zero timeout due to step 11 of the timer algorithm (even if the timeout argument was zero).

---

Googleの翻訳では

ポリシー
上部のウィンドウが5分間非表示になっていて、集中的なウェイクアップスロットルからオプトアウトされていないウィンドウでは、タイムアウトがゼロ以外のタイマータスクを実行できます。

次の場合、1秒の整列したウェイクアップで:
タイマータスクのネストレベルが5未満、または、
ウィンドウは同一生成元ウィンドウであり、ネストレベルが5以上の最後のタイマータスクが同じツリー内の同一生成元ウィンドウで実行されてから少なくとも1分が経過しています。
それ以外の場合は、1分間の整列したウェイクアップで。

ネストレベルが5以上のタイマータスクは、タイマーアルゴリズムのステップ11が原因で、タイムアウトがゼロ以外になります(タイムアウト引数がゼロの場合でも)。

良くわからんが、後方にexampleも載っているので、ある条件下(5分間&ネストレベルが5以上??)での発動とかいう事なのかも。

まぁこれで「CPU使用率が最大1/5」にどう繋がるのかはよくわからんが、まぁまぁそういうことらしいので。

» no reactions

Chrome 87のタイマー

Chrome 87でバックグラウンドのタブのJavaScriptタイマーが1分置きにwake-upと聞いて、

<!DOCTYPE html>
<html lang="jp">
<head>
<meta charset="utf-8"/>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
var cnt=0;
setInterval(function(){
$('.test').replaceWith('<p class="test">' + cnt + '</p>');
cnt ++;
}, 500);
});
</script>
</head>
<body>
JavaScript::setInterval
<p class="test">スタート</p>
</body>
</html>

と書いてバックグラウンドのタグにしてみたが、普通に動いとる。

バージョン: 87.0.4280.66(Official Build) (64 ビット)

» no reactions

Chrome 87

Chromeブラウザがアップデートするそうな。

https://www.itmedia.co.jp/news/articles/2011/18/news088.html

開いているタブを把握し、その他のタブに掛かるリソースを制限することで、CPU使用率は最大で1/5まで下がるとしている。

とあるが、最大1/5 とはなんぞや。

複数のタブのリソース制限なのにタブ数に関係なく最大1/5で頭打ち・・・ってことは背後のタブのpriority(nice値)下げたってことだろうか?

Windowsの場合のスレッドプライオリティは

https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities

このあたりに書いてあるが、プライオリティ値が具体的にどの程度タイムスライス他に関係してくるのかはここからは定かでない。

が、まぁそんな感じなのかもしれない。

とりあえず軽くなるのは良いことで、これでWindowsにChromium入れるという面倒な作業をしなくても済む。

 

と言っている間に

https://www.gizmodo.jp/2020/11/google-chrome-update.html

Chromeの最新バージョンでは、アクティブなタブにパフォーマンスを集中。これによりCPU使用率は5倍改善され、バッテリーは旧バージョンより1.25時間長持ちするそうです。

いや5倍改善て違うでしょ。どうして自分表現に変えちゃうかなぁ。

と思ったらたぶん元のPCmagの記事が5xになっていた。ITmediaが1/5にしたのか。

https://www.pcmag.com/news/chrome-87-tamps-down-browser-tabs-cpu-usage-promises-pc-battery-life-boost#:~:text=To%20prevent%20the%20browser%20from,windows%20you%20currently%20have%20open.&text=%E2%80%9CThis%20reduces%20CPU%20usage%20by,our%20internal%20testing%E2%80%9D%20Chang%20said.

元々のGoogleの記事

https://blog.google/products/chrome/faster-chrome/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FMKuf+%28The+Keyword+%7C+Official+Google+Blog%29

これが

Chrome now prioritizes your active tabs vs. everything that’s open—reducing CPU usage by up to 5x and extending battery life by up to 1.25 hours (based on our internal benchmarks).

とすでにup to 5xなので最大5倍なのだろうが、上記をGoogle翻訳にかけると

Chromeは、開いているすべてのものよりもアクティブなタブを優先するようになりました。CPU使用率を最大5分の1に削減し、バッテリー寿命を最大1.25時間延長します(社内ベンチマークに基づく)。

となるので、まぁそういうことでいいのか。

CPU使用率の改善については

https://blog.chromium.org/2020/11/tab-throttling-and-more-performance.html

に書かれているように、

Timers represent >40% of the work in background tabs. Reducing their impact on CPU and power is important to make the browser more efficient. Beginning in M87, we’re throttling JavaScript timer wake-ups in background tabs to once per minute. This reduces CPU usage by up to 5x, and extends battery life up to 1.25 hours in our internal testing.

つまり背後のタブで動作するJavaScriptタイマーを1分に1度のウェイクアップとすることで、CPU使用率を最大1/5に減らしたという事のようだ。

だったらタブの数に比例してもよさそうなもので「最大5倍」になるのかなぁと疑問は残るが、まぁそういうことなのでしょう。探せばどっかにエビデンスがあるのだろうけれど。

というか、開発者にとってはバックグラウンドのJavaScriptタイマーが1分に1度のwake-upってのが気になるけれど。いろいろまずいの出てくるんじゃねーの?

» no reactions

pluckを使ってみる

ブログを入れるのにとにかく軽いものだったら何でも良いと思って

https://github.com/pluck-cms/pluck/wiki を入れてみた。

DBを使わないのでインストールも特段面倒ではなく、単に一式入れちゃうだけ。

で外から入れたURIのinstall.phpを呼ぶ。基本的にはそれだけでタイトルページができあがる。

ところが設定やファイル類はインストールしたディレクトリにできるのだが、ページを呼ぶ時は

ドメイン直下だったりディレクトリやaliasによっては変なURLを参照しやがる。

これは何と言うかホームURLの取得処理がもう怪しいので'PAGE_DIR'とか調べると

./data/inc/variables-all.php

にいろいろある。

//Site base directory (/var/www/pluck)
//define('SITE_DIR', str_replace('\\', '/', rtrim(realpath(rtrim(dirname(__FILE__), '/\\') . '/../..'), '/\\')));
define('SITE_DIR', 'pluckをインストールしたディレクトリ');
//Site base URL (/pluck)
//define('SITE_URL', str_replace('\\', '/', substr(SITE_DIR, strlen(rtrim(realpath($_SERVER['DOCUMENT_ROOT']), '/\\')))));
define('SITE_URL', '/blog');

としたところすんなり動くようになりましたと。

» no reactions

Pages: 1