Play फ्रेमवर्क 2.0 प्रदर्शन मापन

Play फ्रेमवर्क 2.0 प्रदर्शन मापन

मैंने पहले से ही टाइपसेफ़ स्टैक 2.0 सॉफ़्टवेयर प्लेटफ़ॉर्म के बारे में बात की थी । उस पोस्ट में, मैंने मंच के एक घटक के बारे में बात की - अक्का 2.0 फ्रेमवर्क, जो जेवीएम पर अभिनेता मॉडल को लागू करता है। आज मैं टाइपसैक स्टैक के एक अन्य घटक - प्ले 2.0 ढांचे की क्षमताओं के बारे में लिखना चाहता हूं। यद्यपि इस घटक की कार्यक्षमता पहले से ही यहां और यहां बताई गई है , प्ले 2.0 के समाधान के प्रदर्शन के विषय में, मेरी राय में, इसका खुलासा नहीं किया गया है।

इसके आधार पर विकसित सबसे सरल अनुप्रयोग का उपयोग करके रूपरेखा का परीक्षण किया जाएगा। परीक्षणों के परिणामस्वरूप, निम्नलिखित प्रश्नों का उत्तर दिया जाना चाहिए। एक साथ कनेक्शन की अधिकतम संभव संख्या क्या है? इन कनेक्शनों की खपत कितनी रैम है? परीक्षण आवेदन प्रक्रिया के प्रति यूनिट के कितने अनुरोध हो सकते हैं?

परीक्षण आवेदन

परीक्षण के तहत आवेदन के विवरण के लिए आगे बढ़ने से पहले, हमें प्ले 2.0 ढांचे की मुख्य वास्तुशिल्प विशेषताओं को स्पष्ट करना चाहिए। Play HTTP सर्वर हाई-परफॉर्मेंस नेट्टी लाइब्रेरी पर आधारित है। यह न केवल आपको "बॉक्स से बाहर" का उपयोग करने की अनुमति देता है, सर्वलेट कंटेनर के कॉन्फ़िगरेशन को छोड़कर, बल्कि क्लाइंट अनुरोधों को अतुल्यकालिक रूप से संसाधित करने की क्षमता भी प्रदान करता है। शास्त्रीय तुल्यकालिक प्रसंस्करण संस्करण में, उत्तर के लिए कोई भी आने वाला अनुरोध, जिसके लिए कुछ गणना की आवश्यकता होती है, हर समय ऑपरेटिंग सिस्टम थ्रेड पर कब्जा कर लेगा, जबकि यह गणना की जा रही है। Play आपको गणना की अवधि के लिए सर्वर पूल में स्ट्रीम वापस करने की अनुमति देता है और गणना तैयार होने पर फिर से स्ट्रीम करने के लिए स्ट्रीम लेता है। तकनीकी रूप से, इसका मतलब है कि तुल्यकालिक संस्करण की तुलना में अधिक ग्राहकों को एक साथ जोड़ने की क्षमता।

परीक्षण के तहत आवेदन तीन मुख्य कार्य करेगा:

• क्लाइंट ब्राउज़र के साथ एक धूमकेतु कनेक्शन बनाएं ( /wait?cid={connection_id} )
• आने वाले मूल्य को स्वीकार करें और सभी उपलब्ध धूमकेतु-कनेक्शन ( /put?v={value} ) के ब्राउज़र कंसोल पर भेजें
• सभी मौजूदा धूमकेतु कनेक्शन बंद करें ( /closeall )

विकास के दौरान, अक्का 2.0 पुस्तकालय का उपयोग किया गया था। एप्लिकेशन को स्काला भाषा में विकसित किया गया था, क्योंकि मेरे दृष्टिकोण से यह जावा की तुलना में अक्का के साथ काम करने के लिए अधिक सुविधाजनक है। नीचे मैं कोड के मुख्य भागों को केवल प्ले 2.0 में कनेक्शन के साथ काम करने की सरलता दिखाऊंगा और इस पोस्ट का सार नहीं छोड़ूंगा। सभी कोड गिट रिपॉजिटरी से प्राप्त किया जा सकता है, एक लिंक जो प्रकाशन के अंत में दिया गया है।

अभिनेता धूमकेतु-अप

 ... lazy val channel: PushEnumerator[String] = ch ... def receive = { case Message(message) => { channel.push(message) } ... case Close => { channel.push("closed") channel.close() self ! Quit } } ... 

channel चर धूमकेतु कनेक्शन (प्रकार - Enumerator ) के लिए डेटा स्रोत है, जिसे नीचे दिखाया गया है, धूमकेतु कनेक्शन के माध्यम से Comet -कनेक्शन (प्रकार - Enumeratee ) के लिए प्रेषित किया जाता है। आप यहां Play में डेटा स्ट्रीम के स्रोतों-कन्वर्टर्स-उपभोक्ताओं के साथ काम करने के बारे में अधिक पढ़ सकते हैं। डेटा को channel.push(message) फ़ंक्शन को कॉल करके धूमकेतु सॉकेट में प्रसारित किया जाता है। channel.close() कहकर एक धूमकेतु सॉकेट को बंद करना।

