2008-10-01 11 views
7

मैं एसक्यूएल सर्वर 2000 डेटाबेस के साथ सी # में लिखे गए एएसपीनेट एप्लिकेशन पर काम कर रहा हूं। हमारे पास कई पीडीएफ रिपोर्ट हैं जो ग्राहक अपनी व्यावसायिक जरूरतों के लिए उपयोग करते हैं। समस्या यह है कि इन रिपोर्टों को उत्पन्न करने में कुछ समय लगता है (> 3 मिनट)। आम तौर पर क्या होता है जब उपयोगकर्ता रिपोर्ट का अनुरोध करता है कि वेब सर्वर के पास रिपोर्ट उत्पन्न करने का समय समाप्त होने से पहले अनुरोध टाइमआउट अनुरोध को मारता है, इसलिए उपयोगकर्ता को फ़ाइल डाउनलोड करने का मौका कभी नहीं मिलता है। फिर उपयोगकर्ता पृष्ठ को रीफ्रेश करेगा और फिर से प्रयास करेगा, जो पूरी रिपोर्ट जनरेशन प्रक्रिया को शुरू करता है और अभी भी समय समाप्त हो जाता है। (नहीं, हम अभी रिपोर्ट कैश नहीं कर रहे हैं; यह कुछ है जिसके लिए मैं कड़ी मेहनत कर रहा हूं ...)।लंबे समय तक चलने वाली रिपोर्टों को संभालना

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

क्या कोई आसान तरीका है जिसे मैं नहीं देख रहा हूं?

उत्तर

5

यहां फाइल सिस्टम का उपयोग करना शायद एक अच्छी शर्त है। एक अनुरोध है कि तुरंत रिपोर्ट पीडीएफ स्थान पर एक यूआरएल लौटाता है। आपका सर्वर या तो बाहरी प्रक्रिया को निकाल सकता है या रिपोर्टिंग करने के लिए खुद को एक अनुरोध भेज सकता है। ग्राहक आपूर्ति किए गए यूआरएल पर पीडीएफ के लिए सर्वर (http HEAD का उपयोग कर) मतदान कर सकता है। यदि आप पीडीएफ का फ़ाइल नाम रिपोर्ट पैरामीटर से प्राप्त करते हैं, या तो हैश का उपयोग करके या पैरामीटर को सीधे नाम में डालकर आपको तत्काल सर्वर साइड कैशिंग भी मिल जाएगी।

1- उन टाइमआउट बंद करो:

+0

क्या आप विस्तृत कर सकते हैं कि ग्राहक http HEAD का उपयोग कर सर्वर को कैसे मतदान कर सकता है। मुझे मतदान विचार पसंद है, हालांकि मैं मतदान के लिए जावास्क्रिप्ट का उपयोग करने की योजना बना रहा था। क्या कोई आसान तरीका है? –

+0

आप जावास्क्रिप्ट से हेड अनुरोध भेज सकते हैं, http://www.jibbering.com/2002/4/httprequest.html संभवतः मदद के लिए jquery/अन्य बड़ी जेएस पुस्तकालयों में कुछ लुढ़का हुआ है। – user7375

1

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

+0

यह मेरा पहला विचार था, लेकिन हमारे सिस्टम के उपयोगकर्ताओं को ईमेल पते की आवश्यकता नहीं है। अन्यथा, अच्छा सुझाव। –

4

मैं इस रिपोर्ट को प्रसंस्करण बिंदु से कुछ और ऑफलाइन बनाने पर विचार करता हूं।

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

शायद मैं कतार संभालने के लिए एक अलग विंडोज सेवा भी तैयार करूंगा।

अद्यतन: उपयोगकर्ता को भेजना ईमेल हो सकता है या उनके पास 'रिपोर्ट' पृष्ठ हो सकता है, जहां वे अपनी रिपोर्ट की स्थिति देख सकते हैं और अगर वे तैयार हैं तो उन्हें डाउनलोड कर सकते हैं।

2

आपके उपयोगकर्ताओं को इस दृष्टिकोण को स्वीकार कर सकते है, लेकिन:

वे एक रिपोर्ट का अनुरोध करते हैं (एक बटन या एक लिंक या जो कुछ भी क्लिक करके), तो आपको एक अलग थ्रेड पर रिपोर्ट उत्पन्न करने की प्रक्रिया शुरू कर सकता है, और फिर से उपयोगकर्ता को उस पृष्ठ पर निर्देशित करें जो कहता है "धन्यवाद, आपकी रिपोर्ट आपको कुछ मिनटों में ईमेल कर दी जाएगी"।

