最近我進行了許多的insoler網站的最佳化與改善計畫。雖然整個改善計畫還沒有全部完成,因為已經變更了相當多的功能、項目,所以還是先在這裡說明一下,我做了哪些變更,以及變更的原因、理由。
首先,上次我提到的「終於解決了瀏覽相簿的MySQL查詢指令,幾乎超過1秒〜4.7秒以上的頭痛問題」雖然已經解決了,但其實還有一個關於「相簿」的問題,目前還沒辦法解決。那就是開啟insoler首頁,以及相簿首頁的時候,網頁的顯示速度會比較遲緩的問題,特別是開啟相簿首頁的速度常常比開啟insoler首頁還要更慢!
我在不同瀏覽器進行交互測試的時候,因為Google Chrome、Firefox其他瀏覽器並沒有登入相同的帳號,意外發現在沒有登入帳號的時候,如果做同樣的「開啟相簿首頁」與「開啟insoler首頁」的動作,會明顯的快速很多!特別是「開啟相簿首頁」的速度!
換句話說,「開啟相簿首頁」會因為有沒有登入帳號的關係,而影響網頁的顯示速度!為什麼會這樣?只能猜想大概是「使用者狀態列」太複雜,以及不使用的模組太多,所以導致「登入insoler時」網頁的顯示速度會很明顯的變得比「沒有登入insoler時」緩慢許多。
用文字很難說明網頁開啟速度的差異,所以我特別錄製了一個影片,請特別留意左上角網頁標籤上的「逆時針旋轉」的網頁載入圖示。旋轉次數越多,就表示網頁的顯示速度越慢。
你可以看到在登入insoler帳號以後,點選「首頁」、「照片」的顯示速度會比沒有登入以前緩慢許多,特別是「照片」的首頁顯示速度會比首頁更慢。目前只能猜想「照片」的首頁會一次預覽15張照片,首頁只有12張照片,所以「照片」的首頁的顯示速度會比首頁更慢一些。
當然,我在地下社群網站有測試過,就算減少「照片」的首頁的瀏覽照片張數,在登入insoler帳號以後,還是會很明顯的變得緩慢!
我花了很多時間,終於找到導致insoler網站首頁、相簿首頁顯示速度緩慢的另外一個兇手!就是這兩個MySQL指令:
SELECT COUNT(*) FROM `bx_photos_main` left JOIN `sys_albums_objects` ON `sys_albums_objects`.`id_object`=`bx_photos_main`.`ID` left JOIN `sys_albums` ON `sys_albums`.`ID`=`sys_albums_objects`.`id_album` left JOIN `Profiles` ON `Profiles`.`ID`=`bx_photos_main`.`Owner` WHERE 1 AND `bx_photos_main`.`Status` ='approved' AND `Profiles`.`Status` NOT IN('Rejected','Suspended') AND `sys_albums`.`AllowAlbumView` IN('3','4') AND `sys_albums`.`Status` ='active' AND `sys_albums`.`Type` ='bx_photos' AND `bx_photos_main`.`Featured` ='1'
SELECT COUNT(*) FROM `bx_photos_main` left JOIN `sys_albums_objects` ON `sys_albums_objects`.`id_object`=`bx_photos_main`.`ID` left JOIN `sys_albums` ON `sys_albums`.`ID`=`sys_albums_objects`.`id_album` left JOIN `Profiles` ON `Profiles`.`ID`=`bx_photos_main`.`Owner` WHERE 1 AND `bx_photos_main`.`Status` ='approved' AND `Profiles`.`Status` NOT IN('Rejected','Suspended') AND `sys_albums`.`AllowAlbumView` IN('3','4') AND `sys_albums`.`Status` ='active' AND `sys_albums`.`Type` ='bx_photos'
這兩個指令其實算是同一個指令,主要是用來計算照片頁面底下「分頁」功能的「頁數」。因為是非常複雜的MySQL指令,而且是搜尋整個相簿資料表,所以需要1.08秒、1.13秒左右的資料庫搜尋時間。如果可以把這個速度提高10倍、100倍,應該就可以解決insoler首頁與相簿首頁的顯示速度緩慢的問題!
但是,為什麼會很難找到執行速度緩慢的MySQL指令?不是只要搜尋整個海豚系統 .php 的「SELECT COUNT(*)」程式指令,或是「FROM `bx_photos_main`」之類的關鍵字,一定就可以找到?很不幸的,事情沒有這麼簡單!因為那麼複雜的MySQL指令,其實是由兩個function副程式產生出來的!你可以看到指定在$sqlQuery變數裡面除了「SELECT COUNT(*) FROM」指令以外,後面全部都是由其他陣列變數以及呼叫其他function副程式產生出來的!
function getCount ()
{
$aJoins = $this->getJoins(false);
$sqlQuery = "SELECT COUNT(*) FROM `{$this->aCurrent['table']}` {$aJoins['join']} " . $this->getRestriction() . " {$aJoins['groupBy']}";
return (int)db_value($sqlQuery);
}
/*
* Check restriction params and make condition part of query
* return $sqlWhere sql code of query for WHERE part
*/
function getRestriction ()
{
$sqlWhere = '';
if (isset($this->aCurrent['restriction'])) {
$aWhere[] = '1';
foreach ($this->aCurrent['restriction'] as $sKey => $aValue) {
$sqlCondition = '';
if (isset($aValue['operator']) && !empty($aValue['value'])) {
$sFieldTable = isset($aValue['table']) ? $aValue['table'] : $this->aCurrent['table'];
$sqlCondition = "`{$sFieldTable}`.`{$aValue['field']}` ";
if (!isset($aValue['no_quote_value']))
$aValue['value'] = process_db_input($aValue['value'], BX_TAGS_STRIP);
switch ($aValue['operator']) {
case 'against':
$aCond = isset($aValue['field']) && strlen($aValue['field']) > 0 ? $aValue['field'] : $this->aCurrent['searchFields'];
$sqlCondition = !empty($aCond) ? $this->getSearchFieldsCond($aCond, $aValue['value']) : "";
break;
case 'like':
$sqlCondition .= "LIKE '%" . $aValue['value'] . "%'";
break;
case 'in':
case 'not in':
$sValuesString = $this->getMultiValues($aValue['value']);
$sqlCondition .= strtoupper($aValue['operator']) . '('.$sValuesString.')';
break;
default:
$sqlCondition .= $aValue['operator'] . (isset($aValue['no_quote_value']) && $aValue['no_quote_value'] ? $aValue['value'] : "'" . $aValue['value'] . "'");
break;
}
}
if (strlen($sqlCondition) > 0)
$aWhere[] = $sqlCondition;
}
$sqlWhere .= "WHERE ". implode(' AND ', $aWhere);
}
return $sqlWhere;
}
用這麼複雜的function副程式來產生非常複雜的MySQL指令,虧BOONEX程式設計師想的出來!終於找到「需要花費1秒以上的SELECT資料庫查詢指令」,對我來說仍舊是一個頭N個大!這麼複雜的PHP程式碼,應該不會只用在「相簿」,很可能也同時使用在影片、聲音、檔案等其他模組,如果沒有正確的修改好,以後就會遇到影片、聲音、檔案等其他模組,會出現奇怪bug的問題。
一個頭N個大的問題,當然不可能短時間就能解決,還得花更多時間研究分析清楚function getRestriction的副程式行為,才能知道為什麼會產生那麼複雜的MySQL指令,才能想其他辦法,看看能不能簡化MySQL的SELECT指令。
因為網頁的顯示速度會受到「登入insoler帳號」的影響,所以推測可能是我安裝了太多模組,有許多模組到現在都完全沒有使用過,因此我移除了不使用的模組,比如Poll票選模組、Store購物、Payment、Membership、Chat+、Shoutbox聊天室、Events事件簿、Sites精選網站等。
在「登入insoler帳號」以後,網頁最底下的「使用者狀態與圖示列」的右邊會有許多圖示,因為我移除了「Store購物」模組,也會一併移除狀態列的「購物車」圖示。另外,使用者狀態列的最右邊會有一個「+」號圖示,其實那個圖示與「網站功能表」的功能相同,所以也一併移除。
在「使用者列」的左邊會有一個「使用者狀態」的圖示,這個也會與網頁右上角的使用者圖示重複。而且如果想要變更使用者目前的狀態,只要在登入insoler帳號以後,點選網頁右上角的使用者圖示,再點選「帳號」,然後點選網頁右邊的「狀態」就可以設定「線上」「離線」「忙碌中」等狀態。因為我已經移除「Chat+、Shoutbox聊天室」模組,所以「使用者狀態與圖示列」左邊的「使用者狀態」就變得不是很重要,而且想要設定的話,還是可以在自己的帳號裡面變更。
以前討論區與部落格的網址是使用「標題」來決定網址。如果「標題」是中文的話,就會是「中文網址」。如果「標題」是日文的話,就會是「日文網址」。通常這沒有太多的問題,但是我變更了網址的色彩。沒有點選過的網址連結,會使用「咖啡色」表示。點選過的網址,會變成「抹茶綠」的顏色。但是這樣的色彩設計,在Google Chrome、Firefox其他瀏覽器可以正常顯示,反而在Apple的Safari瀏覽器無法正常顯示!
我花了很多時間,終於證實這是因為Safari瀏覽器的「網址連結」的CSS的色彩功能不支援「中文網址」與「日文網址」,也就是「漢字網址」!也向Apple Bug回報這個問題點,但是經過漫長的時間等待,Apple並沒有修正這個問題,而且很顯然在目前的macOS 10.12.6最新版本都沒有修正,應該是不會修正這個問題。
當然,只是因為Safari瀏覽器的CSS不支援「漢字網址」不需要花很多時間變更討論區與部落格的網址,讓我決定變更討論區與部落格的網址格式,改成與相簿相同的「數字網址格式」,也就是「PHP的時間格式+4位數的微秒時間」。
變更討論區與部落格的網址格式,主要是為了提高「網頁開啟速度」!當然,也會因為改成「英文與數字網址格式」,也會與其他手機瀏覽器、SONY PS3、PS4、Wii、Wii U等瀏覽器,會有有更好的相容性。
例如討論區的這篇新聞:
蘋果60吋電視OLED螢幕配上金屬外殼窄邊框設計
新的網址是:
https://www.insoler.com/forum/topic/15029736815038.htm
這一篇部落格的文章的網址,也會變成這樣的格式:
https://www.insoler.com/blogs/entry/15030179986617.htm
網址改成「15030179986617」數字以後,在MySQL資料庫的欄位格式也可以改成「BIGINT」的大整數格式,在建立索引、搜尋文章、開啟網頁的時候,都會變得更快。
只是變更討論區與部落格的網址,並不是把網址直接改成「15029736815038」、「15030179986617」就行了!因為文章裡面還會有「站內連結」,也就是在insoler網站內,一篇討論區的文章連結到另外一篇insoelr討論區的文章。一篇部落格的文章連結到另外一篇insoelr部落格的文章。如果是「站外連結」,外部的網址是Apple、MSN、Yahoo... 都沒關係,只要該網址沒有被移除,文章裡面的外部連結網址都可以正常使用。
但是變更討論區與部落格的全部網址的話,文章裡面的「站內連結」就會出錯!所以還必須另外寫PHP程式+手動處理那些「站內連結」網址。雖然我寫了一個PHP程式來分析、處理「站內連結網址」,但因為MySQL的UTF-8不是標準的格式(標準是4個位元組,但是MySQL只使用3個位元組),在某些中文字或是日文漢字的時候,會發生找不到資料的錯誤!
所以光靠一個PHP程式來分析、處理「站內連結網址」的500多篇討論區、部落格文章(不是每一篇文章都有站內連結)還是會有30幾篇文章無法處理,使用mysql_query會發生找不到資料的問題,只好自己「手動處理」那些無法正常搜尋網址的30幾篇文章。雖然花了幾個小時才全部處理完畢,但至少以後的insoler不會因為討論區、部落格文章越來越多,將來會出現類似「瀏覽文章的MySQL查詢指令,幾乎超過1秒〜4.7秒以上的頭痛問題」。目前討論區總共有14682篇文章,雖然「寫PHP程式+手動處理」花了好幾天的時間才全部處理完成,但至少早一點處理還比較好。拖越久問題就會越棘手。
目前整個部落格文章只有427篇文章,但是每一篇文章的顯示速度都很明顯的比討論區文章還要緩慢許多!雖然我知道這個問題,但是2-3年長久以來一直找不到「問題點」!也就無法著手解決問題,就這樣膠著了很久。
直到前幾天,因為想要看看Apple有沒有釋出新的macOS版本更新,所以在防火牆開放Web Server網站伺服器,允許HTTP與HTTPS上網(也只有開放這兩個port,其他通訊協定仍舊全部封鎖。通常則是全面封鎖,不允許所有的網站伺服器主機上網),讓Mac mini主機連上Apple網站,確認有沒有版本更新元件?
在等待的時候,隨手點選一篇部落格文章,想不到竟然看到「一片空白」的網頁畫面!我以為網站出了問題,但是點選相簿的照片、討論區文章,都可以正常顯示,只有所有的部落格文章全部都是「一片空白」!完全無法顯示網頁!
打開Console的Apache2的error_log錯誤記錄,竟然看到PHP Fatal error嚴重PHP程式錯誤的訊息!造成PHP Fatal error嚴重錯誤的PHP程式會被強制中斷,也就不會產生任何網頁。我發現這裡面有一個關鍵字就是「getLocalesFacebook」!
PHP Fatal error: Uncaught exception 'Exception' with message 'String could not be parsed as XML' in /Library/WebServer/Documents/insoler/inc/classes/BxDolSocialSharing.php:110\nStack trace:\n#0 /Library/WebServer/Documents/insoler/inc/classes/BxDolSocialSharing.php(110): SimpleXMLElement->__construct('Not Found
_getLocalesFacebook()\n#2 /Library/WebServer/Documents/insoler/templates/base/scripts/BxBaseSocialSharing.php(34): BxDolSocialSharing->_getLocaleFacebook('ja')\n#3 /Library/WebServer/Documents/insoler/modules/boonex/blogs/classes/BxBlogsModule.php(1292): BxBaseSocialSharing->getCode('https://www.ins...', 'Splatoon\\xEF\\xBC\\x88\\xE3\\x82\\xB9\\xE3...', false)\n#4 /Library/WebServer/Documents/insoler/modules/boonex/blogs/classes/BxBlogsModule.php(68): BxBlogsModule->getPostSocialSharingBlock()\n#5 /Library/WebServer/Documents/insoler/inc/classes/BxDolPageView.php(399): BxDolBlogsPageView->getBlockCode_PostSocialSharing(574 in /Library/WebServer/Documents/insoler/inc/classes/BxDolSocialSharing.php on line 110, referer: https://www.insoler.com/blogs/home/
我用這個「getLocalesFacebook」關鍵字搜尋BOONEX網站,找到這篇文章:
雖然我有看過這篇文章,但是當時不知道這個問題會與「部落格」有關!直到我允許Web Server伺服器主機上網的時候,才會發生這個重大錯誤,導致無法顯示網頁!我在修正問題以前,試著關閉防火牆的HTTP、HTTPS的網路規則,禁止Mac mini主機上網,結果部落格網頁就可以正常顯示了!只是網頁開啟的速度緩慢!只要一打開防火牆的HTTP、HTTPS的port,就會看到一片空白的部落格網頁!
可說是非常神奇的錯誤!我按照AlexT的指示,下載FacebookLocales.xml檔案,放到指定的 /plugins/facebook-php-sdk/檔案夾,然後修改 /inc/classes/BxDolSocialSharing.php程式碼。原本107行的程式碼是:
$sXML = bx_file_get_contents ('http://www.facebook.com/translations/FacebookLocales.xml');
修改後的程式碼是:
$sXML = bx_file_get_contents (BX_DOL_URL_ROOT . 'plugins/facebook-php-sdk/FacebookLocales.xml');
我猜想原本的程式碼因為直接使用「http://www.facebook.com/」網址的關係,當Web Server的Mac mini主機試圖連上Facebook網站時,會因為HTTP被我封鎖導致Timeout逾時失敗,所以沒有發生嚴重的錯誤,只會導致部落格文章的開啟速度因為BxDolSocialSharing.php程式碼「試圖直接連上Facebook網站」的關係,雖然會導致逾時失敗,至少程式碼還可以正常執行。
但是如果開放HTTP的80網路埠,可以正常連上Facebook網站的話,反而會因為「FacebookLocales.xml」的問題,導致PHP程式碼產生重大錯誤,完全無法顯示網頁,就會變成一片空白的部落格網頁。
雖然我按照AlexT的指示修正好這個問題,但是只要再度關閉防火牆的HTTP、HTTPS網路埠,禁止連接Facebook網站以後,部落格文章還是會有Timeout逾時失敗,網頁開啟速度緩慢的老問題!
既然確定問題是出在BxDolSocialSharing.php程式碼試圖連上Facebook網站,乾脆就移除部落格的「社群網站分享」這個區塊的功能!反正insoler網站上沒有多少會員,也沒人會想要把insoler文章分享到Facebook等社群網站。直接瀏覽部落格文章時,文章底下的「社群網站分享」這個區塊,就能解決部落格文章顯示速度異常緩慢的問題!
在前面錄製的影片可以看到現在的部落格文章,可說是一點選就能立即開啟,文章的開啟速度非常的順暢!而且還可以繼續保持禁止Mac mini主機上網(不只是HTTP、HTTPS,而是所有的網路埠都全部禁止!)的安全性。
insoler使用的ImageMagick圖片處理模組(這是一個號稱指令列模式的Photoshop程式)是有點老舊的ImageMagick 6.9.6-2版。也利用一些時間,更新php55-imagick模組到最新的版本:
imagick module | enabled |
---|---|
imagick module version | 3.4.3 |
imagick classes | Imagick, ImagickDraw, ImagickPixel, ImagickPixelIterator, ImagickKernel |
Imagick compiled with ImageMagick version | ImageMagick 7.0.6-7 Q16 x86_64 2017-08-12 http://www.imagemagick.org |
Imagick using ImageMagick library version | ImageMagick 7.0.6-7 Q16 x86_64 2017-08-12 http://www.imagemagick.org |
ImageMagick copyright | © 1999-2017 ImageMagick Studio LLC |
ImageMagick release date | 2017-08-12 |
ImageMagick number of supported formats: | 219 |
你可以看到這是在前幾天「2017-08-12」才釋出的新版本。因為Web Server不允許上網的關係,所以更新php55-imagick模組需要依靠另外一台Mac mini伺服器主機,更新到最新的php55-imagick模組版本以後,再把所需的全部檔案copy到Web Server的Mac mini主機。雖然會比較麻煩,但是為了維持「網站的最高安全性」的關係,比較麻煩一點也沒關係,至少可以確保絕對沒有任何的駭客可以入侵insoler主機!
雖然表面上只是從「ImageMagick 6.9.6-2版」升級到最新的「ImageMagick 7.0.6-7版」而已,從6.9升級到7.0版,應該沒有太大的差異。但其實ImageMagick有許多問題,甚至還有很多安全性漏洞,所以幾乎是經常更新版本!常常改版!由於駭客無法入侵Mac mini的Web Server主機,所以我也就懶得更新ImageMagick版本。因為對我來說ImageMagick唯一的功能就是負責處理「照片縮圖」而已,把上傳的原始照片(如果是上傳RAW檔案,還必須先轉換成JPEG圖檔)透過ImageMagick縮小照片的圖片大小。
insoler網站一直是使用標準的macOS Server伺服器主機,除了在PHP加裝圖片處理模組php55-imagick以外,並沒有加裝其他的模組。這次也順便加裝PHP加速模組,實際測試看看insoler網頁的開啟速度會變得更快一點點?還是變得更慢?因為只要加裝更多的程式碼模組,就表示需要花更多的CPU處理時間,安裝php55-opcache可能不會跑的更快,相反的還可能會跑的更慢!
當然,實際的效果,不能用「理論上」或是「感覺上」來自欺欺人!必須實際的測試看看。所以我利用「ab」指令來測試看看:
ab -s 100 -c 2 -n 10 https://www.insoler.com/forum/
底下是安裝php55-opcache前的ApacheBench效能測試結果(就像其他的Benchmark程式,執行N次,沒有一次會得到相同的數字結果!):
ab -s 100 -c 2 -n 10 https://www.insoler.com/forum/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.insoler.com (be patient).....done
Server Software: Apache
Server Hostname: www.insoler.com
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Document Path: /forum/
Document Length: 64729 bytes
Concurrency Level: 2
Time taken for tests: 2.097 seconds
Complete requests: 10
Failed requests: 3
(Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Total transferred: 651593 bytes
HTML transferred: 647287 bytes
Requests per second: 4.77 [#/sec] (mean)
Time per request: 419.415 [ms] (mean)
Time per request: 209.707 [ms] (mean, across all concurrent requests)
Transfer rate: 303.43 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 211 218 8.3 217 240
Processing: 195 200 2.9 202 203
Waiting: 192 196 2.9 198 199
Total: 412 417 8.7 415 441
Percentage of the requests served within a certain time (ms)
50% 415
66% 416
75% 417
80% 419
90% 441
95% 441
98% 441
99% 441
100% 441 (longest request)
底下是安裝php55-opcache之後的ApacheBench效能測試結果:
ab -s 100 -c 2 -n 10 https://www.insoler.com/forum/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.insoler.com (be patient).....done
Server Software: Apache
Server Hostname: www.insoler.com
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Document Path: /forum/
Document Length: 64729 bytes
Concurrency Level: 2
Time taken for tests: 1.819 seconds
Complete requests: 10
Failed requests: 3
(Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Total transferred: 651609 bytes
HTML transferred: 647287 bytes
Requests per second: 5.50 [#/sec] (mean)
Time per request: 363.759 [ms] (mean)
Time per request: 181.880 [ms] (mean, across all concurrent requests)
Transfer rate: 349.87 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 209 218 10.7 214 246
Processing: 138 144 5.4 142 153
Waiting: 135 141 5.2 139 150
Total: 353 361 10.3 357 386
Percentage of the requests served within a certain time (ms)
50% 357
66% 366
75% 366
80% 369
90% 386
95% 386
98% 386
99% 386
100% 386 (longest request)
從數字來看,好像有更快一點點,但其實多執行幾次ab指令,也會看到更慢很多的執行結果!所以加裝php55-opcache可能會更快,也可能會更慢!並沒有看到突飛猛進的效能改善!關於php55-opcache會繼續觀察一段時間,看看CPU的使用量會變得更高?還是更低?如果CPU因此使用量變得更高,實際上網頁顯示速度也沒有更快許多,當然是移除php55-opcache會比較好。
在「終於解決了瀏覽相簿的MySQL查詢指令,幾乎超過1秒〜4.7秒以上的頭痛問題」這篇文章,我終於知道兩件事:
1. BOONEX原廠忘記在MySQL的相簿資料表,幫「照片URL網址」建立索引表。而且依照原本的設計「照片URL網址」是使用照片的檔案名稱,雖然我改成「PHP時間+4位數亂數」(現在改成PHP時間+4位數微秒時間)但仍舊是255長度的文字格式,所以把「照片URL網址」格式改成BIGINT的純數字格式,再加上索引,資料庫的搜尋速度就會快了許多,照片的瀏覽速度改善許多。
2. BOONEX原廠設計的SELECT的照片資料搜尋的MySQL指令太複雜,這也會導致MySQL Server運作繁忙,Mac mini的主機CPU常常異常繁忙,全部都是mysqld這個程序!我重新設計新的SELECT資料搜尋指令,也會改善許多搜尋速度。
不過,非常可笑的是,我自己設計的EXIF模組,我自己也忘記幫EXIF資料表建立索引!雖然忘記建立索引表,但因為照片編號原本就是沒有負數的INT整數的數字格式,比起長達255字串長度的URI網址,就算忘記建立索引,其實搜尋速度還是非常快,平均只需要0.001秒左右。因此就算在「終於解決了瀏覽相簿的MySQL查詢指令,幾乎超過1秒〜4.7秒以上的頭痛問題」之後,並不會覺得照片的瀏覽速度緩慢。現在建立好索引表之後,EXIF資料表的搜尋速度就更快了。
雖然進行了許多以上的改善工作,但是對我來說,至少還有2個工作項目需要完成。
雖然我錄製一個影片,可以證明在沒有登入insoler網站的時候,照片首頁的顯示速度,很明顯會變得輕快許多,甚至瀏覽器轉不到一圈就能載入整個網頁,但是只要登入insoler網站,就會突然變得緩慢一些。這個問題要如何解決?我現在還在想辦法中。可能要另外建立「快取專用資料表」讓照片資料的搜尋速度可以變得非常的快。
事實上,我在地下社群網站測試過,原本應該要從MySQL讀取的照片資料,故意改成array()陣列變數,這樣的話,就完全不需要讀取資料庫,就能顯示照片。但是照片首頁的載入速度,並不會因此有明顯的快速!因此,到底是哪一段程式碼或是MySQL資料庫指令導致insoler首頁與相簿首頁的顯示速度緩慢,還需要花更多時間追查「問題點」!
同樣的,在找不到「真正的問題點」以前,也同樣是束手無策,無法解決問題。
這個工作其實已經拖了2-3年以上!雖然程式碼完成了70%左右,但因為工作繁忙,insoler的問題必須優先解決,老舊的BNW網站的搬家問題,就先擱置,但還是會在明年,最晚後年以前就會完成。因為BNW網址到期以後,我就不會繼續購買這個網域,而會只維持insoler這個網域,所以會在BNW網域到期以前,還可以正常使用以前,必須完成BNW全網站的搬移工作。當然,這也是非常辛苦的苦工,沒有捷徑可走。