Tag: performance

Home » Posts tagged "performance"

Amazon Aurora 支援 Parallel Query 加速

Amazon Aurora 推出了 Parallel Query，可以加速計算速度：「New – Parallel Query for Amazon Aurora」。原理是利用 Aurora 把 storage 層打散的前提，所以有機會透過螞蟻雄兵處理：

官方給的範例可以連到原文去看，可以看到有打開 aurora_pq 與沒打開的效能差異：

15 rows in set (1 min 53.36 sec)
15 rows in set (1 hour 25 min 51.89 sec)

打開後大約是原來的 1/45 時間，提昇超多...

不過還是有些限制，我最在意的就是目前只支援相容於 MySQL 5.6 的版本 (居然不是先支援 5.7)：

Engine Support – We are launching with support for MySQL 5.6, and are working on support for MySQL 5.7 and PostgreSQL.

然後沒有多餘費用，只是 i/o cost 可能會增加：

Cost – You can make use of Parallel Query at no extra charge. However, because it makes direct access to storage, there is a possibility that your IO cost will increase.

AWS, Cloud, Computer, Database, Murmuring, MySQL, Network, Programming, Service, SoftwareNo Comment

各家 Serverless 服務冷啟動 (Cold Start) 的時間

看到「Serverless: Cold Start War」這篇分析了 AWS Lambda、Azure Functions 與 Google Cloud Functions 的冷啟動特性。

裡面分析了多久沒有 request 會需要冷啟動、記憶體的大小對於冷啟動速度的影響、程式語言的影響，以及程式大小的影響。

對於量很少，但是又很在意速度的人來說也許可以研究一下。不過只要有點量 (就算一分鐘只有一次) 應該都不會遇到這塊問題...

AWS, Cloud, Computer, GCP, Murmuring, Network, Programming, ServiceNo Comment

用 Py-Spy 分析 Python 程式效率

這之後應該會變成 Python community 的神器之一...

剛剛看到分析 Python 程式效率的工具，只要有 pid 或是直接包著跑就可以分析：「Py-Spy: A sampling profiler for Python programs.」，執行起來長這樣：

而且還可以直接產生火焰圖讓開發者直接確認，超友善：

在 FAQ 的地方也有提到作者開發這套軟體的原因。有些在開發環境根本看不出問題的，可以很快的透過這個工具在 production 上看：

This project aims to let you profile and debug any running Python program, even if the program is serving production traffic.

另外一個重點在於其他常見的 profiling 工具通常都要改程式引用進來使用，這通常會使得程式效率慢下來，而 Pyflame 支援的平台比較少：

While there are many other python profiling projects, almost all of them require modifying the profiled program in some way. Usually, the profiling code runs inside of the target python process, which will slow down and change how the program operates. This means it's not generally safe to use these profilers for debugging issues in production services since they will usually have a noticeable impact on performance. The only other Python profiler that runs totally in a separate process is pyflame, which profiles remote python processes by using the ptrace system call. While pyflame is a great project, it doesn't support Python 3.7 yet and doesn't work on OSX or Windows.

Computer, Murmuring, Programming, SoftwareNo Comment

又一個 TCP BBR 的測試結果

TCP BBR 是 Google 發表的 TCP congestion control 演算法，是一個純伺服器端就能夠改善 TCP 壅塞處理的機制。在 Linux Kernel 4.9 之後被納入了。

而 Spotify 有大量資料要傳到使用者端 (像是音檔)，剛好是 TCP BBR 改善的對象之一，實際測試後得到了很不錯的改善數據：「Smoother Streaming with BBR」。

Spotify 公佈的資料沒有提到平台，所以先稍微了解一下他的音質，也就是「Audio settings」這篇。

在 Desktop 是 160kbps/320kbps Ogg (Standard/HQ)。在 Web Player 則是 128kbps/256kbps AAC (Standard/HQ)。

行動平台部份比較複雜，在 iOS 上是 96kbps/160kbps/256kbps Ogg (Normal/High/Extreme)，另外有 Automatic 自動調整的設定。在 Android 平台則是 24kbps HE-AACv2 (Low) 與 96kbps/160kbps/320kbps Ogg (Normal/High/Very high) 以及 Automatic。

而最後 Chromecast 則是 128kbps/256kbps (Standard/Premium)。

測試時可以發現 shutter (指跟不上播放速度) 的情況降低了 6%～10%，而且下載速度增加了 5%～7% (對於慢速的裝置改善更多，10%～15%)：

Taking daily averages, stutter decreased 6-10% for the BBR group. Bandwidth increased by 10-15% for the slower download cohorts, and by 5-7% for the median. There was no difference in latency between groups.

而各地區的差異也可以看出來改善很多：

另外他們在測試時，剛好遇到秘魯的機房連外發生問題，結果意外發現 BBR 還是可以穩定在這種網路環境下運作：

In Peru, the non-BBR group saw a 400-500% increase in stutter. In the BBR group, stutter only increased 30-50%.

In this scenario, the BBR group had 4x bandwidth for slower downloads (the 10th percentile), 2x higher median bandwidth, and 5x less stutter!

在 Ubuntu 18.04 上可以直接設定 BBR，在 Ubuntu 16.04 則可以參考「Ubuntu 16.04 用 speedtest-cli 測試 TCP BBR 效能」這篇的方式升級 kernel 後設定 BBR。

Computer, Linux, Murmuring, Network, OS, SoftwareNo Comment

Android 打算針對 Data Saver + 2G 網路的使用者關閉 JavaScript 功能

在「Chrome for Android may start disabling JavaScript on 2G connections」這邊看到的，引用的文章是 XDA 的「Google Chrome on Android to disable JavaScript automatically on 2G connections」。

