1. 程式人生 > >IIS6.0 效能優化

IIS6.0 效能優化

IIS 6.0 應用了新的程序模型。核心模式的HTTP偵聽程式(Http.sys)接收併發送HTTP請求(甚至可以使用它的響應快取來滿足請求)。工作程序註冊URL子空間,Http.sys將請求傳送到相應的程序(如果使用應用程式池,則傳送到程序集合)。

圖 4 展示了IIS 5.0和IIS 6.0程序模型之間的差異。IIS 5.0使用WinSock在埠80接受連線。請求由inetinfo程序負責接收,然後或者在程序內執行請求,或者將它交給dllhost程序在程序外進行處理(為了達到隔離的目的)。響應則由inetinfo程序傳送回去。

圖 4     IIS 5.0 和 IIS 6.0 的程序模型

IIS 6.0 程序依賴於核心模式的Web驅動程式Http.sys。在新的模型中,Http.sys負責管理連線和處理請求。請求可能通過Http.sys快取得到滿足,也可能被交給一個工作程序以便得到進一步處理(見圖5)。可以配置多個工作程序,從而以較低開銷實現了隔離。

Http.sys包括了一個響應快取。當請求與響應快取中的某個條目相匹配的時候,Http.sys直接從核心模式中傳送快取響應。圖5展示了請求通過Http.sys得到處理的情況(請求也可能向上交給某個工作程序進行處理)。

圖 5     IIS 6.0中的請求處理

由於Web伺服器既包括核心模式的元件,也包括使用者模式的元件,必須對二者同時進行調整才能獲得最佳效能。因此,針對特定負載的IIS 6.0調整工作需要對如下內容進行配置:

· Http.sys(核心模式驅動程式)以及相關的核心模式快取。

· 工作程序和使用者模式IIS,包括應用程式池配置。

此外,我們還將在後文中討論會對效能造成影響的其他引數。

核心模式的調整

與效能有關的Http.sys設定可以劃分為兩類:快取管理以及連線和請求管理。所有的登錄檔設定都儲存在以下條目中:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters

如果HTTP服務正在執行,必須首先停止服務,然後重新啟動計算機,以便讓設定生效。

快取管理設定

Http.sys具有的優點之一便是核心模式快取。如果響應位於核心快取中,那麼可能可以完全通過核心模式來滿足某個HTTP請求,這顯然可以極大降低CPU處理請求的開銷。但是,IIS 6.0的核心模式快取是一種基於實體記憶體的快取,每個條目都需要佔用一定的記憶體空間。

快取中的條目只有在被使用的時候才能提供益處。但是,條目在任何時候都會佔用實體記憶體,不論它是否被使用。所以,需要對快取某個專案帶來的益處(能夠直接從快取中滿足請求)以及它在整個生命期中的開銷(需要佔用實體記憶體)進行評估,並且考慮可用資源(CPU、實體記憶體)和工作負載的情況。Http.sys 試圖僅在快取中儲存有用(經常被訪問)的專案,但是,如果針對特定工作負載來調整Http.sys快取,Web伺服器的效能還可以獲得一定程度的提高。

以下是一些有用的Http.sys核心模式快取設定:

·UriEnableCache.預設值:1。設為非零值可以啟用核心模式響應和分段快取。對於大多數工作負載,快取都應該保持啟用。如果希望獲得超低響應和較低的快取利用率,那麼請考慮禁用快取。

·UriMaxCacheMegabyteCount.預設值:0。設為非零值可以指定核心快取可以使用的最大記憶體數量。預設值為0,允許系統自動調節快取能夠使用的記憶體數量。注意:只能設定可以使用的最大記憶體數量,而且系統可能不允許快取增長到指定的大小。

·UriMaxUriBytes.預設值:262144 位元組(256 KB)。本引數設定了核心快取中每個條目的最大長度。大於這個長度的響應或分段都不會被快取。如果有足夠的資金,可以考慮增加此引數的值。如果資金有限,而且大型的條目會擠掉較小的條目,那麼可以將本引數設為更小的值。

