以目前的硬件條件,無論你怎么優(yōu)化,都不可能在生產(chǎn)環(huán)境中做到“每秒1000次的并發(fā)訪問”,除非你拿來做測(cè)試的是只有幾條數(shù)據(jù)的表和最簡(jiǎn)單的查詢。 如果你完全不懂負(fù)載平衡,讀寫分離,群集這些概念的話。
在臺(tái)江等地區(qū),都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局,加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力,以專注、極致的服務(wù)理念,為客戶提供成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營(yíng)銷網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作按需定制設(shè)計(jì),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,網(wǎng)絡(luò)營(yíng)銷推廣,成都外貿(mào)網(wǎng)站建設(shè),臺(tái)江網(wǎng)站建設(shè)費(fèi)用合理。
如何實(shí)時(shí)查看mysql當(dāng)前連接數(shù)? 1、查看當(dāng)前所有連接的詳細(xì)資料: ./mysqladmin -uadmin -p -h10.140.1.1 processlist 2、只查看當(dāng)前連接數(shù)(Threads就是連接數(shù).): ./mysqladmin -uadmin -p -h10.140.1.1 status 、查看當(dāng)前所有連接的詳細(xì)資料: mys...
測(cè)試何種指標(biāo)
在開始執(zhí)行甚至是在設(shè)計(jì)基準(zhǔn)測(cè)試之前 需要先明確測(cè)試的目標(biāo) 測(cè)試目標(biāo)決定了選擇什么樣的測(cè)試工具和技術(shù) 以獲得精確而有意義的測(cè)試結(jié)果 可以將測(cè)試目標(biāo)細(xì)化為一系列的問題 比如 這種CPU 是否比另外一種要快? 或 新索引是否比當(dāng)前索引性能更好?
有時(shí)候需要用不同的方法測(cè)試不同的指標(biāo) 比如 針對(duì)延遲(latency)和吞吐量(throughput)就需要采用不同的測(cè)試方法
請(qǐng)考慮以下指標(biāo) 看看如何滿足測(cè)試的需求
吞吐量
吞吐量指的是單位時(shí)間內(nèi)的事務(wù)處理數(shù) 這一直是經(jīng)典的數(shù)據(jù)庫(kù)應(yīng)用測(cè)試指標(biāo) 一些標(biāo)準(zhǔn)的基準(zhǔn)測(cè)試被廣泛地引用 如TPC C(參考// tpc ) 而且很多數(shù)據(jù)庫(kù)廠商都努力爭(zhēng)取在這些測(cè)試中取得好成績(jī) 這類基準(zhǔn)測(cè)試主要針對(duì)在線事務(wù)處理(OLTP)的吞吐量 非常適用于多用戶的交互式應(yīng)用 常用的測(cè)試單位是每秒事務(wù)數(shù)(TPS) 有些也采用每分鐘事務(wù)數(shù)(TPM)
響應(yīng)時(shí)間或者延遲
這個(gè)指標(biāo)用于測(cè)試任務(wù)所需的整體時(shí)間 根據(jù)具體的應(yīng)用 測(cè)試的時(shí)間單位可能是微秒 毫秒 秒或者分鐘 根據(jù)不同的時(shí)間單位可以計(jì)算出平均響應(yīng)時(shí)間 最小響應(yīng)時(shí)間 最大響應(yīng)時(shí)間和所占百分比 最大響應(yīng)時(shí)間通常意義不大 因?yàn)闇y(cè)試時(shí)間越長(zhǎng) 最大響應(yīng)時(shí)間也可能越大 而且其結(jié)果通常不可重復(fù) 每次測(cè)試都可能得到不同的最大響應(yīng)時(shí)間 因此 通??梢允褂冒俜直软憫?yīng)時(shí)間(percentile responsetime)來替代最大響應(yīng)時(shí)間 例如 如果 % 的響應(yīng)時(shí)間都是 毫秒 則表示任務(wù)在 % 的時(shí)間段內(nèi)都可以在 毫秒之內(nèi)完成
使用圖表有助于理解測(cè)試結(jié)果 可以將測(cè)試結(jié)果繪制成折線圖(比如平均值折線或者 % 百分比折線)或者散點(diǎn)圖 直觀地表現(xiàn)數(shù)據(jù)結(jié)果集的分布情況 通過這些圖可以發(fā)現(xiàn)長(zhǎng)時(shí)間測(cè)試的趨勢(shì) 本章后面將更詳細(xì)地討論這一點(diǎn)
并發(fā)性
并發(fā)性是一個(gè)非常重要又經(jīng)常被誤解和誤用的指標(biāo) 例如 它經(jīng)常被表示成多少用戶在同一時(shí)間瀏覽一個(gè)Web 站點(diǎn) 經(jīng)常使用的指標(biāo)是有多少個(gè)會(huì)話注 然而 HTTP協(xié)議是無狀態(tài)的 大多數(shù)用戶只是簡(jiǎn)單地讀取瀏覽器上顯示的信息 這并不等同于Web 服務(wù)器的并發(fā)性 而且 Web 服務(wù)器的并發(fā)性也不等同于數(shù)據(jù)庫(kù)的并發(fā)性 而僅僅只表示會(huì)話存儲(chǔ)機(jī)制可以處理多少數(shù)據(jù)的能力 Web 服務(wù)器的并發(fā)性更準(zhǔn)確的度量指標(biāo) 應(yīng)該是在任意時(shí)間有多少同時(shí)發(fā)生的并發(fā)請(qǐng)求
在應(yīng)用的不同環(huán)節(jié)都可以測(cè)量相應(yīng)的并發(fā)性 Web 服務(wù)器的高并發(fā) 一般也會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的高并發(fā) 但服務(wù)器采用的語言和工具集對(duì)此都會(huì)有影響 注意不要將創(chuàng)建數(shù)據(jù)庫(kù)連接和并發(fā)性搞混淆 一個(gè)設(shè)計(jì)良好的應(yīng)用 同時(shí)可以打開成百上千個(gè)MySQL 數(shù)據(jù)庫(kù)服務(wù)器連接 但可能同時(shí)只有少數(shù)連接在執(zhí)行查詢 所以說 一個(gè)Web 站點(diǎn) 同時(shí)有 個(gè)用戶 訪問 卻可能只有 ~ 個(gè)并發(fā)請(qǐng)求到MySQL 數(shù)據(jù)庫(kù)
換句話說 并發(fā)性基準(zhǔn)測(cè)試需要關(guān)注的是正在工作中的并發(fā)操作 或者是同時(shí)工作中的線程數(shù)或者連接數(shù) 當(dāng)并發(fā)性增加時(shí) 需要測(cè)量吞吐量是否下降 響應(yīng)時(shí)間是否變長(zhǎng) 如果是這樣 應(yīng)用可能就無法處理峰值壓力
并發(fā)性的測(cè)量完全不同于響應(yīng)時(shí)間和吞吐量 它不像是一個(gè)結(jié)果 而更像是設(shè)置基準(zhǔn)測(cè)試的一種屬性 并發(fā)性測(cè)試通常不是為了測(cè)試應(yīng)用能達(dá)到的并發(fā)度 而是為了測(cè)試應(yīng)用在不同并發(fā)下的性能 當(dāng)然 數(shù)據(jù)庫(kù)的并發(fā)性還是需要測(cè)量的 可以通過sy *** ench 指定 或者 個(gè)線程的測(cè)試 然后在測(cè)試期間記錄MySQL 數(shù)據(jù)庫(kù)的Threads_running 狀態(tài)值 在第 章將討論這個(gè)指標(biāo)對(duì)容量規(guī)劃的影響
可擴(kuò)展性
在系統(tǒng)的業(yè)務(wù)壓力可能發(fā)生變化的情況下 測(cè)試可擴(kuò)展性就非常必要了 第 章將更進(jìn)一步討論可擴(kuò)展性的話題 簡(jiǎn)單地說 可擴(kuò)展性指的是 給系統(tǒng)增加一倍的工作 在理想情況下就能獲得兩倍的結(jié)果(即吞吐量增加一倍) 或者說 給系統(tǒng)增加一倍的資源(比如兩倍的CPU 數(shù)) 就可以獲得兩倍的吞吐量 當(dāng)然 同時(shí)性能(響應(yīng)時(shí)間)也必須在可以接受的范圍內(nèi) 大多數(shù)系統(tǒng)是無法做到如此理想的線性擴(kuò)展的 隨著壓力的變化 吞吐量和性能都可能越來越差
可擴(kuò)展性指標(biāo)對(duì)于容量規(guī)范非常有用 它可以提供其他測(cè)試無法提供的信息 來幫助發(fā)現(xiàn)應(yīng)用的瓶頸 比如 如果系統(tǒng)是基于單個(gè)用戶的響應(yīng)時(shí)間測(cè)試(這是一個(gè)很糟糕的測(cè)試策略)設(shè)計(jì)的 雖然測(cè)試的結(jié)果很好 但當(dāng)并發(fā)度增加時(shí) 系統(tǒng)的性能有可能變得非常糟糕 而一個(gè)基于不斷增加用戶連接的情況下的響應(yīng)時(shí)間測(cè)試則可以發(fā)現(xiàn)這個(gè)問題
一些任務(wù) 比如從細(xì)粒度數(shù)據(jù)創(chuàng)建匯總表的批量工作 需要的是周期性的快速響應(yīng)時(shí)間 當(dāng)然也可以測(cè)試這些任務(wù)純粹的響應(yīng)時(shí)間 但要注意考慮這些任務(wù)之間的相互影響 批量工作可能導(dǎo)致相互之間有影響的查詢性能變差 反之亦然
歸根結(jié)底 應(yīng)該測(cè)試那些對(duì)用戶來說最重要的指標(biāo) 因此應(yīng)該盡可能地去收集一些需求 比如 什么樣的響應(yīng)時(shí)間是可以接受的 期待多少的并發(fā)性 等等 然后基于這些需求來設(shè)計(jì)基準(zhǔn)測(cè)試 避免目光短淺地只關(guān)注部分指標(biāo) 而忽略其他指標(biāo)
返回目錄 高性能MySQL
編輯推薦
ASP NET開發(fā)培訓(xùn)視頻教程
數(shù)據(jù)倉(cāng)庫(kù)與數(shù)據(jù)挖掘培訓(xùn)視頻教程
lishixinzhi/Article/program/MySQL/201311/29741
1、使用行級(jí)別鎖,避免表級(jí)別或頁級(jí)別鎖
盡量使用支持行級(jí)別鎖的存儲(chǔ)引擎,如InnoDB;只在讀操作顯著多于寫作的場(chǎng)景中(如數(shù)據(jù)倉(cāng)庫(kù)類的應(yīng)用)使用表級(jí)別鎖的存儲(chǔ)引擎,如MyISAM;。
2、降低熱巨鎖(hot gaint lock)出現(xiàn)的可能性以盡可能避免全局互斥量
臨界區(qū)(僅允許單一線程訪問的資源)會(huì)嚴(yán)重降低MySQL系統(tǒng)并發(fā)性;InnoDB緩沖池(buffer pool)、數(shù)據(jù)字典等都是常見的臨界區(qū);幸運(yùn)的是,新版本的InnoDB已經(jīng)能夠較好的運(yùn)行于多核處理器,支持使用 innodb_buffer_pool_instances服務(wù)器變量建立多個(gè)緩沖池實(shí)例,每個(gè)緩沖池實(shí)例分別自我管理空閑列表、列表刷寫、LRU以及其它跟緩沖池相關(guān)的數(shù)據(jù)結(jié)構(gòu),并通過各自的互斥鎖進(jìn)行保護(hù)。
3、并行運(yùn)行多個(gè)I/O線程
通過innodb_io_capacity服務(wù)器變量等增加磁盤I/O線程的數(shù)量可以提高前端操作(如SELECT)的性能,不過,磁盤I/O線程的數(shù)量不應(yīng)該超過磁盤的IOPS(7200RPM的單塊硬件的IOPS數(shù)量一般為100個(gè)左右)。
此外,異步I/O也可以在一定程度上提高系統(tǒng)的并發(fā)能力,在Linux系統(tǒng)上,可以通過將MySQL的服務(wù)器變量innodb_use_native_aio的值設(shè)定為ON設(shè)定InnoDB可以使用Linux的異步I/O子系統(tǒng)。
4、并行后端任務(wù)
默認(rèn)情況下,MySQL的清寫(purge)操作(用于移除帶刪除標(biāo)記的記錄)由InnoDB的主線程完成,這可以降低內(nèi)部資源競(jìng)爭(zhēng)發(fā)生的概率,進(jìn)而增強(qiáng)MySQL服務(wù)伸縮能力。不過,隨著InnoDB內(nèi)部各式各樣的競(jìng)爭(zhēng)越來越多,這種設(shè)置帶來的性能優(yōu)勢(shì)已幾乎不值一提,因此,生產(chǎn)環(huán)境中應(yīng)該通過為innodb_purge_threads服務(wù)器變量設(shè)定為ON將主線程與清寫線程分開運(yùn)行。
5、單線程復(fù)制模型中的SQL線程是一個(gè)熱區(qū)
在從服務(wù)器上并行運(yùn)行多個(gè)SQL線程可有效提高M(jìn)ySQL從服務(wù)器性能,MySQL 5.6支持多線程復(fù)制(每庫(kù)一個(gè)復(fù)制線程);