एज़ूर कैश के साथ खराब प्रदर्शन

Question

कैश में कुछ डेटाबेस कॉल स्विच करने के बाद, हम वास्तव में खराब प्रदर्शन करते थे। हमने नए अवशेष के अनुसार सीएलआर समय और प्रतिक्रिया समय में एक बड़ी छलांग देखी। कूद के लिए संलग्न ग्राफ देखें (कैश 1/5 0:00 बजे पेश किया गया था)। केवल जो चीज बदल गई है वह एज़ूर ऐप फैब्रिक कैश का परिचय रहा है। हमारा कैश क्लाइंट एक सिंगलटन पैटर्न का उपयोग करता है, इसलिए webservice के उदाहरण के लिए केवल एक ही है। कैश फैक्ट्री एक बार बनाई जाती है और फिर दूर की जाती है ताकि हम प्रत्येक बार कनेक्शन खोलने के ऊपरी हिस्से को ठीक न कर सकें।

इसके अलावा, NewRelic की रिपोर्ट है कि कैश औसत 15ms पर ले जा रहा है। कई मामलों में, डेटाबेस से 15ms धीमा हो सकता है !!!!

वस्तु हम मैं दो बाइट सरणियों के constits कैश चिपके रहे nto, एक 421 के बारे में की लंबाई है और दूसरे नहीं वास्तव में क्यों कैश की शुरूआत हम वृद्धि हुई देख के साथ समझने 8.

की लंबाई है जवाब देने का समय। एक बाइट सरणी कैश अनुकूल नहीं है?

मेरी कक्षा लगता है कि यह

[Table] 
public class GameState 
{ 
    [Column(IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)] 
    public int Id { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "game_id")] 
    public int GameId { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "player_id")] 
    public int PlayerId { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, DbType = "VarBinary(max)")] //has a length around 421 
    public byte[] State { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)] 
    public DateTime Created { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "update", IsDbGenerated = true, DbType = "timestamp")] //has a length of 8 
    public byte[] TimeStamp { get; set; } 
} 

धन्यवाद

अद्यतन (केवल दो गुण है कि करने से पहले वर्ग में shoved जा रहा पॉपुलेटेड हो दो बाइट सरणियों और सब कुछ सामान्य मानों पर छोड़ दिया जाता है)

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

हम कभी भी एज़ूर कैश को जल्दी से काम नहीं कर पाए और आखिरकार अज़ूर से अमेज़ॅन ec2 तक स्विच कर पाए। एक बार अमेज़ॅन ec2 पर तुलनीय हार्डवेयर पर हमारे प्रतिक्रिया समय लगभग 60-70ms तक गिर गया।

इस पर विचार करने में किसी और के लिए, यह स्विच में हमने सीखा।

एसक्यूएल एज़ूर को डीबी होस्टिंग साझा किया जाता है। आपको अपना डीबी नहीं मिलता है, आप किसी अन्य सर्वर के समूह के साथ एक सर्वर में हैं और यदि आपके पास कोई भी प्रकार का सभ्य ट्रैफिक है, तो आप थ्रॉटल हो जाएंगे। उन्होंने हमें कुछ टिकट खरीद सफलता की कहानी के बारे में बताना जारी रखा, लेकिन उस परिदृश्य में लेनदेन को संसाधित करने के लिए उनके पास 750 डीबी थी। शेर्डिंग कोई मजेदार नहीं है, और एक बेहतर सफलता की कहानी यह है कि आपने उन सभी अनुरोधों को 1 डीबी के साथ संभाला है।

हम एसएसएल का उपयोग करते हैं, और आईआईएस एसएसएल का प्रबंधन करते हुए वास्तव में आपके सीपीयू को मारता है। अमेज़ॅन में आपका ईएलबी एसएसएल करता है और फिर आपके आईआईएस बॉक्स को नहीं करना पड़ता है। इसने आईआईएस बक्से को तेजी से अनुरोधों को संभालने के लिए मुक्त कर दिया।

अमेज़ॅन आपको memcache चलाने देता है। Memcache भयानक है। एक हल्की तेज कैश परत (4 जीबी से आगे बढ़ने में सक्षम) होने के कारण, हमारे डीबी से भारी भार लिया।

हमने जनवरी 2012 में स्विच वापस कर दिया, इसलिए पिछले साल में यह संभव है कि अज़ूर बेहतर हो गया है, हालांकि मेरे पास इसे दूसरा मौका देने की कोई योजना नहीं है।

Answer 1

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

• लेनदेन
• बैंडविड्थ
• समवर्ती कनेक्शन

अपने प्रदर्शन परीक्षण में मुझे लगता है कि समवर्ती कनेक्शन सीमा MSDN से इसके लिए जिम्मेदार है:

Answer 2

नेटवर्क कोटा तीन बदलाव हो:

प्रत्येक कैश की पेशकश में कनेक्शन की संख्या पर एक अलग सीमा होती है जो एक ही कैश के साथ एक साथ खुलती है ... विंडोज़ एज़ूर कैशिंग का उपयोग करने वाले अनुप्रयोगों को समझना चाहिए कि कैशिंग सेवा में कनेक्शन कैसे खोले जाते हैं। प्रत्येक कैश की पेशकश में कनेक्शन की संख्या पर एक अलग सीमा होती है जो एक ही कैश के साथ एक साथ खुल सकती है।

स्रोत: https://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-use-service/

हैं कि ज्यादा मदद नहीं करता है तो आप अलग अलग संगामिति मॉडल की तुलना सोच सकते हैं। ऐपफैब्रिक आशावादी और निराशावादी समवर्ती मॉडल का समर्थन करता है, इस पर अधिक जानकारी के लिए http://msdn.microsoft.com/en-us/library/ee790890.aspx देखें।