·UriScavengerPeriod.預設值:120秒。一個“清道夫”程式會定期掃描Http.sys快取,在兩次掃描期間沒有被訪問過的條目將被刪除。可以將掃描週期設定為一個較高的值,以減少掃描次數。但是,如果訪問頻率低的老條目仍然保留在快取中,快取佔用的記憶體將不斷增加。如果將此期限設定得過低,掃描頻率會過於頻繁,而且可能導致快取的過度清洗和擾動。

請求和連線管理設定

此外,Http.sys管理入站HTTP/HTTPS 連線,並且是在這些連線上處理請求的第一個層。它使用內部資料結構儲存有關連線和請求的資訊。雖然這樣的資料結構可以按需建立(或釋放),但如果在look-aside裡表中儲存部分資料結構留作備用,則可以實現更高的 CPU 效率。儲存這樣的儲備有助於Http.sys利用更少的CPU資源來處理負載波動。注意:負載波動不一定由外部的負載波動而引起。一些旨在改善批處理或者中斷調解的內部優化措施也可能導致負載波動和起伏。

儲備有助於減少CPU的使用率和縮短延遲時間,同時能夠增加Web伺服器的處理能力,但是也會增加記憶體的使用率。在調整Http.sys的請求和連線管理行為的時候,需要牢記的因素便是:可用的伺服器資源,效能目標以及工作負載的特性。您可以使用以下請求和連線管理設定:

·MaxConnections。本設定用來控制Http.sys所允許的併發連線的數量。每一個連線都會耗用非分頁池(一種寶貴和有限的資源)。預設值的設定相當保守,以限制連線佔用的非分頁池數量。對於配備了充足記憶體的專用Web伺服器,如果預計會產生大量的併發連線,可以將此值設定得更高一些。此值設定得越大,佔用的非分頁池就越多,所以要務必小心,應該使用一個與系統配置相適應的正確數值。

·IdleConnectionsHighMark、IdleConnectionsLowMark和IdleListTrimmerPeriod.這些值用來控制對非並行使用的連線結構的處理:在某個時間必須提供多少可用的連線(用於處理連線負載的波動)、釋放列表的上下界限、以及連線結構剪下和補充的頻率等。

·RequestBufferLookasideDepth和 InternalRequestLookasideDepth這些值控制與緩衝區管理有關的資料結構的處理工作,以及應該完成多少儲備以應付負載波動情況。

使用者模式設定IIS 登錄檔設定

以下注冊表設定可以在下面的條目下找到:

HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters\

·MaxCachedFileSize(REG_DWORD),以位元組為單位。決定了能夠被快取的檔案大小(預設為256 KB)。實際值根據資料表中最大檔案的數量和大小以及可用的RAM數量而定。對頻繁訪問的大型檔案進行快取可以降低CPU使用率,減少磁碟訪問以及相關的延遲時間。

·MemCacheSize(REG_DWORD),以MB為單位。將IIS使用者模式快取限制為指定的大小(預設設定為根據可用記憶體的數量由IIS調整快取的大小)。根據“熱門”檔案集合(頻繁訪問檔案的集合)的大小以及RAM數量或者IIS程序地址空間(正常情況下應該在2GB以下),需要認真選擇本引數的值。

·DisableMemoryCache(REG_DWORD)。如果設定為1(預設為0),則禁用使用者模式的IIS快取。在快取命中率非常小的時候,可以完全禁用快取,以避免與快取程式碼路徑有關的開銷。

·MaxPoolThreads(REG_DWORD)。設定每個處理器能建立的池執行緒的最大數量(預設為4,範圍不限。)每一個池執行緒都觀察網路請求,然後處理它們。MaxPoolThreads 計數沒有包括當前處理ISAPI應用程式的執行緒。如果CPU的平均使用率沒有處於最佳狀態,應該增加本引數的值,因為現有的所有執行緒都為繁忙狀態,沒有用於處理新請求的可用執行緒。