जब धागा रिपोर्ट उत्पन्न होता है, तो आप सीधे पीडीएफ ईमेल कर सकते हैं (शायद आकार के कारण काम नहीं करेंगे), या सर्वर पर रिपोर्ट को सहेज लें और उपयोगकर्ता को एक लिंक ईमेल करें।

वैकल्पिक रूप से, आप आईआईएस में जा सकते हैं और टाइमआउट को> 3 मिनट तक बढ़ा सकते हैं।

2

यहाँ से कुछ चीजों के मुझे लगता है मैं इस समस्या को प्रस्तुत किया जाएगा यदि करना होगा है! वे संसाधनों का कुल अपशिष्ट हैं।(एएसपी पृष्ठों का टाइमआउट मान लाएं)

2- एक ही बिंदु में सभी डीबी एक्सेस को केंद्रीकृत करें, फिर आंकड़ों को इकट्ठा करें कि किस रिपोर्ट के दौरान और कितना समय लगा। जांच करें कि यह इतनी देर क्यों लेता है, क्या यह रिपोर्ट जटिलता के कारण है? डेटा रेंज़? सर्वर लोड? (आप वास्तव में सर्वर पर एक .csv फ़ाइल पर लिख सकते हैं और बाद में विश्लेषण करने के लिए एसक्यूएल सर्वर में इस फ़ाइल को समय-समय पर आयात कर सकते हैं)।

आखिरकार, यह आसान आप के लिए "कैश" रिपोर्ट के लिए अगर आप इस एक पहुँच बिंदु के माध्यम से जाना हो जायेगा

3 (उदाहरण के लिए, एक ही क्वेरी में एक ही तिथि पहले से उत्पन्न एक ही पीडीएफ वापस आ जाएगी) मैं वास्तव में यह जानते सवाल नहीं था, लेकिन क्या आपने उन प्रश्नों में डाइविंग करने की कोशिश की है ताकि वे यह देख सकें कि वे इतने लंबे समय तक क्यों चल रहे हैं? क्वेरी ट्यूनिंग शायद?

4- रिपोर्ट तैयार होने पर ईमेल/एसएमएस/स्क्रीन संदेश पर बहुत अच्छा लगता है ... यदि आपका उपयोगकर्ता आमतौर पर उत्पन्न होने वाली रिपोर्ट का बैच भेजता है तो शायद "डैश" की प्रगति का संकेत देने वाला एक छोटा डैशबोर्ड बनाया जा सकता है एप्लिकेशन। थोड़ा AJAX नियंत्रण समय-समय पर स्थिति को रीफ्रेश करेगा .. संकेत: यदि आपने उस केंद्रीय डीबी एक्सेस का उपयोग किया है और आपके पास पर्याप्त जानकारी है कि आप कब और कितनी देर तक अंततः अनुमान लगा सकते हैं कि यह समय के लिए कितना समय लगेगा चलाने के लिए रिपोर्ट करें।

यदि प्रतिक्रिया समय मिशन महत्वपूर्ण है, तो कुछ उपयोगकर्ताओं को दिन के कुछ घंटों के दौरान डेटा रेंज (उदाहरण के लिए दिनांक सीमा) में सीमित होना चाहिए?

गुड लक और अपने परिदृश्य के बारे में अधिक विवरण पोस्ट करें आपको और अधिक सटीक संकेत प्राप्त करना चाहते हैं, तो ...

2

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

क्वेरी को देखने में आपको जो मिल रहा है उसके आधार पर, आपको कुछ इंडेक्स जोड़ने की संभावना हो सकती है, या संभवतः इसे एक रिपोर्ट को सेट अप करने के लिए एक तालिका को सेट अप करने के लिए भी एक तालिका सेट अप करने की आवश्यकता हो सकती है, ताकि इसे तेजी से उपलब्ध कराया जा सके। इस denormalized तालिका को हर घंटे ताज़ा किया जा सकता है (एक SQL सर्वर नौकरी के माध्यम से), या जो भी आवृत्ति आपकी आवश्यकताओं को निर्देशित (कारण के भीतर) के साथ।

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

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

संबंधित मुद्दे

 संबंधित मुद्दे