(आईओएस) ऑफलाइन सिंक डीबी - सर्वर

Question

इंटरनेट से कनेक्ट होने पर स्थानीय डीबी पर वेब सर्वर पर संग्रहीत ऑफ़लाइन डेटा भेजने वाले ऐप को लागू करने का प्रयास करना। मैं नीचे दिखाए गए कोड का उपयोग करता हूं। जहां तक ​​मैंने परीक्षण किया है, यह ठीक काम करता है, सुनिश्चित नहीं है कि यह बड़ी संख्या में रिकॉर्ड्स के लिए ठीक काम करेगा। मैं जानना चाहता हूं कि इस कोड पर कोई ट्वीकिंग प्रदर्शन को बढ़ा सकता है ???

नोट

• मैं इस ऑफ़लाइन समन्वयन उद्देश्य के लिए एक सबसे खराब कोड होगा पता है, तो यह बेहतर बदलाव करने कोशिश कर रहा।

• ऐप से सर्वर तक, यह एकमात्र तरीका सिंक्रनाइज़ेशन है।

  -(void)FormatAnswersInJSON { 
  
      DMInternetReachability *checkInternet = [[DMInternetReachability alloc] init]; 
      if ([checkInternet isInternetReachable]) { 
      if ([checkInternet isHostReachable:@"www.apple.com"]) {//Change to domain 
       responseArray = [[NSMutableArray alloc] init]; 
  
       dispatch_async(backgroundQueue, ^(void) { 
  
        NSArray *auditIDArray = [[NSArray alloc] initWithArray: [self getUnuploadedIDs]]; 
        for (int temp = 0; temp < [auditIDArray count]; temp ++) { 
  
         // Code to post JSON to server 
  
         NSURLResponse *response; 
         NSData *urlData=[NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error]; 
         if (!error) { 
          NSString *responseID = [[NSString alloc]initWithData:urlData encoding:NSUTF8StringEncoding]; 
          if ([responseID isEqualToString:@"ERROR"]) { 
           //Error uploading records 
          } else { 
           [responseArray addObject:responseID]; 
          } 
         } else { 
          //Error 
          return; 
         } 
        } 
        dispatch_async(backgroundQueue, ^{ 
  
         /* Based on return code update local DB */ 
         for (int temp = 0; temp < [responseArray count]; temp ++) { 
          [self updateRecordsForID:[auditIDArray objectAtIndex:temp] withID:[responseArray objectAtIndex:temp]]; 
         } 
        }); 
       }); 
      } 
      } 
  } 
  
  - (void)upload { //Called when internet connection available 
  
      if(backgroundQueue){ 
       dispatch_suspend(backgroundQueue); 
       dispatch_release(backgroundQueue); 
       backgroundQueue = nil; 
      } 
      backgroundQueue = dispatch_queue_create("com.XXXX.TestApp.bgqueue", NULL); 
      dispatch_async(backgroundQueue, ^(void) { 
       [self FormatAnswersInJSON]; 
      });  
  } 
  

Answer 1

यदि यह कोड मेरे सामने बैठे थे, मेरे दृष्टिकोण होगा: उपयोग के मामलों पर

• देखो और परिभाषित 'रिकॉर्ड की भारी संख्या': पर विल 50 रिकॉर्ड अपडेट एक समय नियमित रूप से होता है? या यह 1s और 2s में होगा? क्या मेरे उपयोगकर्ताओं के पास वाईफाई कनेक्शन हैं या यह भुगतान नेटवर्क पर है ?, आदि
• यदि संभव हो, तो जंगली में परीक्षण करें। यदि मेरा उपयोगकर्ता आधार काफी छोटा था, तो वास्तविक डेटा इकट्ठा करें और यह मेरे निर्णयों का मार्गदर्शन करने दें, या केवल उपयोगकर्ताओं/बीटा परीक्षणों और माप के उप-समूह में सुविधा को रिलीज़ करें।
• यदि डेटा आपको बताता है, तो इस कोड को और अधिक कुशल बनाने के लिए अनुकूलित करें।

अनुकूलन का मेरा एवेन्यू समूह प्रसंस्करण कर रहा होगा। किसी न किसी एल्गोरिदम कुछ ऐसा होगा:

for records in groups of X 
    collect 
    post to server { 
    on return: 
     gather records that updated successfully 
     update locally 
    } 

यह मानता है कि आप सर्वर कोड को संशोधित कर सकते हैं। आप 10, 20, 50, आदि के समूह कर सकते हैं। सभी डेटा भेजे जाने वाले प्रकार और आकार के आधार पर निर्भर करते हैं।