·PoolThreadLimit(REG_DWORD)。設定系統能建立的池執行緒的最大數量(預設值為處理器數量的4倍,範圍不限)。PoolThreadLimit 必須大於或等於MaxPoolThreads。正常情況下,PoolThreadLimit = MaxPoolThreads ´ 處理器數量。僅僅設定其中的一個引數是不夠的。如果同時指定了MaxPoolThreads 和PoolThreadLimit引數,則可以施加更嚴格的限制。

·ObjectCacheTTL(REG_DWORD),以秒為單位。控制沒有被訪問過的物件在IIS使用者模式快取中停留的時間長度(預設值為30秒,如設定為0xFFFFFFFF則禁用物件快取清道夫執行緒)。如果系統配備了足夠的記憶體,而且提交的內容不經常變化,那麼可以增加本引數的值。如果系統記憶體不足而且使用者模式快取的大小在不斷增長,則應該降低本引數。請參閱本節下面的 ActivityPeriod 部分。

·ActivityPeriod(REG_DWORD),以秒為單位。只有當檔案在活動期限(預設為10秒鐘,如果設為0則禁用本選項)內被重複命中,才允許快取檔案。本引數會降低由於快取不經常訪問的檔案而引起的快取開銷,如果快取內容變化不大,而且沒有足夠的可用記憶體,那麼可以增加活動期限的值;或者,如果快取上存在大量請求負載,可以降低活動期限的值。

·DataSetCacheSize(REG_DWORD)預設值為50。設定配置資料庫資料集快取中虛擬目錄條目的最大數量。如果已經安裝的虛擬目錄的數量超過了預設值,可以增加本引數的值。在提交靜態內容的時候,一個容量不足的資料集快取會增加延遲時間(更低的吞吐量和更低的CPU使用率)。

IIS Metabase

以下設定可以在 W3SVC/ 下找到。

·AspMaxDiskTemplateCacheFiles。啟用ASP指令碼模板的磁碟快取。ASP模板的編譯是一件非常耗費處理器資源的工作。記憶體大小限制了可以快取在記憶體中的模板的數量。從磁碟上的模板快取中取回編譯後的模板所需的開銷比編譯ASP記憶體快取中沒有的模板要小。請參見下文中的 AspScriptEngineCacheMax 一節。

·AspDiskTemplateCacheDirectory。如果可能,可以將其設定為不頻繁使用的磁碟(例如,沒有和作業系統、分頁檔案、IIS日誌或者其他頻繁訪問的內容共享的磁碟)。預設目錄是 “%windir%\system32\inetsrv\Template Disk cache\ASP Compiled Templates”。

·AspScriptEngineCacheMax。將其設定為記憶體容量所允許的最大的指令碼引擎數(預設為125)。

·AspScriptFileCacheSize。設定為記憶體容量所允許的最大的ASP模板數量(預設250)。請參閱前文中的AspMaxDiskTemplateCacheFiles一節。

·AspExecuteInMTA。如果在交付某些ASP內容時希望對出現的錯誤或故障進行檢測,請將本引數設定為1(啟用)。例如,如果需要託管多個站點,而且每個站點都執行在它自己的工作程序之下,那麼便可以啟用本引數。錯誤一般可以在事件檢視器中的COM+部分中看到。本設定啟用了ASP中的多執行緒單元模型(預設值為0,表示禁用)。

·AspProcessorThreadMax。如果當前設定(預設為25)不足以滿足負載的需求(可能會導致某些請求出現錯誤),可以增加本引數的值。

·CentralBinaryLoggingEnabled。通過將本引數設定為TRUE,可以啟用集中的二進位制日誌記錄。二進位制IIS日誌記錄可以減少對CPU的使用,降低佔用的磁碟空間以及減少磁碟I/O操作。集中的二進位制日誌可以被導向一個二進位制檔案,而無論託管站點的數量如何。分析二進位制格式的日誌需要一個後處理工具。

