FtpWebRequest के प्रदर्शन में सुधार कैसे करें?

Question

मेरे पास .NET 3.5 में लिखा गया एक एप्लिकेशन है जो सर्वर से फ़ाइलों को अपलोड/डाउनलोड करने के लिए एफ़टीपी का उपयोग करता है। ऐप ठीक काम करता है लेकिन प्रदर्शन समस्याएं हैं:

1. एफ़टीपी सर्वर से कनेक्शन बनाने में काफी समय लगता है। एफ़टीपी सर्वर एक अलग नेटवर्क पर है और इसमें विंडोज 2003 सर्वर (आईआईएस एफ़टीपी) है। जब अपलोड के लिए कई फाइलें कतारबद्ध होती हैं, तो एक फ़ाइल से दूसरे में परिवर्तन एफ़टीपीवेबआरक्वेट का उपयोग करके एक नया कनेक्शन बनाता है और इसमें बहुत समय लगता है (लगभग 8-10 सेकेंड)।

2. कनेक्शन का पुन: उपयोग करना संभव है? मुझे KeepAlive संपत्ति के बारे में बहुत यकीन नहीं है। कौन से कनेक्शन जिंदा और पुन: उपयोग किए जाते हैं।

3. विंडोज सर्वर 2003 पर आईआईएस-एफ़टीपी एसएसएल का समर्थन नहीं करता है, इसलिए कोई भी वायरशर्क जैसे पैकेट स्निफ़ेर के माध्यम से आसानी से उपयोगकर्ता नाम/पासवर्ड देख सकता है। मैंने पाया कि विंडोज सर्वर 2008 आईआईएस 7.0 में अपने नए संस्करण में एफ़टीपी पर एसएसएल का समर्थन करता है।

मैं मूल रूप से अपने आवेदन के अपलोड/डाउनलोड प्रदर्शन में सुधार करना चाहता हूं। सभी विचार देने वालों का पहले से आभार।

** कृपया ध्यान दें कि 3 कोई मुद्दा नहीं है, लेकिन मैं लोगों को यह

Answer 1

निजी तौर पर पर टिप्पणी करने के लिए मैं अपने सभी ऐप्लिकेशन फ़ाइल अपलोड/डाउनलोड के लिए FTP का उपयोग करने से दूर चले गए चाहते हैं, और बदले में लुढ़का एक ASP.NET में एक्सएमएल वेब सेवाओं के आधार पर समाधान।

प्रदर्शन में काफी सुधार हुआ है, सुरक्षा उतनी ही कम है जितनी आप कोड करना चाहते हैं (और आप .NET में निर्मित सामग्री का उपयोग कर सकते हैं) और यह सभी बिना किसी समस्या के SSL पर जा सकते हैं।

हमारी सफलता दर अपने ग्राहकों के कनेक्शन को अपने फ़ायरवॉल के माध्यम से प्राप्त करने से एफएआर एफ़टीपी चलाने से बेहतर है।

Answer 2

KeepAlive काम कर रहा है। FtpWebRequest कैश कनेक्शन अंदर, इसलिए उन्हें कुछ समय बाद पुन: उपयोग किया जा सकता है। इस तंत्र के विवरण और स्पष्टीकरण के लिए आप ServicePoint देख सकते हैं।

जानकारी का एक और अच्छा स्रोत FtpWebRequest स्रोत (आप इसे VS2008 पर कर सकते हैं) में देखना है।

Answer 3

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

बीआईटीएस आईआईएस एक्सटेंशन का उपयोग कर HTTP/HTTPS पर काम करता है और कतारबद्ध अपलोड और डाउनलोड का समर्थन करता है जिसे कम प्राथमिकता पर निर्धारित किया जा सकता है। यदि आप क्लाइंट और सर्वर पर विंडोज का उपयोग कर रहे हैं तो यह एफ़टीपी की तुलना में बस इतना अधिक लचीला है।

BITS for PowerShell

BITS for .NET

Answer 4

इससे कोई फर्क नहीं पड़ता अगर व्यक्तिगत कनेक्शन जब तक कनेक्ट करने के लिए लंबे समय तक लेने के रूप में आप समानांतर में कई शुरू कर सकते हैं। यदि आपके पास स्थानांतरण करने के लिए कई वस्तुएं हैं (सैकड़ों कहें) तो BeginGetRequestStream और BeginGetResponse जैसे एसिंक्रोनस विधियों का उपयोग करके समानांतर में दसियों और सैकड़ों वेबरक्वेट लॉन्च करना भी समझदारी है।मैंने उन परियोजनाओं पर काम किया जो समान समस्याओं का सामना करते थे (लंबे समय से कनेक्ट/प्रमाणित समय) लेकिन समानांतर में कई कॉल जारी करके समग्र थ्रूपुट वास्तव में बहुत अच्छा था।