आवेदन के मुख्य अभिनेता

कनेक्शनसुपरवाइजर अभिनेता के कार्यों में शामिल हैं: एक धूमकेतु कनेक्शन बनाना, निर्मित कनेक्शनों को संदेश भेजना, सभी कनेक्शनों को बंद करना।

 ... var connectionActors = Seq.empty[ActorRef] def receive = { case SetConnect(connectionId) => { lazy val channel: PushEnumerator[String] = Enumerator.imperative( onComplete = self ! Disconnect(connectionId) ) val connectionActor = context.actorOf(Props(new ConnectionActor(channel)), connectionId) connectionActors = connectionActors :+ connectionActor sender ! channel } case BroadcastMessage(message) => { connectionActors.foreach(_ ! Message(message)) } case CloseAll => { connectionActors.foreach(_ ! Close) } } ... 

निर्मित अभिनेताओं के लिंक कनेक्शनएक्टर अनुक्रम (प्रकार - Seq [ActorRef]) में संग्रहीत किए जाते हैं। जब एक कनेक्शन स्थापित होता है, तो चैनल चैनल बनाया जाता है, जिसे नए कनेक्शनएक्टर को पास किया जाता है। अभिनेताओं की सूची में एक अभिनेता को जोड़ा जाता है। संदेश कैसे भेजे जाते हैं और कनेक्शन बंद हैं यह कोड से स्पष्ट होना चाहिए।

वर्तमान मूल्य को संग्रहीत करने के लिए अभिनेता

यह माना जाता है कि StorageActor लिए एक मूल्य भेजा जाता है, कुछ क्रियाएं की जाती हैं और मूल्य सभी धूमकेतु-कनेक्शनों को भेजा जाता है, और क्लाइंट को भी लौटा दिया जाता है। इस तरह, कुछ वास्तविक एप्लिकेशन का व्यवहार नकली होता है जब ग्राहक अनुरोध करता है और उससे प्रतिक्रिया की अपेक्षा करता है।

 ... var value = "" def receive = { case Put(v) => { value = v connectSupervisor ! BroadcastMessage(value) sender ! value } } ... 

आवेदन नियंत्रक

 ... object Application extends Controller { ... def waitFor(connectionId: String) = Action { implicit val timeout = Timeout(1.second) AsyncResult { (ActorsConfig.connectSupervisor ? (SetConnect(connectionId)) ).mapTo[Enumerator[String]].asPromise.map { chunks => Ok.stream(chunks &> Comet( callback = "console.log")) } } } def broadcastMessage(message: String) = Action { ActorsConfig.connectSupervisor ! BroadcastMessage(message) Ok } def putValueAsync(value: String) = Action { implicit val timeout = Timeout(1.second) Async { (ActorsConfig.storageActor ? Put(value)).mapTo[String].asPromise.map { value => Ok(value) } } } def closeAll = Action { ActorsConfig.connectSupervisor ! CloseAll Ok } } 

आने वाले HTTP अनुरोधों के पते इस नियंत्रक के तरीकों पर मैप किए जाते हैं (मार्ग का विवरण conf/routes फ़ाइल में है)। यहां सबसे बड़ी रुचि waitFor विधि है, जो एक धूमकेतु सॉकेट बनाता है और इसके साथ एक प्रकार के Enumerator[String] एक चैनल को waitFor Enumerator[String] । SetConnect संदेश के जवाब में अभिनेता द्वारा चैनल को सॉकेट में भेजा जाता है। चैनल में आने वाले प्रत्येक संदेश को क्लाइंट के ब्राउज़र में Comet( callback = "console.log") ऑब्जेक्ट Comet( callback = "console.log") में निर्दिष्ट फ़ंक्शन के पैरामीटर के रूप में प्रेषित किया जाता है। इस मामले में, यह console.log फ़ंक्शन है।

क्लाइंट साइड पर, एक छिपे हुए iframe तत्व का उपयोग करके एक धूमकेतु कनेक्शन बनाया जाता है, उदाहरण के लिए:

 <iframe src='/wait?cid=1' style='display:none'/> 

परीक्षण की प्रक्रिया

परीक्षण एप्लिकेशन को 1 जीबी रैम और 1 प्रोसेसर कोर (भौतिक कंप्यूटर का प्रोसेसर इंटेल कोर i5-2400 3.1GHz है) के साथ Ubuntu 11.10 (32-बिट) चलाने वाली एक आभासी मशीन पर चलाया गया था।