IIS 工作程序選項(IIS Admin UI、應用程式池屬性)

在沒有管理員干預、服務重啟或者計算機重啟的情況下,IIS管理介面上的IIS工作程序回收選項為發生的緊急故障或事件提供了有效的解決辦法。這樣的情況包括記憶體洩漏,洩漏會增加記憶體負擔,或者導致工作程序進入不響應或空閒狀態。在正常情況下,可能不需要啟用回收選項,所以可以關閉它(或者對系統進行配置,以很低的頻率執行回收工作)。在下面的章節中,黑體字名稱是per-app-pool(應用程式池)變數。在使用指令碼設定這些變數的時候,可以使用路徑“ /LM/W3SVC/AppPools/n”,在這裡n 代表應用程式池索引。

有三個選項,如下表所示:

·回收選項。可以在“回收”選項卡中找到。

·效能選項。可以在“效能”選項卡中找到。

·工作程序健康監視選項。可以在“健康”選項卡中找到。

表 8. 回收選項

引數

描述

PeriodicRestartRequests,DWORD,選項預設為禁用,預設值為35000

按照時間定期回收

PeriodicRestartRequests,DWORD,選項預設為禁用,預設值為35000

根據請求的(累計)數量定期回收

PeriodicRestartSchedule, MULTISZ,預設為禁用,預設為空字串值

在指定的時間進行回收

·     PeriodicRestartMemory, DWORD,預設值為512 MB

·    PeriodicRestartPrivateMemory, DWORD,預設值為192 MB

如果達到了以下兩個條件之一,基於記憶體的回收(預設為禁用)將允許回收工作程序:

·    虛擬記憶體的最大容量

·    已使用記憶體的最大容量

如果面臨不斷增長的記憶體容量壓力,可以其中一個引數或全部引數,基於嚴格的記憶體容量標準,頻繁回收工作程序,以緩解記憶體壓力。

表 9.效能選項

引數

描述

IdleTimeout,DWORD,以分鐘為單位,預設值為20

在程序的空閒時間超過指定的時間時,關閉工作程序。這樣可以節省有限的記憶體資源,但是如果CPU負載繁重,需要頻繁啟動新的工作程序,則不建議採取這種做法,因為建立程序會帶來一定的開銷。

AppPoolQueueLength,DWORD,預設值為2000

限制每個應用程式池(App-Pool)的核心請求佇列的長度。請求會消耗分頁池,在對分頁池具有大量需求的情況下,應該降低本引數的值。如果超過指定的長度,會導致伺服器拒絕請求,併產生編號為503的非自定義錯誤。

CpuAccounting,BOOLEAN,預設為禁用(0),啟用為1

監視CPU的使用情況。您可以按照百分比設定CPU的最大使用率(CpuLimit,DWORD,預設值為0)和監視工作的重新整理週期(CpuResetInterval,DWORD,預設值為0,以分鐘計)。如果達到了CPU的使用率限制,或者不採取任何操作(但是會在事件日誌中寫入一個事件),或者關閉工作程序(CPUAction,DWORD,預設值為0,表示“不採取任何操作”;最大值為1,表示“關閉工作程序”)。

MaxProcesses,預設:使用1個工作程序處理所有請求

可以在操作的Web Garden(Web園)模式中控制工作程序的總數量。在Web Garden模式中,幾個工作程序負責處理單個應用程式池下的請求負載。沒有通過不同的應用程式池為Web站點預先分配任何工作程序。在某些情況下,一個工作程序無法滿足負載的處理需要(可以通過糟糕的CPU使用率和漫長的響應時間看出這一點),增加工作程序的數量則有助於改善系統的吞吐量和CPU使用率。在託管了多個站點的情況下,可以考慮採用Web Garden模式。此外,在其中一個程序突然崩潰的情況下,採用多個工作程序還提供了更多可靠性,而且幾乎不會出現所有服務均中斷的情況。與預先分配應用程式池相比,Web Garden模式更容易設定和控制。

