सीरियल

Question

का उपयोग किए बिना PHP में कैश ऑब्जेक्ट मेरे पास एक जटिल ऑब्जेक्ट है जो मैं एक PHP स्क्रिप्ट में बनाता हूं। मैं इस ऑब्जेक्ट को स्टोर करने का एक तरीका ढूंढ रहा हूं जैसे कि बाद के अनुरोधों को इसे फिर से बनाना नहीं है, या समय व्यतीत करने और इसे पुनर्निर्माण करने में समय व्यतीत करना है। Xdebug का उपयोग करके मुझे लगता है कि मैं इस ऑब्जेक्ट को बनाने के पूरे अनुरोध समय का आधा खर्च करता हूं। यहां तक ​​कि जब मैं ऑब्जेक्ट को एपीसी (या memcache) में स्पष्ट रूप से संग्रहीत करता हूं, तब भी इसे रद्द करने का समय और सभी वर्गों को लोड करने तक लगभग ऑब्जेक्ट को पहली जगह बनाने में लग जाता है।

मुझे नहीं पता कि स्टोर करना संभव है और बाद में PHP में "संकलित" ऑब्जेक्ट लोड करना संभव है। क्या यह संभव है? क्या अन्य समाधान हैं?

मुझे यकीन नहीं है कि यह संभव है, लेकिन मैंने सोचा कि मुझे समुदाय से पूछना चाहिए।

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

Answer 1

जहां तक ​​मुझे पता है, सीरियलाइजिंग के बिना PHP में वस्तुओं को कैश करना संभव नहीं है। सामान्यतः, कैशिंग तंत्र (एपीसी, मेमकेचे, इत्यादि) वास्तव में प्रदर्शन में सुधार (और इस प्रकार समग्र डीबी तनाव को कम करने) से अधिक डीबी कनेक्शन को हटाने की कोशिश कर रहे हैं। यह निश्चित रूप से कैसे memcache, et al emp Drupal के संबंध में निषिद्ध। दूसरे शब्दों में, कैशिंग तंत्र आपको स्केल करने की अनुमति दे सकते हैं, हालांकि वे विशेष रूप से प्रदर्शन में सुधार नहीं कर सकते हैं।
एक कैशिंग तंत्र को कार्यान्वित करने से आपको अधिक आसानी से बाहर निकलने की अनुमति मिलनी चाहिए, भले ही प्रति मशीन प्रदर्शन एक कनेक्शन के लिए पहले से बेहतर न हो। एक निश्चित दहलीज पर, डीबी प्रदर्शन तेजी से घट जाएगा, और कैशिंग तंत्र को उस मुद्दे को कम करने में मदद करनी चाहिए।

Answer 2

नहीं, एक गैर-धारावाहिक रूप में एक PHP ऑब्जेक्ट को स्टोर करना संभव नहीं है; कम से कम, नहीं के साथ निम्न संचय समाधानों ; (मैं इन लोगों की कोशिश की है दूसरे के बारे में पता नहीं है कि मौजूद हो सकता है):

• फ़ाइलों
• memcached
• एपीसी
• डाटाबेस (यीप, आप, डीबी में ^^ Drupal डिफ़ॉल्ट रूप से यह करता है बातें कैशिंग के बारे में सोच सकते हैं, उदाहरण के लिए)

यह है कि इतना ti लेता है मुझे आपकी वस्तु को बेअसर करने के लिए, शायद यह वास्तव में बड़ा है? क्या इसका कोई तरीका है जिससे आप इसका आकार कम कर सकते हैं?

उदाहरण के लिए, क्या आपके पास उस ऑब्जेक्ट में HTML कोड का एक बड़ा समूह है? यदि हां, तो क्या यह किसी अन्य कैश प्रविष्टि में संग्रहीत किया जा सकता है?
;

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

Answer 3

शायद समाधान एक एकल, भारी, महंगी वस्तु का निर्माण नहीं करना है।

यह देखते हुए कि एक PHP अनुप्रयोग प्रत्येक पृष्ठ लोड पर एक साफ स्लेट से बहुत अधिक शुरू होता है, एक समाधान जो एकल, विशाल वस्तु पर निर्भर करता है वह भाषा के लिए एक गरीब फिट है। चूंकि आप अपनी वस्तु & के बारे में बहुत अधिक जानकारी नहीं देते हैं, यह निश्चित नहीं हो सकता है, लेकिन मुझे संदेह होगा कि आपको प्रत्येक पृष्ठ लोड पर ऑब्जेक्ट की हर चीज की ज़रूरत नहीं है। यदि ऐसा है, तो आप इसे गंभीर, सरल वर्गों में विभाजित करने पर गंभीरता से विचार कर सकते हैं जिन्हें आप आवश्यकतानुसार तत्काल कर सकते हैं।

