Your solutions is the important method in the next generation lawful interception.
Our country is in policy-making process now and our commander will present about these challenges and how to solve to our President.
cib 是 警政署1 l啊
(沉思)
不過它的使用模型分為 Push Model 跟 Pull Mode。
Pull Mode 是讓它去「聽（不是真的 listen，而是去 polling）」其他 resource 的 event 就是非同步的，應該不會太在呼有沒有啟動慢，不過看 aws 論壇有些抱怨是 throughput 不夠大，或有些 event 沒聽到（？）
現在練習在玩的是 Push Mode 是直接塞 event 給它，這就是同步的呼叫了，會等到它處理完才回來。以目前用 phantomjs 的感覺，就真的慢慢的。
不過，我預想的應用情境也是 Pull Mode 的，所以應該可以接受。像是我們會讓 content provider（片商！？）上片，它是一組檔案合起來成一部完整的內容，我可以看到新的檔上來後，再臨時判斷它有沒有「集滿一組」再做處理：簡單的由上傳區，移到該放的位置，或是出診斷訊息。告訴使用者「你馬幫幫忙，上個片缺東缺西的」或「你欺騙我的感情，明明片長 3 小時，內容只有 1 小時多」
如果考慮不呼叫外部的程式慢。它的 jvm 本身會保持活著一陣子，應該是還好哩
下面這個不含第 1 次啟動，call 外部程式 ps aux 的時間 100 ms
START RequestId: bfa611fa-26c6-11e5-b17e-e52ad05c62a9
[INPUT] {cmd=/bin/ps, args=[aux]}Jul 10, 2015 5:44:36 AM qty.aws.lambda.ApplicationExecutor <init>
INFO: [/bin/ps, aux]
RESULT: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
RESULT: 496 1 0.2 1.3 2426740 52136 ? Ssl 05:39 0:00 java -XX:MaxHeapSize=445645k -XX:MaxMetaspaceSize=52429k -XX:ReservedCodeCacheSize=26214k -XX:+UseSerialGC -Xshare:on -XX:-TieredCompilation lambdainternal.LambdaRTEntry
RESULT: 496 15 0.0 0.0 13560 1068 ? R 05:44 0:00 /bin/ps aux
END RequestId: bfa611fa-26c6-11e5-b17e-e52ad05c62a9
REPORT RequestId: bfa611fa-26c6-11e5-b17e-e52ad05c62a9 Duration: 21.40 ms Billed Duration: 100 ms Memory Size: 512 MB Max Memory Used: 78 MB
放久一點讓它被砍掉的話，含第 1 次啟動就到 500 ms，差異不算太大就是了
START RequestId: 0e07d9af-26cb-11e5-a5ca-510262c74bd7
[INPUT] {cmd=/bin/ps, args=[aux]}Jul 10, 2015 6:15:26 AM qty.aws.lambda.ApplicationExecutor <init>
INFO: [/bin/ps, aux]
RESULT: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
RESULT: 495 1 31.5 1.2 2227848 47788 ? Ssl 06:15 0:00 java -XX:MaxHeapSize=445645k -XX:MaxMetaspaceSize=52429k -XX:ReservedCodeCacheSize=26214k -XX:+UseSerialGC -Xshare:on -XX:-TieredCompilation lambdainternal.LambdaRTEntry
RESULT: 495 11 0.0 0.0 13556 1064 ? R 06:15 0:00 /bin/ps aux
END RequestId: 0e07d9af-26cb-11e5-a5ca-510262c74bd7
REPORT RequestId: 0e07d9af-26cb-11e5-a5ca-510262c74bd7 Duration: 492.38 ms Billed Duration: 500 ms Memory Size: 512 MB Max Memory Used: 33 MB
如果執行 whoami 會是個 sandbox user (看起來真的頗安全)
START RequestId: b60ab05d-269e-11e5-a8cd-1d9c095ef12f
[INPUT] {cmd=/usr/bin/whoami}Jul 10, 2015 12:58:01 AM qty.aws.lambda.ApplicationExecutor <init>
INFO: [/usr/bin/whoami]
RESULT: sbx_user1053
END RequestId: b60ab05d-269e-11e5-a8cd-1d9c095ef12f
REPORT RequestId: b60ab05d-269e-11e5-a8cd-1d9c095ef12f Duration: 1024.78 ms Billed Duration: 1100 ms Memory Size: 512 MB Max Memory Used: 37 MB
看內文的部署描述，大致就跟一般 linux 上要做的差不多。再加上 Windows 上使用的 Robocopy1、PowerShell Desired State Configuration2（也許有配合 Puppet Powershell DSC Module3 使用）
## 部署
- 每天 5 次部署，不去建立过大的应用。主要因为
- 可以直接的监视性能
- 尽可能最小化建立，可以工作才是重点
- 产品建立后再通过强大的脚本拷贝到各个网页层，
- 几乎所有部署都是通过 puppet 或 DSC，升级通常只是大幅度调整 RAID 阵列并通过 PXE boot 安装4，这样做非常快速。
每个服务器的步骤是：
- 通过 POST 通知 HAProxy 下架某台服务器
- 延迟 IIS 结束现有请求（大约 5 秒）
- 停止网站（通过同一个 PSSession 结束所有下游）
- Robocopy 文件
- 开启网站
- 通过另一个 POST 做 HAProxy Re-enable
aws 文件挺好的啊，主文的部分更新的蠻快的（以 html 版為準，其他格式慢是大家都知的），只是 Example 的部分看起來維護就比較少了，除非是跟著主文的部分一起被改動。
例如，使用 jets3t 做 cloudfront 的 signed url 範例1 還在教你如何使用 openssl 由 PEM 轉 DER 的方法，再餵給 jets3t
openssl pkcs8 -topk8 -nocrypt -in origin.pem -inform PEM -out new.der -outform DER
其實 jets3t 已經提供 EncryptionUtil2 處理這個問題。理想狀態是 aws java sdk 能自己提供這功能，當時沒有所以 俺先前整理筆記時3 也自己弄了一組 CloudFrontSignTool4。
剛剛進 github 實際找了一下 sdk 的 source code 看到它終於實作 CloudFrontUrlSigner5 ，在去年加進去的，但還沒寫進 Example 內。