表10.健康選項

引數

描述

PingingEnabled,BOOLEAN, 預設值為1

PingInterval,DWORD,預設值為30秒

以固定時間間隔(PingInterval)Ping 工作程序(PingingEnabled)。如果沒有響應,則認為工作程序發生錯誤,IIS將試圖終止程序併產生一個新的程序。

RapidFailProtection,BOOLEAN,預設

RapidFailProtectionMaxCrashes, DWORD,預設為5個故障

RapidFailProtectionInterval, DWORD,預設為5分鐘

設定在給定的時間段內(RapidFailProtectionInterval)允許產生的最大故障數量(RapidFailProtectionMaxCrashes),對不斷快速產生故障的情況加以控制(RapidFailProtection)。如果到達了指定了故障率,應用程式池將被禁用,並且在事件日誌中寫入相關資訊。

StartupTimeLimit,DWORD,預設為90秒

控制工作程序的啟動時間,超過此時間,則認為其發生了故障。

ShutdownTimeLimit,DWORD,預設為90秒

控制工作程序的關閉時間,超過了此時間,則認為其處於不響應狀態。

安全套接字層的調整引數

安全套接字層(Secure Sockets Layer,SSL)的使用會加重CPU的負擔。SSL中最為耗費資源的部分為建立會話所需的開銷(包括一次完整的握手),然後是重新連線的開銷和加密/解密的開銷。為了獲得更好的SSL效能,請執行如下操作:

· 啟用SSL會話的“保持活動”(keep-alive)特性。這樣可以消除建立會話所需的開銷。

· 如果可能,重新使用會話(特別是對於那些沒有“保持活動”的流量)。

· 注意:金鑰越長,安全性就越高,但是需要的CPU時間就越多。

· 注意:並不是所有的頁面元件都需要加密。但是,混合的純文字HTTP和HTTPS可能會導致客戶端瀏覽器彈出一個警告,告知並不是所有的頁面內容都得到了保護。

ISAPI

對於ISAPI,沒有任何具體的調整引數。如果編寫一個私有的ISAPI擴充套件,請確保程式碼在執行和資源使用方面具有高效率。請參閱後文中的 影響IIS效能的其他問題。

託管程式碼調整引數

· 確信已經預先編譯了所有的指令碼。可以在每個目錄中呼叫一個.NET指令碼來完成這項工作。在編譯完成之後,需要復位IIS。在修改了Machine.config、 Web.config或任何.aspx指令碼之後需要重新編譯。

· 如果不需要會話狀態資訊,請確信在每個頁面中關閉了此專案。

· 當用戶在隔離模式(每個站點一個應用程式池)下執行包含ASP.NET指令碼的多個主機的時候,應該監視記憶體使用情況。請根據預計將要併發執行的應用程式池的數量,為IIS伺服器配備足夠的記憶體。考慮在存在多個隔離程序的地方使用多個應用程式域(app-domains)。

影響IIS效能的其他問題

·安裝沒有快取意識的過濾器。安裝沒有HTTP快取意識的過濾器會導致IIS禁用全部快取,從而造成效能急劇下降。老的ISAPI過濾器(在IIS 6.0之前編寫的過濾器)可能會存在這個問題。可以使用HTTP快取的過濾器在配置資料庫中被標記為“具有快取意識”的過濾器。

·CGI請求。出於效能的考慮,我們不建議使用CGI應用程式處理請求。由於需要頻繁建立(和刪除)CGI程序,會產生大量的系統開銷。更好的替代辦法是使用ISAPI程式和ASP(或ASP.NET)指令碼。這些方式都可以使用隔離。

NTFS 檔案系統設定

HKLM\System\CurrentControlSet\Control\FileSystem\ 下的NtfsDisableLastAccessUpdate(REG_DWORD)1。