Answer 4

Igbinary PHP एक्सटेंशन में देखें। यह serialize और unserialize के प्रतिस्थापन में एक बूंद है और यह आपकी आवश्यकताओं के अनुरूप हो सकता है।

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

हालांकि यह किसी ऑब्जेक्ट को बेअसर करने की प्रक्रिया के माध्यम से जाता है, बाइनरी प्रारूप आपके एप्लिकेशन में उपयोग के लिए इस प्रक्रिया को उचित बनाने के लिए पर्याप्त प्रदर्शन बढ़ा सकता है।

Answer 5

इस मामले में एक बेहतर विकल्प आपके स्वयं के सर्वर लिखना होगा।

यह PHP में आसानी से करने योग्य है - और आपके पास पहले से ही कोड है - लेकिन जब सर्वर लिखने की बात आती है तो PHP सबसे अधिक पसंद नहीं हो सकता है।

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

Answer 6

igBinary एक उपयोगी विस्तार है जो आपको तेजी से धारावाहिक/अनिश्चित प्रक्रिया प्राप्त करने में मदद कर सकता है। यह एक मानक चालाकी, बाइनरी एक के साथ मानक serialization तंत्र की जगह लेता है। यदि आप अपना स्वयं का सर्वर प्रबंधित करते हैं और इसे इंस्टॉल कर सकते हैं, तो यह एक कोशिश के लायक है।

Answer 7

यदि आपके प्लेटफ़ॉर्म पर संभव हो तो एक साधारण डिमन लिखें जो स्टार्टअप पर आपके पेड़ को लोड करता है और सॉकेट पर अनुरोधों का उत्तर देता है। आपकी सर्वर प्रक्रिया पेड़ को पुनर्निर्माण किए बिना कांटा और उत्तर प्रश्नों का उत्तर दे सकती है। एक डेमॉन लिखना तुच्छ नहीं है, लेकिन बहुत अच्छी तरह से प्रलेखित (कम से कम सी के लिए)। आपको pcntl और posix एक्सटेंशन का उपयोग करके PHP में इसका अनुवाद करने में कोई परेशानी नहीं होनी चाहिए।

Answer 8

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

ध्यान दें कि PHP को तीन अलग-अलग स्कॉप्स कहा जा सकता है: एसएपीआई, जो प्रत्येक अनुरोध के भीतर सभी राज्यों को शुरू करता है और अंततः संभालता है; एक्सटेंशन, जो प्रत्येक अनुरोध ईवेंट शुरू होने से पहले शुरू किए जाते हैं; और उसके बाद स्क्रिप्ट स्कोप जिसे प्रत्येक अनुरोध द्वारा शुरू किया जाता है। सभी PHP वर्र्स स्क्रिप्ट स्कोप के भीतर शुरू किए जाते हैं, लेकिन दोनों एक्सटेंशन और एसएपीआई द्वारा एक्सेस किया जा सकता है। लेकिन एकमात्र दायरा जो प्रत्येक अनुरोध से परे मौजूद हो सकता है वह एसएपीआई है। दूसरे शब्दों में, एक PHP ऑब्जेक्ट केवल एसएपीआई के भीतर कई अनुरोधों में बनाए रखा जा सकता है (एक एक्सटेंशन इस समय इस समस्या से मदद नहीं कर सकता है), केवल एक कस्टम एसएपीआई अनुरोधों में zvals को बनाए रखने में सक्षम है।

Answer 9

आप अपने ऐप को ReactPHP पर फिर से लिख सकते हैं जो एक लंबे समय से चलने वाली PHP प्रक्रिया में वेबसर्वर बनाता है (जैसे कि नोड.जेएस या वेब.py)। फिर आप ग्लोबल वैरिएबल के रूप में एक बार (सर्वर स्टार्ट पर) अपनी बड़ी ऑब्जेक्ट बना सकते हैं और अनुरोध ईवेंट हैंडलर से इसे एक्सेस कर सकते हैं।