㈠ 怎樣從硬體方面提高伺服器計算速度
從硬體上來提神技術速度的話，就相當於提升伺服器的配置。版
其中最主要的，是CPU ,高配，高頻，權核心數多。cpu相當於人的大腦.
內存和硬碟也要高，硬碟最高是固態盤和SAS盤，這種的硬碟的轉速快，讀取數據能力強。
機器像人一樣，使用近兩年的高配機器，不要使用以使用多年的機器，那樣會大打折扣機器的性能甚至出問題。
機房的網路至關重要，再好的房子不在告訴邊也走不遠，機器的配置再好，網路垃圾還是無法訪問。
可以網路查下海騰數據晉慧娟
㈡ 怎麼提高伺服器上傳速度
可以使用下載的方式進行傳輸到伺服器上，或者是使用雲盤 速度會普通的ftp上傳快很多倍的。
㈢ 怎樣提高伺服器的下載速度
要想提高速度，首頁要弄清楚雙方所在的網路是不是一樣，比如公司服回務器在聯通網路，你在電信答網路，這樣通常來說都是很慢的。
如果真是網路不同造成的，可以考慮下CDN加速，效果比較明顯。
如果不是網路原因，查下下伺服器上有沒有限制速度的設置（可以在公司內網測試下速度是否正常）
希望以上回答有所幫助。
㈣ 如何加快伺服器下載速度
先用軟體測試一下帶寬質量內 鏈接是：容http://benchmark.avl.com.cn/cab/avltool.exe
㈤ 怎麼提高網站從伺服器讀取數據的速度
現在伺服器的配置層出不窮，讀取速度成為了重中之重，那我們改怎麼樣來提高伺服器的讀取速度呢？下面壹基比小喻來教你們幾個方法。
1.使用內存資料庫,、
內存資料庫，其實就是將數據放在內存中直接操作的資料庫。相對於磁碟，內存的數據讀寫速度要高出幾個數量級，將數據保存在內存中相比從磁碟上訪問能夠極大地提高應用的性能。內存資料庫拋棄了磁碟數據管理的傳統方式，基於全部數據都在內存中重新設計了體系結構，並且在數據緩存、快速演算法、並行操作方面也進行了相應的改進，所以數據處理速度比傳統資料庫的數據處理速度要快很多。
但是安全性的問題可以說是內存資料庫最大的硬傷。因為內存本身有掉電丟失的天然缺陷，因此我們在使用內存資料庫的時候，通常需要，提前對內存上的數據採取一些保護機制，比如備份，記錄日誌，熱備或集群，與磁碟資料庫同步等方式。對於一些重要性不高但是又想要快速響應用戶請求的部分數據可以考慮內存資料庫來存儲，同時可以定期把數據固化到磁碟。
2.使用RDD
在大數據雲計算相關領域的一些應用中，Spark可以用來加快數據處理速度。Spark的核心是RDD，RDD最早來源與Berkeley實驗室的一篇論文《Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing》。現有的數據流系統對兩種應用的處理並不高效：一是迭代式演算法，這在圖應用和機器學習領域很常見；二是互動式數據挖掘工具。這兩種情況下，將數據保存在內存中能夠極大地提高性能。% n( i. u5 O! m;
3.增加緩存
很多web應用是有大量的靜態內容，這些靜態內容主要都是一些小文件，並且會被頻繁的讀，採用Apache以及nginx作為web伺服器。在web訪問量不大的時候，這兩個http伺服器可以說是非常的迅速和高效，如果負載量很大的時候，我們可以採用在前端搭建cache伺服器，將伺服器中的靜態資源文件緩存到操作系統內存中直接進行讀操作，因為直接從內存讀取數據的速度要遠大於從硬碟讀取。這個其實也是增加內存的成本來降低訪問磁碟帶來的時間消耗。
4.使用SSD
除了對內存方面的優化，還可以對磁碟這邊進行優化。跟傳統機械硬碟相比，固態硬碟具有快速讀寫、質量輕、能耗低以及體積小等特點。但是ssd的價格相比傳統機械硬碟要貴，有條件的可以使用ssd來代替機械硬碟。/
5.優化資料庫)
大部分的伺服器請求最終都是要落到資料庫中，隨著數據量的增加，資料庫的訪問速度也會越來越慢。想要提升請求處理速度，必須要對原來的單表進行動刀了。目前主流的Linux伺服器使用的資料庫要屬mysql了，如果我們使用mysql存儲的數據單個表的記錄達到千萬級別的話，查詢速度會很慢的。根據業務上合適的規則對資料庫進行分區分表，可以有效提高資料庫的訪問速度，提升伺服器的整體性能。另外對於業務上查詢請求，在建表的時候可以根據相關需求設置索引等，以提高查詢速度。
㈥ 怎樣提高伺服器的響應速度
提高伺服器響應速度是多方面的:
一\伺服器網路資源帶寬.帶寬越高越好.
二\就是從網站專優化方面入手.具體包括屬以下方面
1\優化HTML代碼.盡量不要用TALBE布局.而採用div+CSS方式.這樣可以把網頁體積縮小至少50%.減少網站傳輸量和帶寬點用量
2\網頁中盡量不要用或少用大體積圖片
3\如果用動態程序.要去優化程序,盡量減少伺服器回傳(postback),即減少伺服器資料庫查詢次數,降低伺服器負載
4\如果網站訪問量大.盡量後台生成靜態頁面(目前新浪,搜狐等大型網站都是採用這種方法).但程序寫起來比較麻煩.
㈦ 如何提升web伺服器的運行速度
1) DNS Lookup，DNS解析時間。如果頁面存在多個請求主機，頻繁DNS解析將消耗更多的版時間。
2) Connecting，建立一個TCP連接所權需要的時間，不同的瀏覽器使用不同的埠下載資源，因此更多的埠等於更多的並行性，並且更多的TCP連接時間開銷。
3) Blocking，網頁請求被阻塞，花費在瀏覽器中的等待網路連接的時間;
4) Sending，向伺服器發送請求所需要的時間;
5) Waiting，等待伺服器響應的時間(直到第一個位元組是從伺服器收到的)，優化服務或連接;
6) Receiving，接收伺服器響應對象需要的時間;
【TS，DM】
㈧ 如何提高伺服器速度
再買一個小空間，設置雙線訪問，每個IP點上訪問速度是不一樣的，還有網頁不要超過50K，速度明顯提高
㈨ 如何提升伺服器的速度
你好來.我來解答下你的問自題.
影響伺服器運行速度的因素是多方面的.比如說伺服器的配置.帶寬.所在機房網路環境.所用的網站程序.是否中病毒木馬等.如果你的伺服器是用的WIN系統.建議像平時優化自己電腦一樣.可以從以下幾個方面來優化提升性能:
一.藉助於一些電腦管家.安全衛士等軟體直接優化系統.
二.ASP的網站直接用IIS即可發布.不需要再配置PHP.NET等其他網站環境.安裝的資料庫太多也會降低伺服器性能.
三.建議沒用的軟體以及程序刪除掉.平時養成好的操作習慣.可以不用安裝殺軟.
四.定期更新系統補丁.並進行病毒和木馬的掃描.
五.平時留意CPU.內存.以及帶寬的佔用情況.當配置不夠用時及時升級.
海騰數據楊闖為你解答.希望以上回答對你有幫助.
㈩ 怎樣提高IIS伺服器性能，加快伺服器速度
1、應該分配和釋放多個對象
你應該盡量避免過量分配內存，因為內存分配可能是代價高昂的。釋放內存塊可能更昂貴，因為大多數分配算符總是企圖連接臨近的已釋放的內存塊成為更大的塊。直到Windows NT? 4.0 service pack 4.0，在多線程處理中，系統堆通常都運行得很糟。堆被一個全局鎖保護，並且在多處理器系統上是不可擴展的。
2.不應該考慮使用處理器高速緩存
大多數人都知道由虛擬內存子系統導致的hard 頁錯誤代價很高，最好避免。但是許多人認為其他內存訪問方法沒有什麼區別。自從80486以後，這一觀點就不對了。現代的CPUs比RAM要快得多，RAM至少需要兩級內存緩存 ，高速L1 緩存能保存8KB數據和8KB指令，而較慢的L2 緩存能保存幾百KB的數據和代碼，這些數據和代碼混合在一起。L1 緩存中內存區域的一個引用需要一個時鍾周期，L2 緩存的引用需要4到7個時鍾周期，而主內存的引用需要許多個處理器時鍾周期。後一數字不久將會超過100個時鍾周期。在許多方面，緩存像一個小型的，高速的，虛擬內存系統。
至於和緩存有關的基本內存單元不是位元組而是緩存列。Pentium 緩存列有32個位元組寬。Alpha 緩存列有64個位元組寬。這意味著在L1 緩存中只有512個slot給代碼和數據。如果多個數據一起使用（時間位置）而並不存儲在一起（空間位置），性能會很差。數組的空間位置很好，而相互連接的列表和其他基於指針的數據結構的位置往往很差。
把數據打包到同一個緩存列中通常會有利於提高性能，但是它也會破壞多處理器系統的性能。內存子系統很難協調處理器間的緩存。如果一個被所有處理器使用的只讀數據，和一個由一個處理器使用並頻繁更新的數據共享一個緩存 列，那麼緩存將會花費很長時間更新這個緩存列的拷貝。這個Ping-Pong高速游戲通常被稱為"緩存 sloshing"。如果只讀數據在一個不同的緩存 列中，就可以避免sloshing。
對代碼進行空間優化比進行速度優化效率更高。代碼越少，代碼所佔的頁也越少，這樣需要的運行設置和產生的頁錯誤也會更少，同時占據的緩存 列也會更少。然而，某些核心函數應該進行速度優化。可以利用profiler去識別這些函數。
3.決不要緩存頻繁使用的數據。
軟體緩存可以被各種應用程序使用。當一個計算代價很高時，你會保存結果的一個拷貝。這是一個典型的時空折中方法：犧牲一些存儲空間以節省時間。如果做得好，這種方法可能非常有效。
你必須正確地進行緩存。如果緩存了錯誤數據，就會浪費存儲空間。如果緩存得太多，其他操作可以使用的內存將會很少。如果緩存得太少，效率又會很低，因為你必須重新計算被緩存 遺漏的數據。如果將時間敏感數據緩存得時間過長，這些數據將會過時。一般，伺服器更關心的是速度而不是空間，所以他們要比桌面系統進行更多的緩存。一定要定期去除不用的緩存，否則將會有運行設置問題。
4.應該創建多個線程，越多越好。
調整伺服器中起作用的線程數目是很重要的。如果線程是I/O-bound的，將會花費很多時間用來等待I/O的完成-一個被阻塞的線程就是一個不做任何有用工作的線程。加入額外的線程可以增加通量，但是加入過多的線程將會降低伺服器的性能，因為上下文交換將會成為一個重大的overhead。上下文交換速度應該低的原因有三個：上下文交換是單純的overhead，對應用程序的工作沒有任何益處；上下文交換用盡了寶貴的時鍾周期；最糟的是，上下文交換將處理器的緩存填滿了沒用的數據，替換這些數據是代價高昂的。
有很多事情是依靠你的線程化結構的。每個客戶端一個線程是絕對不合適的。因為對於大量用戶端，它的擴展性不好。上下文交換變得難以忍受，Windows NT用盡了資源。線程池模型會工作得更好，在這種方法中一個工人線程池將處理一條請求列，因為Windows 2000提供了相應的APIs，如QueueUserWorkItem。
5.應該對數據結構使用全局鎖
使數據線程安全的最簡單方法是把它套上一把大鎖。為簡單起見，所有的東西都用同一把鎖。這種方法會有一個問題：序列化。為了得到鎖，每一個要處理數據的線程都必須排隊等候。如果線程被一把鎖阻塞，它沒有在做任何有用的事。當伺服器的負載較輕時，這個問題並不常見，因為一次可能只有一個線程需要鎖。在負載很重的情況下，對鎖的激烈爭奪可能就會成為一個大問題。
設想在多車道高速公路上發生了一個意外事故，這條高速公路上的所有車輛都被轉向一條狹窄的道路。如果車輛很少，這一轉換對交通流的速率的影響可以忽略。如果車輛很多，當車輛慢慢並入那條單通道時，交通阻塞會延伸幾英里。
有幾種技術能夠減少鎖競爭。
· 不要過分保護，也就是說，不是非常必要不要鎖住數據。只有需要時才去持有鎖，而且時間不要過長。不要在大段代碼周圍或頻繁執行的代碼中沒必要地使用鎖，這一點很重要。
· 對數據進行分割，使它能夠用一套獨立的鎖保護。例如，一個符號表可以按標識符的第一個字母分割，這樣在修改名字以Q開頭的符號的值時，就不會去讀名字以H開頭的符號的值。
· 使用APIs的Interlocked 系列（InterlockedIncrement，等）自動修改數據而不需要鎖。
· 當數據不是經常被修改時可以使用多讀者/單作者（multi-reader/single-writer）鎖。你將獲得更好的並發性，盡管鎖操作的代價將更高並且你可能會冒餓死作者的危險。
· 在關鍵部分使用循環計數器。參見Windows NT 4.0 service pack 3中的SetCriticalSectionSpinCount API。
· 如果你不能得到鎖，使用TryEnterCriticalSection並做一些其他的有用的工作。
高競爭導致serialization，serialization導致降低CPU的利用率，這促使用戶加入更多的線程，結果事情變得更糟。
6.不必注意多處理器機器
你的代碼在多處理器系統上比在單處理器系統上運行得還要糟，這可能是件令人惡心的事。一個很自然的想法是，在一個N維系統上運行N次會更好。性能很差的原因是競爭：鎖競爭，匯流排競爭，和/或緩存列競爭。處理器都在是爭奪共享資源的所有權，而不是做更多的工作。
如果你一定要編寫多線程應用程序的話，你應該在多處理器盒上對你的應用程序進行強度測試和性能測試。單處理器系統通過時間分片地執行線程而提供一個並發性的假象。多處理器盒具有真正的並發性，競爭環境和競爭更容易發生。
7.應該始終使用模塊化調用；他們很有趣。
利用同步模塊化調用來執行I/O操作對大多數桌面應用程序來說是合適的。但是，他們不是使用伺服器上的CPU（s）的好方法。I/O操作要花費上百萬個時鍾周期來完成，這些時鍾周期本來可以被更好地利用。利用非同步I/O你能得到顯著提高的用戶請求率和I/O通量，不過增加了額外的復雜性。
如果你有需要花費很長時間的模塊化調用或I/O操作，你應該考調撥多少資源給他們。你想使用所有的線程還是有個限制？一般地，使用有限的幾個線程要好些。構建一個小的線程池和隊列，利用隊列來安排線程的工作完成模塊化調用。這樣，其他線程就可以拾取和處理你的非模塊化的請求。
8.不要進行測量
當你能夠測量你所談論的事情並用數字表達它時，這就表示你對他有了一定的了解；但是如果你不能用數字表達時，你的知識是貧瘠的不能令人滿意的；這可能是知識的開始，但這時你簡直不可能將你的思想提高到科學的水平。
- Lord Kelvin (William Thomson)
如果不測量你就不能了解應用程序的特性。你在黑暗中摸索，一半是靠猜測。如果不識別性能問題，你就不能做任何改進或做出工作量計劃。
測量包括黑匣子測量和profiling。黑匣子測量的意思是收集由性能計數器（內存使用，上下文交換，CPU利用等）和外部檢測工具（通量，反映時間等）所顯示的數據。為了profile你的代碼，你編譯代碼的一個工具版，然後在各種條件下運行它，並收集關於執行時間和過程調用頻率的統計數據。
測量如果不用於分析的話就一點用都沒有。測量將不僅告訴你有問題，而且甚至能幫助你找到問題發生在哪，但它不能告訴你為什麼會有問題。對問題進行分析以便你能正確地改正他們。要從根本上解決問題而不是停留在表面現象。
當你進行改動後，要重新測量。你要知道你的改動是否有效。改動也可能會暴露其他性能問題，測量-分析-改正-再測量的循環就會重新開始。你也必須要有規律地進行測量，以便發現性能衰退問題。
9.應該使用單一用戶，單一請求的測試方法。
書寫ASP和ISAPI應用程序的一個通病是只用一個瀏覽器去測試應用程序。當他們在Internet上應用他們的程序時，他們才發現他們的應用程序不能處理高負載，並且通量和反應時間另人可憐。
用一個瀏覽器測試是必要的但是不夠的。如果瀏覽器反應得不夠快，你就知道你有麻煩了。但即使它在使用一個瀏覽器時很快，你也不知道它處理負載的能力如何。如果十幾個用戶同時請求會發生什麼事？一百個呢？你的應用程序能容忍什麼樣的通量？它能提供什麼樣的反應時間？在輕載時這些數字會怎樣？中等負載呢？重載呢？在多處理器機器上你的應用程序會如何？對你的應用程序進行強度測試，這對於找出bugs發現性能問題來說是基本的。
類似的負載測試考慮適用於所有的伺服器應用程序。
10.不應使用實際環境。
人們往往只在幾個特定的，人工的環境（如下benchmarks）下調整應用程序。選擇和實際情況相對應的各種情況，並為針對各種操作進行優化，這一點很重要。如果你不這樣做，你的用戶和評論家一定會這樣做，並且他們將依此來評判你的應用程序的好壞。