小試 PHP 5.6 vs PHP 7.0 vs PHP 7.1

最近想昇級到 PHP 7，本以為最新版的 PHP 7.1 會是最快的，但看到網路上的比較，發現最快的是 PHP 7.0。看來，是不用追最新的版本啊。下面，自己來做個小測試吧。

在 Gentoo 下，使用 elselect 來切換不同版本的 PHP，下面的指令為切換成 PHP 7.0
# eselect php set cli php7.0

使用 PHP 內附的 httpd server
 $ php -S 127.0.0.1:8080

使用 siege 來測試效能
$ siege -c 10 -r 10 -u http://127.0.0.1:8080/ntu-ocw/index.php/ocw/cou/104S113

網頁程式，是自己管的開放式課程 (NTU OCW)，使用 Laravel 5.1。

三者比較的結果，PHP 7.0 > PHP 7.1 > PHP 5.6，和網上看到的結果一致。

看起來有夠少的，可是測一下 index.html，卻也只有 Transaction rate: 14.27 trans/sec，實在是不可思議啊，是我不會用 siege?

補充說明

本文看看就好，我必須承認沒有什麼參考性。此網站使用 Laravel framework，受到 session 的影響很大，假如不啟動 session，是可以讓效能提升很多的。

PHP 7.1.1 的結果

Transactions:                 100 hits
Availability:              100.00 %
Elapsed time:               10.77 secs
Data transferred:            5.63 MB
Response time:                0.39 secs
Transaction rate:            9.29 trans/sec
Throughput:                0.52 MB/sec
Concurrency:                3.63
Successful transactions:         100
Failed transactions:               0
Longest transaction:            0.76
Shortest transaction:            0.09

PHP 7.0.15 的結果

Transactions:                 100 hits
Availability:              100.00 %
Elapsed time:                9.83 secs
Data transferred:            5.63 MB
Response time:                0.35 secs
Transaction rate:           10.17 trans/sec
Throughput:                0.57 MB/sec
Concurrency:                3.54
Successful transactions:         100
Failed transactions:               0
Longest transaction:            0.61
Shortest transaction:            0.08

PHP 5.6.29 的結果

Transactions:                 100 hits
Availability:              100.00 %
Elapsed time:               11.37 secs
Data transferred:            5.63 MB
Response time:                0.42 secs
Transaction rate:            8.80 trans/sec
Throughput:                0.50 MB/sec
Concurrency:                3.68
Successful transactions:         100
Failed transactions:               0
Longest transaction:            0.78
Shortest transaction:            0.10

正式網站 Apache 2.2.15 + PHP 5.4.42

Transactions:                 100 hits
Availability:              100.00 %
Elapsed time:                8.15 secs
Data transferred:            5.74 MB
Response time:                0.22 secs
Transaction rate:           12.27 trans/sec
Throughput:                0.70 MB/sec
Concurrency:                2.69
Successful transactions:         100
Failed transactions:               0
Longest transaction:            0.40
Shortest transaction:            0.15

nginx/1.10.2  +  PHP/7.0.14

Transactions:                 100 hits
Availability:              100.00 %
Elapsed time:                8.62 secs
Data transferred:            5.95 MB
Response time:                0.18 secs
Transaction rate:           11.60 trans/sec
Throughput:                0.69 MB/sec
Concurrency:                2.05
Successful transactions:         100
Failed transactions:               0
Longest transaction:            0.30
Shortest transaction:            0.13

ReiserFS 與 Gentoo

Benchmark
http://marc.info/?l=reiserfs-devel&m=121484256609180&w=2 ( 2008-06-30)