एक समूह एल्गोरिदम का मतलब थोड़ा अधिक प्रसंस्करण क्लाइंट पक्ष है, लेकिन HTTP अनुरोधों को कम करने का समर्थक है। यदि आपको केवल कुछ ही अपडेट प्राप्त होने जा रहे हैं, तो यह YAGNI और पूर्व परिपक्व अनुकूलन है।

इस निर्णय को आपको शिपिंग से न रखने दें!

Answer 2

आपके कोड में कुछ समस्याएं हैं। त्रुटि पैरामीटर का परीक्षण करने से पहले एक सम्मेलन हमेशा रिटर्न वैल्यू की जांच करना है। त्रुटि पैरामीटर सेट किया जा सकता है - भले ही विधि सफल हुई।

त्वरित नमूना या परीक्षण की तुलना में किसी भी चीज़ के लिए NSURLConnection का उपयोग करते समय, आपको हमेशा प्रतिनिधि विधियों को संभालने के साथ एसिंक्रोनस शैली का उपयोग करना चाहिए। चूंकि NSURLConnectionका उपयोग ठीक से तेजी से बोझिल और त्रुटि प्रवण हो सकता है, तो मैं एक तीसरे पक्ष के ढांचे का उपयोग करने का सुझाव दूंगा जो NSURLConnection ऑब्जेक्ट और NSOperation के उप-वर्ग के रूप में सभी कनेक्शन से संबंधित राज्य जानकारी को समाहित करता है। आप ऐप्पल नमूने में एक उदाहरण कार्यान्वयन पा सकते हैं: QHTTPOperation। एक अन्य उचित तृतीय पक्ष ढांचा AFNetworking (गिटहब पर) होगा।

जब आप प्रतिनिधि या तृतीय पक्ष उप-वर्ग के साथ एसिंक शैली का उपयोग करते हैं, तो आप कनेक्शन को रद्द कर सकते हैं, विस्तृत त्रुटि या प्रगति जानकारी पुनर्प्राप्त कर सकते हैं, प्रमाणीकरण कर सकते हैं और बहुत कुछ - जो आप सिंक्रोनस एपीआई के साथ नहीं कर सकते हैं।

मुझे लगता है कि, एक बार जब आप इसे पूरा कर लेंगे और आपका दृष्टिकोण सही तरीके से काम करता है, तो आप जांच सकते हैं कि प्रदर्शन स्वीकार्य है या नहीं। लेकिन जब तक आपके पास बड़ा डेटा न हो - कहें> 2 एमबीटी - मैं बहुत ज्यादा चिंता नहीं करता।

यदि आपका डेटा वास्तव में बड़ा हो जाता है, तो कहें> 10 MByte आपको अपने दृष्टिकोण को बेहतर बनाने के लिए विचार करने की आवश्यकता है। उदाहरण के लिए, आप PO12 डेटा को NSData ऑब्जेक्ट के बजाय फ़ाइल स्ट्रीम के रूप में प्रदान कर सकते हैं (NSURLRequest की संपत्ति HTTPBodyStream देखें)। एक स्ट्रीम का उपयोग रैम में सभी पोस्ट डेटा लोड करने से बचाता है जो सीमित रैम समस्या को कम करने में मदद करता है।

यदि आपके पास इसके बजाय छोटे POST डेटा हैं, लेकिन संभवतः उनमें से कई, तो आप NSOperationQueue का उपयोग करने पर विचार कर सकते हैं जहां आपने अपना NSOperation कनेक्शन सबक्लास रखा है। समवर्ती परिचालनों की अधिकतम संख्या 2 पर सेट करें। यह लीवरेज HTTP पाइपलाइनिंग - यदि सर्वर इसका समर्थन करता है, जो प्रभावी रूप से विलंबता को कम करता है।

बेशक, आपके ऐप में अन्य भाग हो सकते हैं, उदाहरण के लिए आप जो डेटा भेजना चाहते हैं उसे बना या पुनर्प्राप्त कर सकते हैं, जो समग्र प्रदर्शन को प्रभावित कर सकता है। हालांकि, यदि आपका कोड ध्वनि है और प्रेषण कतारों या NSOperations का उपयोग करता है जो चीजों को पैराल में निष्पादित करने देता है तो कनेक्शन के प्रदर्शन में सुधार करने के लिए कई और विकल्प नहीं हैं।