通過禁止更新最後一次訪問的檔案或目錄的日期和時間戳記,這個針對整個系統的開關引數會降低磁碟I/O負載和縮短延遲。預設情況下本鍵不存在,因此需要額外新增。如果操作包含數千個目錄的大型資料集(或者大量主機),禁用更新的效果十分明顯。如果只需要保留資訊Web供Web管理使用,我們建議使用者使用IIS日誌代替它。

警告:某些應用程式(例如增量備份工具)需要使用這些更新資訊,如果沒有這些資訊,它們將無法正常工作。

相關推薦

IIS6.0 效能優化

IIS 6.0 應用了新的程序模型。核心模式的HTTP偵聽程式(Http.sys)接收併發送HTTP請求(甚至可以使用它的響應快取來滿足請求)。工作程序註冊URL子空間,Http.sys將請求傳送到相應的程序(如果使用應用程式池,則傳送到程序集合)。 圖 4 展示了IIS

Win2003 IIS6.0效能優化指南

問:好多asp.net程式,放在一臺伺服器上,客戶端連線使用一段時間後,在伺服器上開啟工作管理員一看,發現有很多w3wp.exe,佔用記憶體很大,達到1g,請問為什麼會這樣?有什麼辦法可以避免這種情況呢? 答:這主要是你的ASP.NET 開發的程式有記憶體洩漏;對於非託管

淺談webpack4.0 效能優化

原文連結:https://blog.csdn.net/yuanyang08/article/details/84324331 前言:在現實專案中,我們可能很少需要從頭開始去配置一個webpack 專案,特別是webpack4.0釋出以後,零配置啟動一個專案成為一種標配。正因為零配置的webpack對專

Spring Boot2.0效能優化

    1、JVM引數調優   針對執行效果  吞吐量    初始堆記憶體與最大堆儘量相同   減少垃圾回收次數  2、掃包優化: 啟動優化 預設Tomcat容器改為Undertow  To

效能優化 java 24 次閱讀 · 讀完需要 15 分鐘 0

摘要: 技術傳播的價值,不僅僅體現在通過商業化產品和開源專案來縮短我們構建應用的路徑,加速業務的上線速率,也會體現在優秀程式設計師在工作效率提升、產品效能優化和使用者體驗改善等小技巧方面的分享,以提高我們的工作能力。 技術傳播的價值,不僅僅體現在通過商業化產品和開源專案來縮短我們構建應用的路徑,加速業務的上

php8.0正式版新特性和效能優化學習

## 前言 > PHP團隊宣佈PHP8正式GA(連結)。php的發展又開啟了新的篇章,PHP8.0.0版本引入了一些重大變更及許多新特性和效能優化機制.火速學習下~ ## JIT(Just in Time Compiler) 即時編譯器 `JIT` 是一種編譯器策略,它將程式碼表述為一種中間狀態,在執行時將

在Windows Server 2003 的IIS6.0發布網站出現401錯誤

401錯誤在IIS 6.0 裏面 發布網站,瀏覽網頁的時出現 “您未被授權查看該頁” HTTP 錯誤 401.1 - 未經授權:訪問由於憑據無效被拒絕。猜想是匿名用戶沒有開放。 右擊 我的電腦—管理—本地用戶和組—找到IUSER_計算機名 這個用戶,右擊屬性 ,可以看到“帳號已禁用”被勾選,去掉勾即可。重

yii2.0如何優化路由

tac con tty enable gin 2.0 sym yml dex 比如我的路由是 http://localhost/basic/web/?r=site/index 現在想改成 http://localhost/basic/web/site/index 的

IIS6.0解析漏洞

執行 bsp 裏的 clas cer 默認 兩種 gpo iis6 IIS6.0解析漏洞分兩種 1、目錄解析 以*.asp命名的文件夾裏的文件都將會被當成ASP文件執行。 2、文件解析 *.asp;.jpg 像這種畸形文件名在“;”後面的直接被忽略,也就是說當成 *.a

js效能優化問題學習筆記