यदि आप use the async methods या सिंक्रोनस एक के साथ भी बहुत बड़ा अंतर डालते हैं, जैसे ही आपके पास कई (दसियों, सैकड़ों) अनुरोध हैं। यह न केवल आपके वेबरक्वेट विधियों पर लागू होता है, बल्कि अपलोड/डाउनलोड स्ट्रीम प्राप्त करने के बाद आपके स्ट्रीम read/write विधियों पर भी लागू होता है। The Improving .Net Performance and Scalability पुस्तक थोड़ी पुरानी है, लेकिन इसकी अधिकांश सलाह अभी भी खड़ी है, और ऑनलाइन पढ़ने के लिए स्वतंत्र है।

विचार करने की एक बात यह है कि ServicePointManager कक्षा एकमात्र उद्देश्य के साथ Framwework में छिपकर बैठती है: अपने प्रदर्शन को बर्बाद करने के लिए। सुनिश्चित करें कि आप अपने यूआरएल के obtain the ServicePoint और उचित मूल्य पर ConnectionLimit बदलें (कम से कम उतना ही उच्च जितना आप चाहते हैं कि कितने समवर्ती अनुरोध हैं)।

Answer 5

AFAIK, प्रत्येक FtpWebRequest को सर्वर पर लॉगऑन सहित एक नया कनेक्शन स्थापित करना होगा। यदि आप एफ़टीपी स्थानान्तरण को तेज करना चाहते हैं, तो मैं अनुशंसा करता हूं कि आप इसके बजाय वैकल्पिक एफ़टीपी क्लाइंट का उपयोग करें। इनमें से कुछ वैकल्पिक ग्राहक लॉगिन कर सकते हैं और फिर एक ही कमांड कनेक्शन का उपयोग करके कई क्रियाएं कर सकते हैं।

ऐसे क्लाइंट incldue के उदाहरण: http://www.codeproject.com/KB/IP/FtpClient.aspx जिसमें यह भी एक अच्छा स्पष्टीकरण शामिल है कि ये पुस्तकालय मानक FtpWebRequest और http://www.codeproject.com/KB/macros/ftp_class_library.aspx से अधिक तेज़ क्यों काम कर सकते हैं जो कि एक साधारण पर्याप्त कार्यान्वयन की तरह दिखता है।

व्यक्तिगत रूप से, मैंने एफटीपीवेबआरक्वेट पेश किए जाने से पहले 1.1 दिन पहले .NET में अपना एफ़टीपी वापस कार्यान्वित किया था और यह अभी भी .NET 2.0 के लिए अच्छा काम करता है।

Answer 6

मैं rsync पर स्विच करने की अनुशंसा करता हूं।
पेशेवर:
स्थानांतरण समय को कम करने के लिए अनुकूलित।
सुरक्षित हस्तांतरण
का उपयोग करता है के लिए SSH का समर्थन करता है टीसीपी तो अपने आईटी विभाग/फ़ायरवॉल लोग खुश

विपक्ष बनाता है:
कोई देशी नेट समर्थन
Linux सर्वर प्रतिष्ठानों की ओर तैयार - हालांकि वहाँ DeltaCopy

की तरह सभ्य खिड़कियों बंदरगाह हैं

कुल मिलाकर, हालांकि यह एफ़टीपी की तुलना में काफी बेहतर विकल्प है

Answer 7

मैं EDT के एफ़टीपी पुस्तकालय के साथ अच्छे परिणाम मिले थे:

इस पेज पर

http://www.enterprisedt.com/products/edtftpnet/overview.html

Answer 8

देखो - http://www.ietf.org/rfc/rfc959.txt

यह अलग बंदरगाह का उपयोग करते समय कनेक्शन पुन: उपयोग करने में सक्षम होना जोड़ने का कहते हैं।
क्या यह काम करता है?

Answer 9

डीबग नेटवर्क

सरल नेटवर्क डिबगिंग के लिए कुछ गुर:

1. चेक प्रतिक्रिया समय है जब आप आवेदन सर्वर से FTP सर्वर को पिंग।
2. एक ट्रेस मार्ग के लिए प्रतिक्रिया समय की जांच करें (tracert एक डॉस खोल से)।
3. ftp कमांड का उपयोग कर कमांड लाइन से फ़ाइल को स्थानांतरित करें।
4. टेलीनेट के माध्यम से एफ़टीपी सर्वर से कनेक्ट करें: telnet server 21।

परिणाम समस्या को हल करने के लिए संकेत प्रदान करेंगे।

नेटवर्क हार्डवेयर

एक धीमी गति से ट्रेस मार्ग के लिए:

• निर्धारित क्यों दो कंप्यूटर नेटवर्क मुद्दों कर रहे।
• सबसे धीमे लिंक के बीच नेटवर्क हार्डवेयर को अपग्रेड करें।

नेटवर्क कॉन्फ़िगरेशन

एक धीमी गति से पिंग के लिए:

• चेक प्रत्येक मशीन पर नेटवर्क विन्यास।
• सुनिश्चित करें कि सेटिंग्स इष्टतम हैं।

मान्य एपीआई

एक धीमी कमांड लाइन FTP सत्र आपको बताएगा कि समस्या एफ़टीपी एपीआई का उपयोग कर रहे करने के लिए अलग नहीं है। यह एपीआई को एक संभावित समस्या के रूप में खत्म नहीं करता है, लेकिन निश्चित रूप से यह कम संभावना बनाता है।

नेटवर्क त्रुटियाँ

पैकेट स्रोत और गंतव्य के बीच गिरा दिया जा रहा है, पिंग आपको बता देंगे। किसी भी त्रुटि को देखने के लिए आपको पैकेट आकार को 1500 बाइट्स में बढ़ाना पड़ सकता है।

एफ़टीपी कतार सर्वर

एक मध्यस्थ के सर्वर आप गंतव्य FTP सर्वर पर कोई नियंत्रण नहीं है, तो है अपलोड की गई फ़ाइलों प्राप्त करते हैं। मध्यस्थ तब फ़ाइलों को दूरस्थ सर्वर पर भेजता है जो भी हो सकता है। यह भ्रम देता है कि फ़ाइलों को जल्दी से भेजा जा रहा है। हालांकि, अगर फ़ाइलों को रिमोट सर्वर पर अपलोड होने के तुरंत बाद मौजूद होना चाहिए, तो यह समाधान व्यवहार्य नहीं हो सकता है।

एफ़टीपी सर्वर सॉफ्टवेयर

एक अलग एफ़टीपी डेमॉन FTP सर्वर पर, इस तरह के ProFTPd के रूप में एक Windows service के रूप में प्रयोग करें। (Proftpd विभिन्न डेटाबेस प्रमाणीकरण का उपयोग एसक्यूएल क्वेरी की अनुमति देते के लिए प्लग-इन है।)

FTP सर्वर ऑपरेटिंग सिस्टम

एक यूनिक्स आधारित ऑपरेटिंग सिस्टम के लिए एक Microsoft आधारित एक से एक बेहतर विकल्प हो सकता है।

एफ़टीपी क्लाइंट सॉफ़्टवेयर

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

वैकल्पिक प्रोटोकॉल

तो एफ़टीपी एक निरपेक्ष आवश्यकता नहीं है, कोशिश:

• एक Windows नेटवर्क ड्राइव
• HTTPS
• SCP, rsync, या इसी तरह के कार्यक्रमों (Cygwin हो सकता है आवश्यक)

Answer 10

मैं दृढ़ता से Starksoft FTP/FTPS Component for .NET and Mono का सुझाव देता हूं। इसमें एक कनेक्शन ऑब्जेक्ट है जिसे आप कैश और पुन: उपयोग कर सकते हैं।

Answer 11

मैं कुछ प्रयोग

KeepAlive निम्नलिखित कारकों के साथ FtpWebRequest पर (विभिन्न आकारों पर के बारे में 20 फ़ाइलों को अपलोड) किया है = सही/गलत

ftpRequest.KeepAlive = isKeepAlive; 

connnection समूह का नाम = UserDefined या शून्य

ftpRequest.ConnectionGroupName = "MyGroupName"; 

कनेक्शन सीमा = 2 (डिफ़ॉल्ट) या 4 या 8

