#在建立 Web 應用程式時，我們必須時刻注意的最重要的事情之一就是效能。
正如他們所說，效能是一項功能。
無論您是設計師、開發人員還是用戶，您都會直觀地知道這一點：在應用程式方面，我們討厭等待。當事情執行得不夠快，或者我們必須等待比我們認為應該等待的時間更長的時間時，我們會感到沮喪。
#為此，大多數現代 Web 開發框架都可以透過使用某些 API 來實現某種類型的緩存，而 WordPress（儘管是一個基礎）也不例外。
因此，當我們繼續討論為什麼WordPress 是作為Web 應用程式開發基礎的可行選擇時，我們將了解核心應用程式提供的API、它們的工作原理以及我們如何利用它們來發揮我們的優勢，以及如何透過額外的快取插件進一步提高效能。
簡而言之，快取很重要，因為它允許我們將經常檢索的資料儲存在記憶體中的某個位置，以便可以快速檢索。
當您從更大的範圍來看時，當多個用戶查看一個網站時，這一點變得越來越明顯。我的意思是，如果一個人（或極少數人）訪問一個網站，並且該網站將其資料儲存在資料庫中，那麼每次加載頁面時，都必須從該網站檢索該資訊。資料庫，插入頁面中，然後返回給使用者。
如果建立了一定層級的緩存，則不必頻繁地呼叫資料庫。相反，可以從記憶體中的某個區域提取訊息，從而加快檢索速度，從而加快頁面載入時間。
我們將在本文後面詳細介紹這方面的技術細節。
如果您已經使用 WordPress 很長時間，那麼您可能熟悉許多可用的快取外掛。
這些無疑是加速網站和/或 Web 應用程式速度的絕佳解決方案，但它確實提出了一個問題：如果可以使用外掛程式來執行此操作，那麼我們為什麼要擔心它？
當然，這是一個有效的問題，但插件只能自己完成這麼多工作。
開發人員可以以這樣的方式建立他們的應用程序，使它們不僅在沒有快取機制的情況下表現良好，而且還可以透過所述快取外掛程式得到極大的增強。
我的意思是，這些快取外掛程式會尋找主題和應用程式要儲存在某個位置的數據，如果我們可以在自己的工作上下文中以程式設計方式執行此操作，那麼這些外掛程式將產生更大的效果性能。
在了解了可用的 API 後，我們將在本文後面重新討論此主題，看看它們如何提高快取外掛程式的效能。
為了在應用程式中引入第一層緩存，我們需要利用 WordPress 的 Transients API。首先，請注意瞬態的官方定義是「僅存在很短時間的事物。」
如同食品法典中的定義：
[Transient API] 提供了一種簡單且標準化的方法，透過為其指定自訂名稱和時間範圍（在該時間範圍之後資料將過期並被刪除），將快取資料暫時儲存在資料庫中。
但這到底是什麼意思呢？畢竟，資料仍然儲存在資料庫中，那麼為什麼這比將資料儲存在任何其他資料庫表（例如 wp_options 表？）中更好呢？
一旦我們重新審視有關快取和外掛程式的討論，我們將更詳細地討論這個問題。
設定瞬態值實際上非常簡單，就像在選項表中儲存資料一樣。
具體來說，您需要一個唯一標識資料的鍵值，然後需要一個與該鍵關聯的值。您還需要一個過期時間（以秒為單位）來在刷新表之前將資料保留在表中。
假設我們希望將目前使用者的名稱儲存為網站上最後一個或最近活躍的使用者。我們可以利用 wp_get_current_user() 函數來做到這一點。
首先，我們將設定如下值：
set_transient( 'most_recent_user', wp_get_current_user()->user_login, 12 * HOUR_IN_SECONDS )
#在這裡，請注意以下幾點：
HOUR_IN_SECONDS 常數是 WordPress 3.5 中引入的。此處提供了完整的常數列表。 儘管這就是我們設定瞬態的方式，但這仍然無法解釋我們如何管理瞬態（如果瞬態不存在或已存在）。
我們將在本文後面詳細介紹這一點。
當涉及檢索瞬態時，它與檢索元資料或選項等內容非常相似。我的意思是，我們只需要知道檢索資訊的密鑰。
因此，為了與上面的範例保持一致，我們可以透過以下呼叫來檢索應用程式的最新使用者：
get_transient('most_recent_user');
這顯然會返回您儲存的任何類型的信息，或如果瞬態已過期（即已經過去超過12 小時），則該函數將返回FALSE 的布爾值.
這是要記住的關鍵，特別是當您嘗試讀取快取值，然後需要從另一個資料來源取得它們（如果它們在臨時儲存中不可用）時。
我們將在本文結束之前看一下執行此操作的完整範例。
最後，如果您需要刪除瞬態以將其完全刪除，或者在其定義的到期之前將其刪除以便將其替換為另一個值，那麼您只需使用以下函數：
delete_transient('most_recent_user');
#此外，如果臨時值刪除不成功，函數將傳回 FALSE；否則，它將傳回 FALSE。
在設定快取值的過期時間時，有多種方法可以讓設定值比音樂基本整數操作更容易。
例如，MINUTE_IN_SECONDS 比 60 更容易使用，尤其是在乘以分鐘、小時或天時。
從 WordPress 3.5 開始，核心應用程式中添加了幾個常數，使這些計算更易於閱讀。
即：
MINUTE_IN_SECONDSHOUR_IN_SECONDSDAY_IN_SECONDSWEEK_IN_SECONDSYEAR_IN_SECONDS更容易使用、閱讀和寫作，不是嗎？
此時，我認為重要的是要了解如何從在選項表中儲存值開始設定瞬態。
以下是我們執行此操作的順序：
wp_options 表中儲存一個選項。 然後，在程式碼的後半部分，我們將執行以下操作：
話雖如此，讓我們來看看：
$username = wp_get_current_user()->user_name;
add_option( 'most_recent_user', $username );
// Check to see if the value exists in the cache
if ( FALSE !== get_transient( 'most_recent_user' ) ) {
// If it does, we'll delete it...
if( delete_transient( 'most_recent_user' ) ) {
// ...and store the most recent user for a maximum of one minute
set_transient( 'most_recent_user', MINUTE_IN_SECONDS );
} else {
// The deletion was unsuccessful, so log the error
}
}
// Now try to read the value from the cache.
if ( FALSE !== ( $username = get_transient( 'most_recent_user' ) ) {
// Since it doesn't exist, then we'll read it from the option's table
$username = get_option( 'most_recent_user' );
// And then we'll update the cache
set_transient( 'most_recent_user', $username, MINUTE_IN_SECONDS );
}
請注意，這個範例並不完整- 它可以重構得更清晰一些，並且程式碼應該抽象化為與應用程式更相關的函數，但此程式碼的目的是展示如何處理條件邏輯、選項和瞬態。
現在，綜上所述，我們可以重新審視如何使用瞬態來提高插件效能的問題。
正如我們之前提到的：
在了解了可用的 API 後，我們將在本文後面重新討論此主題，以了解它們如何增強快取外掛的效能。
块引用>話雖如此，快取和 WordPress 資料庫與資料庫中資料的位置有關。
由於瞬態數據儲存在與其他數據不同的位置，因此插件（例如基於 memcached 的插件）將查找存儲瞬態數據的數據，然後將數據從該位置加載到內存中。
因此，當請求資料時，將從記憶體中檢索資料。如果資料不存在，則會從資料庫中檢索。
最重要的是，如果編程正確，當從快取中讀取資料失敗並從資料庫中檢索資料時，會將其插回快取中，以便下次檢索時將其插入到快取中。內存中可用。
最後，關於瞬態資訊需要注意的關鍵一點是它有一個有效期限。這意味著資料只會在資料庫的該區域中儲存特定的時間。
為此，我們需要考慮到這一點。這意味著每當我們想要檢索瞬態時，我們都需要確保它們存在。如果沒有，我們會將它們從所在位置拉出，然後將它們存放在正確的位置。
自訂查詢
至此，我們已經介紹了 WordPress 提供的許多與 Web 應用程式開發基礎相關的功能。
但是我們還有最後一個主要元件要介紹，那就是如何處理自訂查詢。
當然，有一些很棒的AP，因為它與運行專為WordPress 特定目的而設計的查詢相關，例如
WP_Query和WP_User_Query，但我們還將了解一些允許我們編寫的本機工具使用定義的WordPress 物件以及允許正確資料清理的方法對資料庫進行自訂查詢。但我們將在下一篇文章中介紹所有這些內容以及更多內容。
以上是WordPress Web應用開發指南：可用功能詳解（第7部分）：快取技術的詳細內容。更多資訊請關注PHP中文網其他相關文章！