mkfs:
ext3-1: 0,02s user 0,99s system 6% cpu 14,816 total
ext3-2: 0,03s user 3,63s system 9% cpu 39,030 total
jfs-1: 0,00s user 0,04s system 11% cpu 0,337 total
jfs-2: 0,00s user 0,09s system 12% cpu 0,731 total
xfs-1; 0,00s user 0,01s system 2% cpu 0,322 total
xfs-2: 0,00s user 0,01s system 0% cpu 0,907 total
reiserfs-1: 0,01s user 0,04s system 0% cpu 10,455 total
reiserfs-2: 0,01s user 0,07s system 2% cpu 3,502 total
reiser4-1: 0,00s user 0,01s system 2% cpu 0,423 total
reiser4-2:0,01s user 0,02s system 1% cpu 2,619 total

disk usage
ext3: 48062440  22160100  23460864  49%
jfs: 48795072  22049220  26745852  46%
xfs: 48805696  21979288  26826408  46%
reiserfs: 48828008  21960572  26867436  45%
reiser4: 46397568  21190652  25206916  46%

create
ext3: 1,08s user 105,19s system 3% cpu 45:17,78 total
jfs: 0,79s user 64,93s system 6% cpu 16:14,70 total
xfs: 1,09s user 82,65s system 2% cpu 1:04:30,78 total
reiserfs: 1,12s user 183,73s system 7% cpu 41:17,34 total
reiser4: 0,88s user 123,96s system 15% cpu 13:04,77 total

copy
ext3: 1,09s user 114,32s system 3% cpu 50:15,30 total
jfs: 0,84s user 68,99s system 6% cpu 17:22,76 total
xfs: 1,10s user 90,33s system 3% cpu 40:03,23 total
reiserfs: 1,03s user 173,93s system 11% cpu 25:56,22 total
reiser4: 0,89s user 142,65s system 17% cpu 14:01,58 total

move
ext3: 0,00s user 0,01s system 4% cpu 0,218 total
jfs: 0,00s user 0,00s system 0% cpu 0,353 total
xfs: 0,00s user 0,01s system 2% cpu 0,540 total
reiserfs: 0,00s user 0,01s system 0% cpu 0,688 total
reiser4: 0,00s user 0,01s system 1% cpu 0,602 total

rem
ext3-1: 0,04s user 5,12s system 6% cpu 1:17,75 total
ext3-1: 0,04s user 5,74s system 4% cpu 2:05,16 total
jfs-1: 0,05s user 4,74s system 3% cpu 2:26,86 total
jfs-2: 0,05s user 4,55s system 3% cpu 2:27,94 total 
xfs-1: 0,04s user 10,76s system 1% cpu 12:13,20 total
xfs-2: 0,04s user 11,23s system 1% cpu 13:24,95 total
reiserfs-1: 0,04s user 16,59s system 30% cpu 53,700 total
reiserfs-2: 0,06s user 16,57s system 29% cpu 56,769 total
reiser4-1: 0,07s user 23,64s system 22% cpu 1:47,22 total
reiser4-2: 0,06s user 20,18s system 19% cpu 1:41,35 total

原測試者評語:
I was very surprised by jfs and xfs. The first was faster than expected (even with the unfairness in its favour) and xfs was much, much slower than expected. XFS was pretty fast with the films, but suffered a lot with the emails, while reiserfs and reiser4 dealt very well with the emails.

註: JFS 看起來，雖然不錯，但有crash的風險。ReiserFS 和 Reiser4 的優點，在於處理小檔案。但是 ReiserFS 不支援 SSD 的 discard 動作，而 Reiser4 沒有進 Linux 的 kernel，看起來，將來也不可能被採用。未來之星是 Btrfs。

結論，別再關注 ReiserFS，不值得的。

Reiser4 Gentoo FAQ
https://forums.gentoo.org/viewtopic-t-706171.html

Laravel 的 Implicit controller

從 CodeIgniter (CI) 開始使用 PHP 的 MVC framework，然後是 Laravel 3.1，只要建好 controller，就自動有連結可用。再跳到 Laravel 5.0，變成要在 route.php 裡宣告 Route::controllers()，這些都是所謂的 Implicit controller。

這個 Implicit controller，在 Laravel 5.2 時，變成 deprecated，在後面的版本，這個就會被取消。

