常見搞爆系統的字串

Big List of Naughty Strings 是個測試用的列表,拿他來塞 input 看看系統會不會爆炸出現 500 之類的錯誤 XD

2015 年就有的專案,這幾天又上了 Hacker Newsreddit 於是又冒出來了...

Posted in Computer, Murmuring, Network, Programming, Security, WWW | Tagged , , , , , , | Leave a comment

EC2 的 r4 系列機器開出來了...

Amazon EC2 的 r4.* 總算是開出來了:「Amazon EC2 R4 instances are now available in new regions」。

Amazon EC2 R4 instances are now available in the following regions: Asia Pacific (Tokyo), Asia Pacific (Singapore), South America (São Paulo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Canada (Central), and EU (London).

r4.16xlarge (488GB) 算是補上中間的 r3.8xlarge (244GB) 與 x1.16xlarge (976GB) 中間的一塊洞了,不然之前得開 p2.8xlarge (488GB),但也不是每一區都有,而且用不到 GPU 就浪費了...

Posted in AWS, Cloud, Computer, Hardware, Murmuring, Network | Tagged , , , , , | Leave a comment

瀏覽器 UI 的死亡線

作者 Eric Lawrence 現在在 Google Chrome team 裡,寫了一篇文章講到瀏覽器上 UI 設計與安全性的問題:「The Line of Death」。

從一開始會假設紅線以上是可信任的:

後來有些操作跨過這條線 (左邊),於是就開始有很 tricky 的方法 (右邊):

甚至反過來利用 icon 讓使用者誤會是表示有訊息要通知使用者:

另外是直接惡搞,假裝是另外一個視窗:

最新的方法是利用 HTML5 的 Fullscreen API 直接搞定所有事情:

花樣愈來愈多了...

Posted in Browser, Computer, GoogleChrome, Murmuring, Network, Security, Software, WWW | Tagged , , , , , , , | 3 Comments

Facebook 機房內的 IPv6 架構

Facebook 在「Legacy support on IPv6-only infra」這邊提到機房內主要的流量幾乎都是 IPv6 了:

Today, 99 percent of our internal traffic is IPv6 and half of our clusters are IPv6-only.

不過只有一半的機器是 IPv6-only,這個比例看起來還有不少服務在 dual-stack 轉移階段... 然後從外部只有 15% 的流量是 IPv6:

Globally, however, only 15 percent of people who use Facebook have IPv6 support.

所以從外部連進來的時候必須轉換成 IPv6 資訊:

這張圖也解釋了 shiv 的角色,在 traceroute 的時候會看到他...

Posted in Computer, Murmuring, Network, Social, WWW | Tagged , , , , | Leave a comment

MyRocks 與 InnoDB 在 INSERT 效能的比較

MyRocksMark Callaghan 對 INSERT 效率整理出來的比較:「Insert benchmark, MyRocks and InnoDB」。

當資料比記憶體小的時候,InnoDB 效能比較好。但超過記憶體大小時就是 MyRocks 效能比較好。另外 InnoDB 在 MySQL 5.7 的效率比 5.6 好不少。

兩張圖來自相同資料,只是 x 軸不太一樣。

是從 16 台 client 裡面抽一台的量出來,這樣就可以解釋後面那段爬上來... (其他台跑完了,所以這台的 insert 速度變快了)

This is for data from one of the 16 clients rather than the global rate because my test script forgot to collect that.

While it is odd that the throughput rate for InnoDB 5.7 picks up at test end, that can occur if the thread I monitored ran longer than other threads and had less competition for HW resources near test end.

Posted in Computer, Database, Murmuring, MySQL, Software | Tagged , , , , , | Leave a comment

Swap 對 InnoDB 的影響

Percona 的老大拿 5.7 版做實驗,確認 swap 對 InnoDB 的影響:「The Impact of Swapping on MySQL Performance」。

測試的機器是 32GB RAM,作業系統 (以及 swap) 裝在已經有點年紀的 Intel 520 SSD 上,而 MySQL 則是裝在 Intel 750 NVMe 上。透過對 innodb_buffer_pool 的調整來看情況。

可以看到設為 24GB (記憶體 75% 的量) 時很穩定的在 44K QPS 與 3.5ms (95%):

This gives us about 44K QPS. The 95% query response time (reported by sysbench) is about 3.5ms.

而當設成 32GB 的時候開始可以觀察到 swap i/o,掉到 20K QPS 與 9ms (95%):

We can see that performance stabilizes after a bit at around 20K QPS, with some 380MB/sec disk IO and 125MB/sec swap IO. The 95% query response time has grown to around 9ms.

當拉到 48GB 的時候就更掉更多,6K QPS 與 35ms (95%):

Now we have around 6K QPS. Disk IO has dropped to 250MB/sec, and swap IO is up to 190MB/sec. The 95% query response time is around 35ms.

作者發現掉的比率沒有想像中大:

When I started, I expected severe performance drop even with very minor swapping. I surprised myself by getting swap activity to more than 100MB/sec, with performance “only” halved.

這邊測試用的是 SSD,如果是傳統用磁頭的硬碟,對 random access 應該會很敏感而掉更多:

This assumes your swap space is on an SSD, of course! SSDs handle random IO (which is what paging activity usually is) much better than HDDs.

基本上還是要避免碰到 swap 啦,另外 comment 的地方剛好有提到前陣子在猜測的 best practice,測試時的 vm.swappiness 是設成 1,這應該是作者的 best practice:

Swappiness was set to 1 in this case. I was not expecting this to cause significant impact as swapping is caused by genuine (intended) missconfiguration with more memory required than available.

Posted in Computer, Database, Hardware, Murmuring, MySQL, Software | Tagged , , , , , , , , , , , , , , , | Leave a comment

Google Cloud Platform 提供 Cloud Key Management Service

GCP 提供 Cloud Key Management Service (目前是 beta),將對 key 的處理 (像是加解密) 變成服務的一部分。

費用的部份,比較大的量應該會在「Key use operations (Encrypt/ Decrypt)」這塊?每一萬次收 USD$0.03。

自己建會有一堆稽核問題要處理,有人建起來後直接用,拔責任直接拆開的確是比較方便...

Posted in Cloud, Computer, Murmuring, Network, Security | Tagged , , , , , , , , , , , | Leave a comment

Amazon Aurora 支援 Auditing

AWS 的人把 auditing plugin 移植到 Amazon AuroraMySQL 環境上了:「Auditing an Amazon Aurora Cluster」。

官方宣稱的效能很好,打開後不會掉太多:

主要原因是把寫 auditing log 這塊改寫掉:

這樣看起來頗不錯,平常其實可以開起來讓他記錄?

Posted in AWS, Cloud, Computer, Database, MariaDB, Murmuring, MySQL, Network, Security, Software | Tagged , , , , , , , , , , , , , | Leave a comment

用人力就可以達到離心機的效果...

看到「This Human-Powered Paper Centrifuge Is Pure Genius」這個設計真的很巧妙... 全文刊登在 nature biomedical engineering 上:「Hand-powered ultralow-cost paper centrifuge」。

起源來自於小時候的玩具 (我也有印象,但忘記中文叫什麼了...):

Here, we report an ultralow-cost (20 cents), lightweight (2 g), human-powered paper centrifuge (which we name ‘paperfuge’) designed on the basis of a theoretical model inspired by the fundamental mechanics of an ancient whirligig (or buzzer toy; 3,300 BC).

研究後發現離心速度可以到 125000rpm:

The paperfuge achieves speeds of 125,000 r.p.m. (and equivalent centrifugal forces of 30,000 g), with theoretical limits predicting 1,000,000 r.p.m.

對於無法買昂貴醫療器材的地區,這樣就有簡單但又頗有效的離心機做檢驗...

Posted in Murmuring, Science, Social | Tagged , , , , , , , | Leave a comment

辦公室採用開放式空間的問題

這幾年對於開放式空間有不少反面意見出來,像是這幾天 BBC 登的「Why open offices are bad for us」。

這是目前的主流,大量的公司採用開放式空間:

Numerous companies have embraced the open office — about 70% of US offices are open concept — and by most accounts, very few have moved back into traditional spaces with offices and doors.

但人的效率會因為開放式空間大約掉 15%:

But research that we’re 15% less productive, we have immense trouble concentrating and we’re twice as likely to get sick in open working spaces, has contributed to a growing backlash against open offices.

採用開放式空間最常見的理由包括辦公室成本 (每個人平均分到的空間大小會比較低),另外一個是藉由開放式空間讓互相討論合作的成本降低,但因為開放式空間,反而是影響到別人的情況比討論合作的情況多,甚至是與工作無關的事情也會影響到期他人:

Beside the cheaper cost, one main argument for the open workspace is that it increases collaboration. However, it’s well documented that we rarely brainstorm brilliant ideas when we’re just shooting the breeze in a crowd. Instead, as many of us know, we’re more likely to hear about the Christmas gift a colleague is buying for a family member, or problems with your deskmate’s spouse.

其實科技的進步讓遠端溝通的成本降低了不少,像是 SlackZoom,現在未必要靠 open office 的架構讓大家溝通了。

Posted in Murmuring | Tagged , , , , , | Leave a comment