ftpRequest.ServicePoint.ConnectionLimit = ConnectionLimit; 

मोड = तुल्यकालिक या Async

देख this example

मेरे परिणाम:

1. उपयोग कनेक्शन समूहनाम, KeepAlive = सच लिया (21188.62 मीटर सेकंड)

2. उपयोग ConnectionGroupName, KeepAlive = false (53,449.00 msec) ले लिया

3. नहीं ConnectionGroupName, KeepAlive = false लिया (40,335.17 msec)

4. उपयोग ConnectionGroupName, KeepAlive = true async = सच है, कनेक्शन = 2 लिया (11,576.84 msec)

5. उपयोग ConnectionGroupName, KeepAlive = true async = सच है, कनेक्शन = 4 लिया (10,572.56 msec)

6. कनेक्शन समूह का उपयोग करें, KeepAlive = true; async = true, कनेक्शन = 8 लिया (10598।76 msec)

निष्कर्ष

1. FtpWebRequest एक आंतरिक कनेक्शन पूल का समर्थन करने के डिजाइन किया गया है। यह सुनिश्चित करने के लिए, कनेक्शन पूल का उपयोग किया जाता है, हमें यह सुनिश्चित करना होगा कि ConnectionGroupName सेट किया जा रहा है।

2. कनेक्शन सेट करना महंगा है। यदि हम एक ही प्रमाण पत्र का उपयोग कर एक ही FTP सर्वर से कनेक्ट कर रहे हैं, तो जीवित ध्वज को सत्य पर सेट रखने से कनेक्शन सेटअप की संख्या कम हो जाएगी।

3. असीमित्रोनस अनुशंसित तरीका है यदि आपके पास ftp करने के लिए बहुत सी फाइलें हैं।

4. कनेक्शन की डिफ़ॉल्ट संख्या 2 है। मेरे पर्यावरण में, 4 की कनेक्शन सीमा मुझे सबसे अधिक प्रदर्शन लाभ प्रदान करेगी। कनेक्शन की संख्या में वृद्धि प्रदर्शन में सुधार हो सकता है या नहीं। मैं अनुशंसा करता हूं कि आपके पास कॉन्फ़िगरेशन पैरामीटर के रूप में कनेक्शन सीमा है ताकि आप इस पैरामीटर को अपने पर्यावरण में ट्यून कर सकें।

आशा है कि आपको यह उपयोगी लगेगा।

Answer 12

यह लिंक वर्णन ConnectionGroupName और KeepAlive प्रभावित करता है: WebRequest ConnectionGroupName

Answer 13

एकल सलाह सूत्र:

कम बफर/हिस्सा-आकार प्रदर्शन में काफी कम

कारण: कई और डिस्क मैं/हे, स्मृति i/o, ftp स्ट्रीम init और कई अन्य कारक

Answer 14

प्रदर्शन के बारे में समस्या को हल करने के लिए आपको बस सेट करने की आवश्यकता है:

ftpRequest.ConnectionGroupName = "MyGroupName"; ftpRequest.KeepAlive = false; ftpRequest.ServicePoint.CloseConnectionGroup("MyGroupName");

Answer 15

मुझे पता है कि यह एक पुराना धागा है, लेकिन मुझे हाल ही में इसी तरह की स्थिति से गुजरना पड़ा।

हमें उस समय-फ्रेम के दौरान 5 से अधिक कनेक्शन खोलने के बिना 25 मिनट से कम समय में एक FTP सर्वर से 70+ एक्सएमएल फ़ाइलों को डाउनलोड करने की आवश्यकता थी। गया था तेजी से यह, लेकिन हर एक नए कनेक्शन का मतलब है -

• wget:

  ये सभी विकल्प हम करने की कोशिश की थी। हमें बनाए गए कनेक्शन की मात्रा के कारण रोकना पड़ा। हमें जीईटीएम के साथ कुछ समस्याएं थीं जो वेब में अच्छी तरह से प्रलेखित है ताकि यह एक विकल्प न हो।

• FtpWebRequest - प्रत्येक बनाएं कॉल एक नया कनेक्शन लॉग करेगा, भले ही हमने KeepAlive और ConnectionGroupName गुणों का उपयोग किया हो। इसके अलावा यह बहुत धीमी थी।
• वेब क्लाइंट - हमने यह जांच नहीं की कि क्या उसने प्रत्येक फ़ाइल के लिए एक नया कनेक्शन बनाया है (हालांकि मुझे लगता है कि यह करता है), लेकिन यह 1 फ़ाइल/मिनट की प्रतिलिपि बनाई गई। तो यह एक विकल्प नहीं था।

