建站
咨詢
售后
建站咨詢
新聞中心
Ben Gidley進(jìn)行了一個關(guān)于Tapestry5.1.0.5的性能評測。最后，他得出的結(jié)論是：
路橋網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、自適應(yīng)網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)建站成立與2013年到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。
1、Tapestry5的速度是比較快的。即使在一定的壓力下Tapestry的反應(yīng)時間也相當(dāng)短。Tapestry并不總是最快的解決方案，但它對于我（譯注：Gidley）已經(jīng)足夠快了。
2、Tapestry5沒有內(nèi)存泄漏。我以前曾經(jīng)聽說過Tapestry會占用大量的內(nèi)存，實(shí)際上，正好相反。它使用的內(nèi)存比Struts/Jsp還要少。內(nèi)存使用曲線相當(dāng)?shù)钠教埂?/p>
3、Tapestry5在表單應(yīng)用中比struts要快。Tapestry在應(yīng)用變得非常復(fù)雜的時候有一定的優(yōu)勢。這可能利益于其模塊池技術(shù)。
4、Tapestry5不輕易崩潰，即使崩潰，也會恢復(fù)。Tapestry在極大壓力的情況下確實(shí)會相應(yīng)變慢，但是它會暫停或者遇到瓶頸（譯注：我懷疑是作者這里有筆誤，從語氣和上下文來看，感覺應(yīng)該不是暫停和沒有瓶頸），這的確是一個好事情。另外在壓力減輕之后，Tapestry能夠自動恢復(fù)。
5、更多的CPU并一定會提升性能。在一系列的測試中，性能與CPU的數(shù)量并不是線性增長。２個CPU確實(shí)比一個CPU的性能翻倍了，但是４個CPU并不比２個CPU的性能翻倍。因此，建議在多個雙核CPU的虛擬機(jī)上運(yùn)行，而不是少數(shù)的４核CPU上運(yùn)行。
6、６４位比３２位要快。這一點(diǎn)很讓我驚奇。不管在Solaris還是Linux上，運(yùn)行在６４位JVM中要比在３２位JVM要快。
7、Linux要比Open Solaris X86要快。這一點(diǎn)同樣讓我驚奇。我本來以為性能應(yīng)該是相似的。
最終的結(jié)論是：Tapestry即使是對于一個大并發(fā)量的Web應(yīng)用來說也已經(jīng)足夠快了。如果你的應(yīng)用有性能問題的話，那么問題應(yīng)該出在你自己本身的代碼上。
Taptestry５和Struts相比，我認(rèn)為差別應(yīng)該是在反射的使用上（包括在java.bean.Introspector中大量的synchronization）。因此在Struts將查詢參數(shù)的名稱映射成JavaBean屬性的時候，會比較耗時。而Tapestry５是不使用反射的，Tapestry在查詢參數(shù)和JavaBean的屬性之間使用一種“預(yù)編程”向量組件，也許這就是兩者（Tapestry和Struts）的差別。當(dāng)然，這只是猜想，如果要證實(shí)的話，是需要花費(fèi)很多時間的。我認(rèn)為OGNL的教訓(xùn)不是說反射很慢，而是在于一個關(guān)鍵代碼上的序列存取對于性能的影響是相當(dāng)大的。
最后一個小提示：我覺得在Tapestry5應(yīng)用中如果把BeanModel從BeanModelSource中只提取一次，然后給Grid，BeanEditForm等等提供一個可以存取的方法，將會獲得相當(dāng)?shù)男阅芴嵘＿@樣就不是需要每次都重建BeanModel，將減少操作的消耗。
網(wǎng)站欄目：Tapestry5的性能改進(jìn)淺析
本文地址：http://m.fisionsoft.com.cn/article/cdojpog.html
