有沒有人在以下兩種組合中測試過他/她的應用程序的性能？Tomcat 7上的Spray-servlet與JVM上的Spray-jar罐
罐子我猜想2）執行優於1 ）在大多數情況下，即使1）使用servlet 3.0功能。
我問的原因是我的團隊需要權衡性能以及應用程序部署/管理（自動擴展，監控等）的簡便性，因爲AWS Elastic Beanstalk的默認java webapp配置是Linux運行Tomcat。
對此的任何輸入將不勝感激。乾杯
你應該看看這裏： http://spray.io/blog/2013-05-24-benchmarking-spray/
前幾天的鄉親techempower發表了他們廣受歡迎的系列目前web框架基準，在噴霧參與的第一個5回合。 Techempower基準測試包含許多不同的測試場景，這些測試場景運行着Web框架/堆棧的各個部分，其中只有一個我們爲「JSON序列化」測試提供了基於噴霧的實現。這個基準測試目標框架層的其他部分（如數據庫訪問），其噴射故意不提供。
這裏有輪5的JSON測試在替代可視化呈現的發表的結果（但是示出了完全相同的數據）：
該試驗可通過所連接的兩個相同的機器之間運行GB-Ethernet鏈接，一個生成HTTP請求的客戶機，wrk作爲負載生成器，以及一臺運行相應「benchmarkee」的服務器機器。爲了提供性能如何隨底層硬件平臺而變化的指示，所有測試運行兩次，一次在兩個EC2「m1.large」實例之間，一次在兩個專用i7-2600K工作站之間。
分析
在圖表上面我們比較與在EC2機器的那些專用硬件的性能結果。我們預計兩者之間會有很強的相關性，大多數數據點都集中在趨勢線上。距離趨勢線很遠的「bechmarkees」或者不能放大或縮小以及「包裝」，或者在其「弱」一側遭遇某些配置問題（例如，i7上的cpoll_cppsp和洋蔥或雙子/小服務程序和火花在EC2上）。無論如何，可能會建議對問題的原因進行一些調查。
除了繪製在30秒運行結束時由wrk報告的平均請求/秒數，我們還包括了請求計數的替代預測，基於wrk報告的平均請求延遲（例如，1ms平均。跨64個連接的延遲應該導致大約64K的平均請求/秒）。理想情況下，這些預測結果應該與實際報告的結果大致相符（禁止任何舍入問題）。
但是，正如您在圖表中看到的那樣，兩個結果在一些benchmarke中有很大不同。對我們來說，這是一個跡象表明，在各自的測試運行中，某些事情並不完全正確。也許運行wrk的客戶端遇到了一些其他負載，這會影響其生成請求或正確測量延遲的能力。或者我們看到wrk的某些「非正統」請求延遲採樣實現的結果。無論哪種方式，我們對平均的有效性的信心。如果兩個結果更接近對齊，請求計數和延遲數據會更高。
外賣
這一基準的特殊值不同於techempower團隊已經成功地包括不同的框架/庫/工具集的絕對數量造成的。第5輪爲使用17種不同語言編寫的近70個（！）Benchmarke非常不同的組提供結果。因此，它可以很好地說明不同解決方案可以預期的粗略性能特徵。例如，您是否預計Ruby on Rails應用程序的運行速度比基於JVM的良好選擇慢10-20倍？大多數人會假設性能上的差異，但其實際數量可能會令人驚訝，並且當然有趣，不僅對於目前正在面臨技術決策的人而言。
對於我們作爲HTTP堆棧的作者，我們從稍微不同的角度來看這樣的基準。我們面臨的主要問題是：與同一平臺上的替代方案相比，我們的解決方案的性能如何？我們可以從他們身上學到什麼？我們在哪裏仍然有優勢的潛力，我們似乎留在桌面上？在寫一個類似噴霧的圖書館時，各種架構決策對於性能有什麼影響？
從上圖可以看出，在這個特定的基準測試中，我們對spray的性能非常滿意。它優於EC2上的所有其他基於JVM的HTTP堆棧，甚至可以在專用硬件上查看延遲數據的吞吐量。
這向我們展示了我們優化噴霧的HTTP實現的成果。此基準測試中使用的版本是最近一次1.1版本的噴塗，其中包括爲即將發佈的1.0/1.1/1.2三合一版本計劃的大部分（但不是全部）性能優化（Akka 2.0爲1.0，Akka 2.1爲1.1，Akka 2.2爲1.2 ）。
但是，此基準是否證明spray是JVM上最快的HTTP堆棧？
不幸的是它沒有。這個測試可以使各種HTTP實現的所有邏輯的百分比小一些，以便能夠對它們進行正確的排名。它給出了一個指示，但幾乎沒有。
什麼是缺失？
標杆願望清單
讓我們仔細看一下techempower標杆「JSON序列化測試」，實際上行使。客戶端爲服務器創建8到256個長期併發的TCP連接，並通過這些連接觸發儘可能多的測試請求。每個請求都會衝擊服務器的NIC，通過Linux內核的網絡堆棧冒出來，由benchmarkees IO抽象獲取，並在實際由「應用程序邏輯處理」之前傳遞到HTTP層（它被解析並可能被路由） 」。在這個基準測試的情況下，應用程序僅創建一個小的JSON對象，將其放入HTTP響應中，然後將其發送回堆棧，然後再次沿相反方向通過所有層。
這樣這個基準測試如何好benchmarkee：
它通過少量的長連接使用帶有一組固定HTTP頭的小請求來完成所有這些操作。而且，它不會給我們一個線索，而是讓我們知道堆棧各個部分的潛在優勢和弱點。
如果我們想了解一些更深入的進行噴淋如何相比，其基於JVM的競爭對手，其中它的優勢和劣勢所在，我們將不得不建立衡量基準的整個範圍：
如果我們有生產這些數字也的基準套件，我們會覺得建立一個更舒適適當的基於性能的噴霧排名及其替代方案。如果有像「持續基準測試」基礎架構那樣的東西，那麼這會不會很棒？它會在簡單的git推入其存儲庫時自動生成這些基準測試結果？
哦......我想我們不斷增長的待辦事項列表剛剛收到一個多項目標記爲重要... :)
你應該看看這裏：http://blog.xebia.com/ 2013/08/02/on-the-mysteriously-fast-spray-can-web-server/and here http://spray.io/blog/2013-05-24-benchmarking-spray/ –
@MarceloBezerra你在這裏的評論應該變成一個答案，以便我可以投票。 – cfeduke
呃...它已完成;-) –