Home » Posts tagged "dynamic"

在 Linux 下引用 Windows 的 DLL 檔

作者為了在 Linux 下進行安全分析而弄出來的計畫:「Porting Windows Dynamic Link Libraries to Linux」。

作者對 Windows 的架構有不少抱怨 XDDD

Distributed, scalable fuzzing on Windows can be challenging and inefficient. This is especially true for endpoint security products, which use complex interconnected components that span across kernel and user space. This often requires spinning up an entire virtualized Windows environment to fuzz them or collect coverage data.

This is less of a problem on Linux, and I've found that porting components of Windows Antivirus products to Linux is often possible. This allows me to run the code I’m testing in minimal containers with very little overhead, and easily scale up testing.

This is just personal opinion, but I also think Linux has better tools. ¯\_(ツ)_/¯

而這個專案跟 WineHQ 完整模擬不一樣,這只是給 Linux 下原生的程式使用 Windows 下 DLL 內的功能:

This project does not replace Wine or Winelib.

Winelib is used to port Windows C++ projects to Linux, and Wine is intended to run full Windows applications. This project is intended to allow native Linux code to load simple Windows DLLs.

The closest analogy would be ndiswrapper but for userspace.

作者拿了 Windows Defender 當範例,示範在 Linux 下呼叫 Windows 的 DLL...

MySQL 8.0 對 4 bytes UTF-8 的效能改善

在「MySQL 8.0: When to use utf8mb3 over utf8mb4?」這邊提到了 MySQLutf8 以及 utf8mb4 的故事,以及在 MySQL 8.0 預期的效能提昇:

可以看到 Oracle 的團隊花了不少力氣提昇 utf8mb4 的效能。另外提到了在 5.7 的時候將 row format 的預設值轉成 DYNAMIC

MySQL 5.7 (2015) added some optimizations such as a variable length sort buffer, and also changed InnoDB’s default row format to DYNAMIC. This allows for indexes on VARCHAR(255) with utf8mb4; something that made migrations more difficult prior.

依照「14.11.3 DYNAMIC and COMPRESSED Row Formats」這邊的敘述,看起來 COMPRESSED 也應該支援一樣的特性,不過不確定... (因為通常不會完整 index 整個 VARCHAR(255),只會 index 某個 prefix length):

The COMPRESSED row format uses similar internal details for off-page storage as the DYNAMIC row format, with additional storage and performance considerations from the table and index data being compressed and using smaller page sizes.

CloudFront 支援將 Query String 內的特定 Key/Value 當作 Cache Key 的一部分

Amazon CloudFront 可以指定 query string 中的某個特定的 key/value 當做 cache key 的一部分了:「Announcing Query String Whitelisting for Amazon CloudFront」,對應的文件在「Configuring CloudFront to Cache Based on Query String Parameters」這邊可以查到。

先前只能針對選擇忽略掉整個 query string,或是把整個 query string 當作 cache key 的一部分,現在可以細部調整了。

最簡單的應用可以用在 css/js 的 asset 上,針對 v=\d+ 當作 cache key 的一部分,而其他的參數可以忽略,不過這好像沒什麼特別的意義。

目前想到比較有意義的應用是針對 dynamic content 多了一些籌碼可以用,像是 Slack 把整個網站放上 CloudFront 後,應該會有很多 API 是透過 query string 傳遞參數,而這次的改變讓 CloudFront 可以細部調整。

nginx 引入 Dynamic Module 架構

nginx 在 1.9.11 版引入了 Dynamic Module,能夠更方便的決定要掛哪些模組使用了:「Introducing Dynamic Modules in NGINX 1.9.11」。



也因此多了 load_module 功能可以用:

To load a module at runtime, include the new load_module directive in the main context, specifying the path to the shared object file for the module, enclosed in quotation marks. When you reload the configuration or restart NGINX, the module is loaded in. You can specify a path relative to the source directory, as in these examples, or a full path.

load_module "modules/ngx_http_geoip_module.so";
load_module "modules/ngx_stream_module.so";

CloudFlare 對 Brotli 的測試

之前有提過這件事情,由於 Firefox 已經支援 Brotli 了 (Google 推出 Brotli 無損壓縮法),所以 CloudFlare 的人整理了目前的效能比較:「Results of experimenting with Brotli for dynamic web content」。

主要還是 Brotli 拿了不少資源來換壓縮率,對於 static content 由於可以事先算好而大勝不少 (大約可以再榨出 15% 的壓縮率,從 zlib 9 的 27.7% 降到 brotli 10 的 23.3%):

The current state of Brotli gives us some mixed impressions. There is no yes/no answer to the question "Is Brotli better than gzip?". It definitely looks like a big win for static content compression, but on the web where the content is dynamic we also need to consider on-the-fly compression.

另外對於大檔案、網路速度不快的連線來說也頗有幫助,但對於 on-the-fly 的壓縮反而會比較慢。

Adobe Typekit 支援 CJK 字型

Adobe Typekit 宣佈支援 CJK 字型:「Announcing East Asian web font support and new font browsing tools for Japanese customers」。中文的公告在「正式公開東亞網頁字體支援以及日文客戶適用的全新字體瀏覽工具」這邊。

這也包括了網頁版的部份。對於 CJK 單一字型檔案過大的問題,與大家的解法也都一樣,取出對應的字組出來給使用者作為 workaround (稱為 Dynamic Subsetting):

會稱為這是 workaround 是因為當網路速度愈來愈之後,就會又變成最單純的直接整包下載...

Anyway,Adobe 這個新功能是一個大邁進,不過他用的 HTTPS (EdgeCast) 還沒支援 SPDY 或是 HTTP/2 啊... :/

Elasticsearch 1.2.0

由於 Elasticsearch 的想法與實做比起 Solr 吸引人,可以看到愈來愈多團體換過去...

而前幾天 Elasticsearch 的官方放出 1.2.0 與 1.1.2 的消息:「elasticsearch 1.2.0 and 1.1.2 released」。

1.2.0 最大的改變是強制使用 Java 7 了,也就是不能在 Ubuntu 12.04 下安裝 default-jre 了,變成要裝 openjdk-7-jre。(要注意,官方建議的是 Oracle 官方的 JDK,而非 OpenJDK)

如果是 Ubuntu 14.04 就沒這個問題。(因為 default-jre 會裝 Java 7)

另外一個大改變是,之前產生安全問題的 dynamic scripting 預設關掉了,也就是 CVE-2014-3120

目前我的進度只到看完 mapping,但還沒實際開始塞資料進去玩...

CloudFlare 的速度...

CloudFlare 是一種 CDN 服務,相較於其他 CDN 會被歸類到 AkamaiDynamic Site AcceleratorLimelight NetworksDynamic Site Platform,或是 EdgeCastApplication Delivery Network

這類型的 CDN 加速服務,如果用在完全沒有考慮最佳化的網站上,效果應該會很明顯。但如果拿到 WordPress 或是其他 open source 軟體上,反而會因為軟體已經做了不少處理,上了 CloudFlare 反而因為多了一層而變慢。

不過會變慢多少呢?有人跳下去測試寫報告了:「Cloudflare Showdown」,如果懶得看中間的數據,可以看最後的結論「Conclusion」。

如果用在已經最佳化過的網站上,用 CloudFlare 會慢不少,如果是 WordPress 及其他 open source 軟體,最好的情況是快一點點,但最差的情況會慢個幾倍... 作者下的結論是「不要用」。

跟預期差不多,動態資料的加速基本上是個商業包裝而已,真正需要加速還是得自己把可以 cache 的部份切割出來。