https://github.com/fuel/core/wiki/Changelog-v1.6

見つからず。

http://fuelphp.jp/docs/1.6/requirements.html

5.3.2

 

https://github.com/fuel/core/wiki/Changelog-v1.7

http://fuelphp.jp/docs/1.7/requirements.html

5.5+とある。

 

https://github.com/fuel/core/wiki/Changelog-v1.8

PHP 7 とある。

また、一部5.6+と。

 

https://github.com/fuel/core/wiki/Changelog-v1.8.1

PHP7.1とある。

 

git log –graph –oneline –decorate=full –date=short –format=”%C(yellow)%h%C(reset) %C(magenta)[%ad]%C(reset)%C(auto)%d%C(reset) %s %C(cyan)@%an%C(reset)” remotes/origin/1.8/master

  • c7e7a4a [2018-04-27] (tag: refs/tags/1.8.1.3) hash_equals is php 5.6+, add compatibility layer @WanWizard

ここで、5.6対応も入っていたりする。

その前は、1.7時台。

  • 8e774d4 [2015-11-13] split off php 5.6+ code to avoid syntax errors in older versions; closes #1952 @WanWizard

 

https://github.com/fuel/core/commits/1.9/develop

7.2, 7.3が。

 

PHP5.6 Fuelphp1.8

 

色々調べると、GuzzleHttpがHTTPSで通信する際に増えるらしい

 

まとめ


  • AWS SDKのクライアント、GuzzleHttpも最終的にphpのcurl_~関数を呼んでいる
    ※constructorでcurlが無い場合、Exception吐くコードがあるし、AWSの要件にもcurlが入っている
  • php curl の nssは多分、ビルドされたcurlのNSSバージョンに依存してそう
    ※curl -V のNSS/3.27 の部分
  • curlをmakeすると、その時のOSのnssバージョンが組み込まれた
    curl 7.19.7 (x86_64-unknown-linux-gnu) libcurl/7.19.7 NSS/3.36
  • かつ、その際、nss-softokn-3.14.3-23.3.el6_8.x86_64 で、curlコマンドのNSS_SDB_USE_CACHE=yes は有効だった
  • phpのcurlバージョンは、コマンドと同じくlibcurlに依存してそうだが、curl_version(); 又は、phpinfo(); で確認できる

 

各種情報

AWS-SDKでSNSへpublishするテストコードを準備

実行前後の情報

dentunusedが増加し、dentryのslabが増加している。

buffers/cacheが減少している。

 

対策コードを追加

実行前後の情報

ほぼ増加しなくなったことがわかる。

nss-softokn-3.14.3-23.3.el6_8 の環境でも効果がありそうだ。

 

GuzzleHttp

コードを追っていくと、内部でphp curlを使っているようだ

curl と nss

NSS/3.27.1 が使われているようだ。

osにinstallされているnss-softknは使われていない?

curlをmakeして確かめてみる

同じバージョンをインストール

システムのnssが使われた事の確認と効果の確認

nss-softokn-3.14.3-23.3 で nss-softokn-3.14.3-23.3 が使えているだろうと思われる。

 

wget

 

epel

CentOS : EPEL リポジトリ追加

php5.5を入れるために

 

 

pip

CentOS 6 の python 2.6.6 に pip を導入する手順

 

aws cli

https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/awscli-install-linux.html

php5.5

 

php-xml

こんなエラーが出たので、

 

 

となったので、

 

と作成

とできた。

AWS SDKを使用しているとslabが肥大化していく現象

NSS_SDB_USE_CACHE=yesが利用できるのが、nss3.16以上とあるが、

nss-softokn-3.14.3-12.el6 という情報もあるため、確認

https://bugzilla.redhat.com/show_bug.cgi?id=1044666

http://tama1029hq.hatenablog.com/entry/2016/12/12/105353

 

Amazon Linux

この場合、NSS/3.21が有効なのだろうか。

 

→効いている。

 

さくら(CentOS release 6.6 (Final))

 

→再現しない

 

CentOS6.9(Amazonマーケットプレイス)

 

→効いている

 

 

 

普通にやると次のようなエラーが出てはまった

http://d.hatena.ne.jp/kadotanimitsuru/20090216/thread

あたりから辿り、

 