為何要取消，心中有一些疑惑，也許有很多英文的討論吧，但沒能力看那些討論。但自己想偷懶，也沒有寫成符合 RESTful 的程式，非常想要 Implicit controller 的功能。後來，找到了這篇討論
https://laravel-china.org/topics/3614

有空再仔細看一下相關討論，思考一下該怎麼做。也許，開始時，會直接加上 Implicit controller 的作法吧，終究是偷懶的。

讓 Facebook 分享取得資訊的網頁設定

當使用者在 Facebook (FB) 分享連結時，FB 會依連結取得適當的資訊，如圖片、Title、簡介內容等。FB 有指定提供訊息的方式，假如網頁有提供對應的資訊，則會顯示該資訊。假如沒有提供這些資訊，則 FB 會自行判斷挑選，常常會挑到不具代表性的圖。

下面的連結是相關的討論
http://stackoverflow.com/questions/1138460/how-does-facebook-sharer-select-images-and-other-metadata-when-sharing-my-url

除錯的網站，需以 FB 帳號登入才可使用。
 https://developers.facebook.com/tools/debug

FB 需要下面的 metadata，假若找不到，則自行推導。

<head>
    <meta property="og:url" content="http://www.test.com/" />
    <meta property="og:title" content="Prepaid Phone Cards, low rates for International calls with Lucky Prepay" />
    <meta property="og:description" content="Cheap prepaid Phone Cards. Low rates for international calls anywhere in the world." />
    <meta property="og:image" content="http://www.test.com/img/fb-logo.png" />
   <meta property="og:image:width"  content="110" />
  <meta property="og:image:height" content="110" />
</head>

小測 Google 的雲端硬碟

實測 copy 4GB 的檔案
內部，NAS 複製到自己的電腦，時間 00:01:20，不到 1分半鐘。
再由自己的電腦上傳到 Google 的雲端硬碟，時間 00:01:21.68，也是不到 1分半鐘。
上傳到 Google 的雲端硬碟，僅慢了幾秒鐘。
因為是一手按滑鼠按鍵，一手點按手機，實際差多少，就不知道了。但也只能說，Google 大神，實在太恐怖了。

gcin-2.8.4 -- 對 QT5 的支援

在 Gentoo 的 overlay，只有 gcin-2.8.3 的 ebuild，還沒有 gcin-2.8.4 的 ebuild。就自行下載 2.8.3 的版本，直接改成 2.8.4 的版本。在上一篇，已處理了在 gtk 應用程式，輸入框一直黏在左上角的問題。

PS. 目前，已升級至 gcin-2.8.5，所以，此處的資訊，對於 gcin-2.8.4  可能都是沒用的了。

在 USE flag 包含 qt4 時，會編譯失敗，只要將 ebuild 中的 DEPEND，qt4 的部分改成
 qt4? ( dev-qt/qtcore:4 dev-qt/qtgui:4 )

另外，在 DEPEND，加上 qt5? ( dev-qt/qtcore:5 dev-qt/qtgui:5 )，以及在 IUSE 加上 qt5，即會多了 qt5 的 USE flag。
再來，要將 qt5-im/Makefile 中的 Qt5PlatformSupport 移除，以及將 qt5-im/gcin-qt5.h 中的 IID 版本，改成 org.qt-project.Qt.QPlatformInputContextFactoryInterface.5.1

在 Qt5PlatformSupport 移除後，在有 qt5 的 USE flag 之下，可以順利編譯，但仍無法在 QT5 應用程式中，如 kate，輸入中文。

在未修正 IID 時，使用 「qtplugininfo /usr/lib64/qt5/plugins/platforminputcontexts/libgcinplatforminputcontextplugin.so」 的指令，顯示下列結果
IID "org.qt-project.Qt.QPlatformInputContextFactoryInterface" Qt 5.6.2 (debug)
User Data: {
    "Keys": [
        "gcin"
    ]
}

依上述所講的，修正 IID 之後，使用 「qtplugininfo /usr/lib64/qt5/plugins/platforminputcontexts/libgcinplatforminputcontextplugin.so」 的指令，顯示下列結果