हम पुरानी शैली वाली एफटीपी बैच स्क्रिप्ट का उपयोग कर समाप्त हो गए। यह तेज़ है और मैं केवल सभी फाइलों को डाउनलोड करने के लिए एक कनेक्शन का उपयोग करता हूं। यह लचीला नहीं है, लेकिन यह सब कुछ मैंने कोशिश की है (75 फाइलें 20 मिनट से कम) की तुलना में बहुत तेज़ है।

Answer 16

मैं इसके साथ कुछ दिनों काम कर रहा था ... और गति वास्तव में कम थी, फ़ाइलज़िला से तुलना करने के लिए कुछ भी नहीं ... आखिर में मैंने मल्टीथ्रेड के साथ हल किया। 10 धागे डाउनलोड के लिए कनेक्शन बनाने के लिए मुझे एक अच्छा दर देता है, हो सकता है और भी .. एक standar ftprequest विन्यास के साथ सुधार किया जा सकता

PeticionFTP.ConnectionGroupName = "MyGroupName" 
PeticionFTP.ServicePoint.ConnectionLimit = 4 
PeticionFTP.ServicePoint.CloseConnectionGroup("MyGroupName") 

PeticionFTP.KeepAlive = False 
PeticionFTP.UsePassive = False 

PeticionFTP.UseBinary = True 

PeticionFTP.Credentials = New NetworkCredential(lHost.User, lHost.Password) 

Answer 17

कोड नीचे इस प्रयास करें, तो आप बेहतर प्रदर्शन मिल जाएगा:

private void Upload144_Click(object sender, EventArgs e) 
{ 
    OpenFileDialog fileobj = new OpenFileDialog(); 
    fileobj.InitialDirectory = "C:\\"; 
    //fileobj.Filter = "Video files (*.mp4)"; 
    //fileobj.ShowDialog(); 

    if (fileobj.ShowDialog() == DialogResult.OK) 
    { 
     if (fileobj.CheckFileExists) 
     { 
      string test = Properties.Settings.Default.Connection; 
      SqlConnection con = new SqlConnection(test); 
      con.Open(); 
      string correctfilename = System.IO.Path.GetFileName(fileobj.FileName); 
      SqlCommand cmd = new SqlCommand("Insert into Path(ID,Path5) VALUES ((select isnull(MAX(id),0) + 1 from Path),'\\Videos\\" + correctfilename + "')", con); 

      cmd.ExecuteNonQuery(); 

      string path = Application.StartupPath.Substring(0, Application.StartupPath.Length - 10); 
      con.Close(); 

      //For Progressbar 
      DataTable dt = new DataTable(); 
     // SqlDataAdapter da = new SqlDataAdapter(cmd); 
     // da.Fill(dt); 

      timer5.Enabled = true; 

      // FOR FtpServer File Upload:: 
      string uploadfile = fileobj.FileName; 
      string uploadFileName = new FileInfo(uploadfile).Name; 

      string uploadUrl = "ftp://ftp.infotech.com/"; 
      FileStream fs = new FileStream(uploadfile, FileMode.Open, FileAccess.Read); 
      try 
      { 
       long FileSize = new FileInfo(uploadfile).Length; // File size of file being uploaded. 
       Byte[] buffer = new Byte[FileSize]; 

       fs.Read(buffer, 0, buffer.Length); 

       fs.Close(); 
       fs = null; 
       string ftpUrl = string.Format("{0}/{1}", uploadUrl, uploadFileName); 
       FtpWebRequest requestObj = FtpWebRequest.Create(ftpUrl) as FtpWebRequest; 
       requestObj.Method = WebRequestMethods.Ftp.UploadFile; 
       requestObj.Credentials = new NetworkCredential("test@sample.com", "test@123"); 
       Stream requestStream = requestObj.GetRequestStream(); 
       requestStream.Write(buffer, 0, buffer.Length); 

       requestStream.Flush(); 
       requestObj = null; 
      } 
      catch (Exception ex) 
      { 
       //MessageBox.Show("File upload/transfer Failed.\r\nError Message:\r\n" + ex.Message, "Succeeded", MessageBoxButtons.OK, MessageBoxIcon.Information); 
      } 
     } 
    } 
}