在「Disable scripts for Data Saver users on slow connections」這邊可以看到 Android 的計畫，在打開 Data Saver 的情況下，Chrome 會停用 JavaScript，並且提示使用者：

If a Data Saver user is on a 2G-speed or slower network according to the NetInfo API, Chrome disables scripts and sends an intervention header on every resource request. Users are shown a UI at the bottom of the screen indicating the page has been modified to save data. Users can enable scripts on the page by tapping “Show original” in the UI.

在「Enabled NoScript Preview feature by default on Android」這邊可以看到對應的程式修改。

這樣反而可以少收到很多廣告耶，反倒希望是全域打開 XDDD

Browser, Computer, GoogleChrome, Murmuring, Network, Software, WWWNo Comment

Amazon S3 提供更高的存取量...

AWS 宣佈提高了 Amazon S3 的效能：「Amazon S3 Announces Increased Request Rate Performance」。

每個 S3 prefix 都可以到 5500 RPS read 與 3500 RPS write：

Amazon S3 now provides increased performance to support up to 3,500 requests per second to add data and 5,500 requests per second to retrieve data, which can save significant processing time for no additional charge. Each S3 prefix can support these request rates, making it simple to increase performance exponentially.

舊的資料可以看「Request Rate and Performance Considerations」這邊，裡面沒有明講速度，但有提到如果超過 800 RPS read 與 300 RPS write 的門檻，建議開 case：

However, if you expect a rapid increase in the request rate for a bucket to more than 300 PUT/LIST/DELETE requests per second or more than 800 GET requests per second, we recommend that you open a support case to prepare for the workload and avoid any temporary limits on your request rate.

不過如果有量的話，還是建議照著原來的 prefix 建議，打散處理會比較好，通常在前面的 CDN 通常可以跑簡單的 url rewrite 處理掉 (像是 CloudFront 自家或是 Cloudflare)，像是把使用 unix timestamp (ms) 的 https://www.example.com/1531843366123.jpg 變成 https://www.example.com/6123/1531843366123.jpg，這樣可以讓 Amazon S3 的後端依照 prefix 打散 loading，避免當站愈來愈大的時候很難處理。

AWS, Cloud, Computer, Murmuring, Network, ServiceNo Comment

Python 3.7.0 以及效能

這幾天 Python 3.7.0 出了，這應該是 3.x 版第一個在一般性綜合測試有機會比 Python 2.7 快的版本。這邊拿二月時有人用 3.7 的 beta 版測試結果來看：「Which is the fastest version of Python?」。其中第一個圖就是 Django 上 django_html (render) 的測試，Y 軸是時間，所以是愈低愈好：

其他的幾張可以看到不是完全被 Python 2.7 抓著打了，算是出頭天了 (???)，如果是用 pyenv 的人，把 pyenv 升級到新版後就可以安裝 3.7.0 了。

Computer, Murmuring, Programming, SoftwareNo Comment Computer, Database, Library, Murmuring, Programming, SoftwareNo Comment

GCP 的 f1-micro 的使用心得...

這幾天在弄備援跳板機，不想弄在日本 (latency)，所以就想到 Google Cloud Platform (GCP) 在台灣有機房，而 Compute Engine 有 f1-micro，類似 AWS 裡 EC2 提供的 t2.nano 的機器。而這兩天玩了玩，大概有些事情值得記錄起來。

CPU 相關的部份：

  • EC2 的 t2 系列可以透過 API 或是在 web console 看到 CPU credit 剩下多少，GCE 沒找到在哪邊可以看。
  • EC2 的 t2 系列在 CPU credit 用完後是變慢運行，除非你打開 T2 Unlimited 同意 AWS 多收錢。而 GCE 的則是沒得選，相當於一定要開 T2 Unlimited。
  • GCE 的 f1-micro 是 0.2 vCPU，但我在上面跑 Ubuntu 18.04，平常沒事就已經是 15% 左右。這數字比預期的高不少，還在找是什麼原因...

網路相關的部份：

  • 因為要用台灣的機房，網路的部份只有 Premium 等級可以選 (Standard 等級目前只在美國有)，也就是會先走 Google 佈建的網路再出去，所以流出的費用會隨著 destination 地區而有差異 (i.e. 封包送到美國與送到中國是不同計價)。
  • 但 Premium 等級實測品質真的很不一樣，到香港居然在 15ms 以下，以前在固網機房內沒看過這個數字...

其他的部份：

  • 硬碟空間方面，Standard provisioned space 比 EBS 的 gp2 便宜不少，而且還包括了 i/o 費用 (AWS 會另外收費)。
  • 連續使用就會有 discount 了，也可以 commit 買一年或是三年取得更深的 discount。而 AWS 則是得買 Reserved Instance 拿到 discount。

來看看一個月會有多少帳單產生吧...

Cloud, Computer, GCP, Murmuring, Network, Security2 Comments

MySQL 裡 performance_schema 對效能的影響

最近在弄 MySQL 的 perforemance_schema，開起來後發現效能影響沒有很大，跟印象中不太一樣... 找了一下文章發現 Percona 在 2017 年年初時有針對效能測試過：「Performance Schema Benchmarks: OLTP RW」。重點在這張圖：

圖上可以看到 Default 其實對效能的影響有限，另外文章也整理出來，有哪些設定對效能影響不會太大，可以考慮平常就開著：

Using Performance Schema with the default options, Memory, Metadata Locks and Statements instrumentation doesn’t have a great impact on read-write workload performance. You might notice slowdowns with Stages instrumentation after reaching 32 actively running parallel connections. The real performance killer is Waits instrumentation. And even with it on, you will start to notice a performance drop only after 10,000 transactions per second.

Computer, Database, Murmuring, MySQL, SoftwareNo Comment

Recent Comments

Archives

Blogroll