IID "org.qt-project.Qt.QPlatformInputContextFactoryInterface.5.1" Qt 5.6.2 (debug)
User Data: {
    "Keys": [
        "gcin"
    ]
}

安裝之後，重新登入，在 kate 下，即可切換中文和輸入中文了。

ebuild 測試步驟摘要

• 修改後，執行 ebuild gcin-2.8.5.ebuild digest，重新建立 Manifest
• ebuild gcin-2.8.5.ebuild clean，清除暫存檔
• ebuild gcin-2.8.5.ebuild prepare，執行 src_prepare() 的部分
• ebuild gcin-2.8.5.ebuild configure，執行 src_configure() 的部分
• ebuild gcin-2.8.5.ebuild compile，執行 src_compile() 的部分
• ebuild gcin-2.8.5.ebuild install，執行 src_install() 的部分
• ebuild gcin-2.8.5.ebuild qmerge，移除舊版本，安裝新的版本

參考連結
http://hyperrate.com/thread.php?tid=32359 
http://hyperrate.com/thread.php?tid=32406

http://hyperrate.com/thread.php?tid=32772#32772

2017 年 10 月

噢，gcc 升級後，gcin 在加上 qt5 的支援，又不行編譯了，出現
/usr/include/qt5/QtCore/qcompilerdetection.h:562:6: 錯誤：#error Qt requires a C++11 compiler and yours does not seem to be that.
 #    error Qt requires a C++11 compiler and yours does not seem to be that.
/usr/include/qt5/QtCore/qbasicatomic.h:61:4: 錯誤：#error "Qt requires C++11 support"
 #  error "Qt requires C++11 support"

這裡有一篇關於 C++11 support 的討論，只能有空再看了

The C++11 ABI incompatibility problem in Gentoo

現在只好在 kde 的應用程式下，不要用中文輸入啦
其他參考
https://forums.gentoo.org/viewtopic-t-1065532-start-0.html

2017-11-09 補記

QT 5 要求 C++11 support，而 gcc 預設是 C++98，因而在加上 qt5 的 use flag 時，gcin 無法成功安裝。因此，KDE 的應用程式，如 kate 也就無法輸入中文。找了一陣子的解答，忍受到今天，終於修改安裝成功。 

在發生編譯錯誤後，下指令測試
# cd /var/tmp/portage/app-i18n/gcin-2.8.5/work/gcin-2.8.5/qt5-im

加上 --std=c++11 的選項，可以成功編譯
gcc -g  --std=c++11 -O -I../im-client -I/usr/include/X11 `pkg-config Qt5Core Qt5Gui  QtDBus --cflags` -I`pkg-config --variable=includedir Qt5Gui`/QtGui/`pkg-config --modversion Qt5Gui`/QtGui -Wall -D_REENTRANT -DUNIX=1 -fPIC  -DQT5 -DQT_SHARED -DQT_IMMODULE -DPIC -DDEBUG="00" -MM *.cpp > .depend

改成 --std=c++98，出現 "Qt requires C++11 support" 的錯誤
gcc -g  --std=c++98 -O -I../im-client -I/usr/include/X11 `pkg-config Qt5Core Qt5Gui  QtDBus --cflags` -I`pkg-config --variable=includedir Qt5Gui`/QtGui/`pkg-config --modversion Qt5Gui`/QtGui -Wall -D_REENTRANT -DUNIX=1 -fPIC  -DQT5 -DQT_SHARED -DQT_IMMODULE -DPIC -DDEBUG="00" -MM *.cpp > .depend

修改  gcin-2.8.5.ebuild，在 src_prepare() 段落中，加入  append-cxxflags -std=c++11 並沒有用。只好直接用 sed 在 qt5-im/Makefile 的 CXXFLAGS 加上 --std=c++11 的選項。程式片段如下

    # Qt5 requires C++11 support
    if use qt5 ; then
        sed -i 's/CXXFLAGS=/&-std=c++11 /' \
                "${S}"/qt5-im/Makefile \
                || die 'sed failed'
    fi