मानक उपकरण (JMeter, Visual Studio Load Test) के साथ परीक्षण विफल रहा, क्योंकि यहां तक ​​कि 700 समानांतर धागों के प्रक्षेपण ने परीक्षण प्रणाली को इतना विस्मित कर दिया कि कम से कम कोई महत्वपूर्ण भार पैदा करना असंभव था। एक विशेष परीक्षण उपकरण का उपयोग करना जैसे कि गैटलिंग तनाव उपकरण (जिसकी वास्तुकला भी अक्का पर आधारित है) धूमकेतु-कनेक्शन के लिए एक परीक्षण फ़ंक्शन की कमी के कारण संभव नहीं था। उसी समय, संशोधन भी एक कठिन कार्य था, क्योंकि डेवलपर प्रलेखन निर्माणाधीन है। इन कारणों से, हमारे अपने परीक्षण उपकरण को विकसित किया गया था।

टेस्ट स्क्रिप्ट

परिदृश्य में तीन चरण होते हैं:

• धूमकेतु कनेक्शन की एक निश्चित संख्या एक निश्चित आवृत्ति के साथ बनाई गई है
• मूल्यों की एक पूर्व निर्धारित संख्या एक निश्चित आवृत्ति के साथ प्रेषित होती है
• धूमकेतु कनेक्शन को एक संबंधित अनुरोध द्वारा बंद कर दिया जाता है

परीक्षण प्रक्रिया के दौरान, डेटा को स्थापित धूमकेतु कनेक्शनों की संख्या, प्रत्येक धूमकेतु कनेक्शन में औसतन प्राप्त मूल्यों की संख्या, उन्हें भेजने और उनसे सफल होने के अनुरोधों की संख्या और इन अनुरोधों के औसत निष्पादन समय पर एकत्र किया जाता है। स्क्रिप्ट के प्रत्येक चरण के निष्पादन के दौरान, प्रोसेसर लोड और अधिग्रहित रैम की मात्रा दर्ज की गई (धूमकेतु कनेक्शन के लिए)।

परीक्षण के परिणाम

1. धूमकेतु कनेक्शन की अधिकतम संख्या और उपयोग की गई रैम की मात्रा को मापें।
   
   इस परीक्षण समूह में, धूमकेतु-कनेक्शन स्थापित करने के बाद, एकमात्र मान भेजा जाता है, जिसके बाद कनेक्शन बंद हो जाते हैं।
   

   धूमकेतु कनेक्शन की संख्या	कनेक्शन आवृत्ति (1 / एमएस)	अधिकृत मेमोरी (MB)	कनेक्शन सेटअप के दौरान अधिकतम CPU उपयोग	मूल्य भेजते समय अधिकतम CPU उपयोग
   500	50	36	15%	15%
   1000	40	56	17.5%	15%
   3000	20	145	25%	62%
   3000	10	142	40.6%	61%
   3000	5	140	59.9%	70.8%
   3000	3	138	98%	69%
   6000	4	262	80.5%	93.4%
   8000	4	394	73.7%	80.9%
   10000	4	485	77.1%	100%

   
   4 एमएस की अवधि के साथ धूमकेतु-कनेक्शन स्थापित करने की प्रक्रिया में प्रोसेसर लोड उचित सीमा के भीतर है, इसलिए, अतिरिक्त कनेक्शन जोड़ना केवल रैम की बात है।
   
   
2. मूल्य भेजने के अनुरोधों और अल्पकालिक शिखर भार के अधिकतम प्रवाह का मापन।
   
   जैसा कि आप पिछले परीक्षणों से देख सकते हैं, एक धूमकेतु कनेक्शन के लिए एक मूल्य भेजना एक संसाधन-गहन संचालन है, इसलिए, परीक्षणों के इस समूह में, सर्वर के अधिकतम प्रवाह को मापने के लिए, कनेक्शन की संख्या कम हो जाएगी।
   

   धूमकेतु कनेक्शन की संख्या	प्रस्तुत मूल्यों की संख्या	फ्रीक्वेंसी भेजें (1 / ms)	मैक्स सीपीयू यूसेज ऑन सबमिट	औसत क्वेरी निष्पादन समय (ms)	अस्वीकृत अनुरोधों की संख्या
   1000	10	100	85.7%	163	7
   1000	10	500	76.5%	45	0
   1000	10	200	100%	374	2
   500	10	200	77%	39	0
   100	10	100	25%	19	0
   100	100	50	68.9%	35	0
   100	100	30	100%	250	0
   10	100	20	31%	12	0
   10	1000	10	61.7%	18	0
   10	1000	5	98.7%	47	0
   1	1000	4	58.2%	27	0
   1	1000	2	92.3%	33	0
   1	10000	2	100%	400	4636
   1	8000	4	100%	415	3217
   1	5000	5	100%	399	292
   1	3000	7	100%	129	0
   1	2000	7	98%	58	0

   
   प्रदर्शन किए गए परीक्षणों से पता चलता है कि आवेदन प्रति सेकंड 500 अनुरोधों के अल्पकालिक शिखर भार का सामना करता है और प्रति सेकंड 100-150 अनुरोधों के भार के साथ सामान्य रूप से काम करता है।
   

अद्यतन:
परीक्षण किया गया आवेदन: git: //github.com/tolyasik/testeeApp.it
परीक्षण आवेदन: git: //github.com/tolyasik/testerApp.git