一:載入和執行 因為JavaScript是單執行緒的,具有阻塞性。當html頁面解析時,如果遇到<script>,那麼就會停止頁面的下載和解析過程,先將js指令碼執行完成,再開始下載,解析。注意:瀏覽器在遇到<body>標籤之前是不會渲染頁面的任何部分的。 1、將<scrip

菜鳥要做架構師——java效能優化之for迴圈

完成同樣的功能,用不同的程式碼來實現,效能上可能會有比較大的差別,所以對於一些效能敏感的模組來說,對程式碼進行一定的優化還是很有必要的。今天就來說一下java程式碼優化的事情,今天主要聊一下對於for(while等同理)迴圈的優化。 作為三大結構之一的迴圈,在我們編寫程式碼的時候會經常用到。

多層科目任意組合彙總報表的效能優化 (下)

2.4 有序計算方案 在充分利用遍歷一次的特點進行優化後,可能我們還會覺得計算效能有點慢,希望有進一步優化的空間。由於每次只需要取出總資料量的很小一部分 (100 個指標涉及的所有科目號大概幾百個,即在幾百萬記錄中取幾百條),這時我們通常能想到的是:如果能利用資料有序直接進行有序查詢(若源資料有序,可以

多層科目任意組合彙總報表的效能優化 (上)

一 問題背景 我們先來看一張資產負債表: 這是一個典型的中國式複雜報表格式,其複雜並不在於佈局,而在於其中“期末餘額”的每個單元格都是一個需要獨立計算的指標,互相之間幾乎沒有關係,事實上就是一個各種指標的彙總清單,而這些指標往往會有上百個之多。 在源資料表結構中,有一個欄位稱為科目,其

Android的效能優化

Android的效能優化 寫在前面: 公司給了我一週的時間去學習Android效能的優化,參考了張明雲老師的一片文章,並且用公司的實際專案進行測試(附有截圖),還進行了一些知識點,注意事項以及很多網址連結的補充,希望這篇博文能讓做效能測試的朋友們少走一些彎路。

python程式效能優化

最近工作中有個任務,就是優化一個模型的實時性。從有到無,主要完成了以下內容。 0.模型的邏輯 1.演算法邏輯 2.程式碼重構 3.程式的效能優化,包括編譯、多執行緒、多程序、numba 4.語言 numba包,經測試,比較適用於陣列、矩陣等數值計算,其他的型別操作,容易報錯。

Lighthouse前端效能優化測試工具

在前端開發中,對於自己開發的app或者web page效能的好壞,一直是讓前端開發很在意的話題。我們需要專業的網站測試工具,讓我們知道自己的網頁還有哪些需要更為優化的方面,我自己嘗試了一款工具:Lighthouse,感覺還不錯,記錄下來,也順便分享給用得著的夥伴。 Lighthouse分析web應用程式和w

效能優化之記憶體優化

效能優化之記憶體優化 計算 APP 獲得的最大記憶體分配值 Runtime rt=Runtime.getRuntime(); long maxMemory=rt.maxMemory(); Log.i("maxMemory:",Long.toString(max

Sql Sever效能優化之指定索引

背景:生產環境SQL語句查詢過慢(資料總量在350萬左右),日誌中心一直報警 解決過程:分析無果後,求助於公司的DBA,DBA分析後建議在語句中指定索引 解決:在SQL語句中指定索引,效果相當明顯,親測有效 優化前SQL: SELECT ROW_NUMBER() OVER ( ORDER BY

Android——效能優化之SparseArray

相信大家都用過HashMap用來存放鍵值對,最近在專案中使用HashMap的時候發現,有時候 IDE 會提示我這裡的HashMap可以用SparseArray或者SparseIntArray等等來代替。 SparseArray(稀疏陣列).它是Android內部特有的api,標準的jdk是沒有這

idea效能優化,使用小技巧

更多學習文章和資源請關注公眾號:Java程式設計指南 IDEA 配置優化,提高開發效率 去掉煩人的indent提示### 如何去掉呢? 開啟IDEA 的preferences|Editor|Code Style, 去掉下圖中的兩個勾選:   設定檔案的模板###