升級 Qt 5.9.4 問題處理 (2018-03-24)

升級至 Qt 5.9.4 之後，gcin 又不能用了。重新安裝，在 compile 時，會出現找不到 qtguiglobal_p.h 和 qglobal_p.h 的錯誤。

compile 時，是用 pkg-config Qt5Core Qt5Gui  QtDBus --cflags 取得 include 的資訊，其取得的結果如下
-DQT_SHARED -I/usr/include/qt5/QtGui -I/usr/include/qt5 -I/usr/include/qt5/QtCore -I/usr/include/qt5 -I/usr/include/qt4 -I/usr/include/qt4/QtDBus -I/usr/include/qt4 -I/usr/include/qt4/QtXml -I/usr/include/qt4 -I/usr/include/qt4/QtCore

但實際上，這兩個檔是在這目錄下
$ find /usr/include -name qglobal_p.h
/usr/include/qt5/QtCore/5.9.4/QtCore/private/qglobal_p.h
$ find /usr/include -name qtguiglobal_p.h
/usr/include/qt5/QtGui/5.9.4/QtGui/private/qtguiglobal_p.h

因此，按上述手動執行各階段動作，在 compile 之前，修改 /gcin-2.8.5/qt5-im/Makefile，加上兩個 include 的目錄，成功安裝。

INCS=-I../im-client -I/usr/include/X11 `pkg-config Qt5Core Qt5Gui  QtDBus --cflags` -I/usr/include/qt5/QtGui/5.9.4 -I/usr/include/qt5/QtCore/5.9.4

不想改 ebuild 檔，也許，那天上游會作出修正。

升級 Gcin 2.8.6 (2018-06-16)

感謝 Edward Liu，升級到 Gcin 2.8.6，完全不需要做任何修改，即可安裝成功。

gcin 問題解決 -- 輸入窗黏在視窗左上解

蠻奇怪的，在家裡，輸入中文時，就是會黏在應用程式的左上角，而辦公室的是正常的。
歸納問題，這些程式都是 gtk+ 的程式。除了 Gnome 自己的應用程式，如 gedit 為 gtk3 的外，其他的都是 gtk2。

先收集辦公室的相關資料
設定檔 ~/.config/xfce4/xinitrc 的內容
#!/bin/sh
#
# Settings for gcin.
#
export LANG=zh_TW.UTF-8
export LC_ALL=zh_TW.UTF-8
export GTK_IM_MODULE=gcin
export XMODIFIERS="@im=gcin"
#exec gcin &

使用的是 gcin 2.8.4。

# lsof | grep -i immo
gedit     ....   /usr/lib64/gtk-3.0/3.0.0/immodules/im-xim.so  
xfce4-ter ....   /usr/lib64/gtk-2.0/immodules/im-gcin.so
leafpad   ....   /usr/lib64/gtk-2.0/immodules/im-gcin.so

從上面的列表，可以看到 gtk2 的應用程式，使用 im-gcin.so。而 gtk3 的應用程式 gedit，則是用 im-xim.so。

執行 gtk-query-immodules-3.0 --update-cache，會將  input method modules for GTK+ 寫入 libdir/gtk-3.0/3.0.0/immodules.cache，其中 libdir 為 /usr/lib64 及 /usr/lib。

例如 /usr/lib/gtk-3.0/3.0.0/immodules.cache 中，會有下列資料
"/usr/lib64/gtk-3.0/immodules/im-gcin.so" 
"gcin" "gcin Input Method" "gcin" "/usr/share/locale" "zh:ja" 

/usr/lib/gtk-2.0/2.10.0/immodules.cache 中，會有下列資料

"/usr/lib64/gtk-2.0/immodules/im-gcin.so" 

"gcin" "gcin Input Method" "gcin" "/usr/share/locale" "zh:ja" 

可以看到，gedit 已改成用 im-gcin.so。
gedit     ....   /gtk-3.0/immodules/im-gcin.so