https://www.raspberrypi.org/forums/viewtopic.php?t=46096

で回避できた。

 

 

カード番号を合わせると録音できた。

失敗する

次のコマンドで失敗

次で入れる

次のように

マイクの音量が小さくなっている。

 

 

解説記事は色々流れているけど、実際に触ってみないと覚えないので。

歴史の整理

async / await は Promiseと関連している。まず、時系列を整理。

  • 昔の Node では Promise が独自実装されており。2010年頃 deprecate された、という話がある。
  • Node.js v0.11.13 より、ES2015/ES6 Promise が利用可能に
  • Node.js v7 より ES2017/ES7 async/await が利用可能に。

Promise

async / await を理解するにあたってはまずPromiseから。
例えば次のようなHTTPリクエストの非同期処理を考える。

 

この例では、★1まで処理が進行して関数を抜けてしまってから、★2が実行される。
node.js の イベントループモデルはそもそもがそういうものなのだけど、
やっぱり同期処理的に書いたり処理した方がいいよね、ということで可能にしたのがPromiseで、
次のように既存処理を括って書ける。

この場合、★1まで処理が進行した後、★2で応答を返すまで Promise が処理を返さない。
★2が実行されると、★3以降の処理が実行される、というもの。
ちなみに、上記の例で、呼び出し側は次のようになる。

 

async/await

async/awaitは、上記 Promise の呼び出しを簡略化して、
かつ、処理の流れ自体を同期化する仕組み。

async

async の簡単な説明、

  • async をつけた関数は、Promiseを返す
  • async function が return した場合、Promise は戻り値を resolve する。
  • async function が 例外等を throw した場合、Promise は、それを reject する。

要は、既存の関数をそのまま、同期処理に変えることができる。
しかし、ポイントがあって、あくまで「その関数」内の return / throw に作用するので、上記に示したような、ライブラリのコールバックには対応できない。(と思う)
なので、async で Promise 実装を簡潔化しよう、と思っても、Promise は残らざるを得ない。(はず)
※ async function って、「非同期で処理される関数です」じゃなくて、「非同期処理を含む関数(だけどPromiseで同期的に処理できる)です」ってことですね。ちょっと混乱した。

await

対して、await。

  • async function 内でしか使えない。
  • await を指定した関数の Promise が返却されるまで処理を待機する。

なので、await で同期的に待つ、という事をしたい場合は、その関数自身が async function である必要があり、
つまりは、Promise を返すことになり、つまりは、同期的に処理されうる関数になる。
なので、await で待つことを決めた時点で、その関数は同期的な関数になり、その関数が async function になることで、その上位の関数にも、同期関数になるかどうかの選択を与える、という連鎖が続く。
これが最上位まで続くと、そのコールスタック全てが同期的に処理されることが、言語的に保証される。
というものなんだな、という理解。
Promise を待つ場合、従来の then, catch が使えるので、await を使う必要は必ずしも無いが、処理を簡潔にさせる等の理由で使うという判断ができる。
上記の呼び出し例は、await を使うと、次のように書ける。

 

エラー処理のために、try – catch も、Promise 同様に then, catch を使うこともできるが、
catch を使った方が処理が簡潔に書ける。

 

async/await の伝搬

async function にすると、Promise が返されるので、呼び出し元では、await 等の Promise 的な処理を行う必要がある。なので、非同期処理が無いにも関わらず、async 化しておくのは無駄のように見える。
async/await モデルにおいては、async function にした時点で、呼び出し元には await を使うことになり、その関数も必然的に async function になるので、という連鎖が続くので、全てを async function にする必要が出てくる。
そうさせないためには、あえて、async function だけど同期的に処理されていることが保証されていて呼び出し元に伝搬させる必要がないから、await は用いず、Promise の処理を行って、async をつけない、ということを行う必要がある。
ということが正解なのかがよくわからない。

 

async/await を使った場合の、伝搬例

 

Lambda の Node.js

Node.js 8.10 ランタイムから、イベントハンドラ自体を async で記述できるようになっている。

 

https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/nodejs-prog-model-handler.html
なので、中の処理を同期的に書いてもいいよ、ということになっている。
async function では、await が使えるので、中で async function を定義して、コールしていくという作りにできる。