PHP में ऑब्जेक्ट कितनी मेमोरी का उपभोग करते हैं और क्या यह 64-बिट संस्करण का उपयोग करने के लायक है?

यह पोस्ट मेरे वर्तमान बड़े ZendFramework प्रोजेक्ट के लिए मेमोरी खपत के अध्ययन से प्रेरित थी। हमेशा की तरह, अध्ययन के परिणामों के अनुसार, हम अपने प्रोग्रामेटिक अहंकार से हैरान थे, जो अक्सर तब होता है जब हम PHP में कुछ बड़ा लिखते हैं। और, शायद, न केवल PHP में।

लेकिन पहले बातें पहले।

यह लेख निम्नलिखित लेखों की एक तार्किक निरंतरता है:

• मेमोरी के साथ काम करना (और अभी तक यह है)
• PHP में सरणियाँ (और मान) कितनी बड़ी हैं? (संकेत: बहुत बड़ा)

हम कैसे मापेंगे

शुरू करने के लिए, हम यह निर्धारित करेंगे कि हम "वजन" को कैसे मापेंगे। यहाँ टेम्प्लेट है:

$startMemory = 0; $startMemory = memory_get_usage(); //  echo (memory_get_usage() - $startMemory) . ' bytes' . PHP_EOL; 

ऐसा टेम्पलेट नई आवंटित मेमोरी को मापने के लिए उपयुक्त है, अर्थात, चर के लिए मेमोरी। लेकिन यह मापना असंभव है कि कार्यों, कक्षाओं के विवरण, अर्थात्, इस दृष्टिकोण से खाया जाता है, क्योंकि वे स्क्रिप्ट शुरू होने से पहले स्मृति में संग्रहीत होते हैं। परिभाषाओं को मापने के लिए, हम निम्नलिखित टेम्पलेट का उपयोग करते हैं:

 $startMemory = 0; $startMemory = memory_get_usage(); //  include $testfile; echo (memory_get_usage() - $startMemory - $include_overhead) . ' bytes' . PHP_EOL; 

जहां $ शामिल_ओवरहेड अपनी आंतरिक आवश्यकताओं को फिट करने के लिए शामिल विवरण खपत कितना है। इस लेख में, हम अध्ययन नहीं करेंगे कि हम $ शामिल_कोहेड को कैसे माप सकते हैं। मैं केवल इस बात पर ध्यान देता हूं कि खपत की गई मेमोरी का आकार 3 चीजों पर निर्भर करता है:

• पूर्ण फ़ाइल पथ लंबाई
• इस फ़ाइल को कैसे शामिल किया गया (प्रत्येक 8, 16, 32, 64 आदि, आंतरिक संरचनाओं के लिए एक अतिरिक्त चयन है)
• PHP की आंतरिक संरचनाओं की पूर्णता ही, जो समय-समय पर भविष्य के लिए स्मृति आवंटित करती है।

अगर किसी को भी इस खोज को गहराई से जानने में दिलचस्पी है, तो आप फ़ाइल run.include-test.php की जांच कर सकते हैं, यह शामिल के दौरान मेमोरी खपत की असमानता को अच्छी तरह से दर्शाता है। मैं यह भी ध्यान देता हूं कि नीचे दिए गए सभी परीक्षणों में हम लगभग $ $__ को मापते हैं, क्योंकि हमें सटीक मानों की आवश्यकता नहीं है, लेकिन 32-बिट और 64-बिट संस्करणों के बीच की प्रवृत्ति और अंतर।

कितना "वस्तुओं" वजन करते हैं

इसलिए टेस्टसुइट को बड़ी संख्या में परीक्षण स्वचालित रूप से चलाने के लिए लिखा गया था। सभी परीक्षण UbuntuBox 12.04.1 LTS i386 और Ubuntu 12.04.1 LTS amd64 के लिए वर्चुअलबॉक्स में चलाए गए थे। PHP संस्करण - 5.3.10, ZendFramework - 1.11.11। कंसोल में चलने का आदेश:

 php run.testsuite-without-accelerator.php 

इसके अतिरिक्त, मैंने नियंत्रण के लिए Gentoo amd64 के साथ अपनी मशीन पर एक परीक्षण किया। कंसोल से लॉन्च किए जाने पर PHP एक्सीलेटर काम नहीं करते हैं। यहाँ परिणाम हैं:

टेस्ट नाम	विवरण	उबंटू x86, PHP 5.3.10, जेडएफ 1.11.11	उबंटू x86-64, PHP 5.3.10, जेडएफ 1.11.11	जेंटू x86-64, PHP 5.3.15, जेडएफ 1.11.4
a.mention_variable	परिवर्तनीय मेंशन	44	80	48
a.new_null_variable	एक नया अशक्त चर बनाना	108	208	144
a.unset_null_variable	चर हटाएं	-108	-208	-144
stdClass.new	वस्तु निर्माण	120	232	168
stdClass.tovar1	एक वस्तु बनाना और इसे $ a लिंक करना	264	512	352
stdClass.tovar2_unset_and_thesame	लिंक $ a और रीक्रिएट लिंक $ a हटाएं	0	0	0
stdClass.tovar3_unset_and_another	लिंक $ a हटाएं और लिंक $ b बनाएं	0	0	0
stdClass.tovar4_another	एक वस्तु का निर्माण करना और इसे $ c लिंक करना	264	512	352
stdClass.tovar5_addlink	$ A को उसी वस्तु से $ b के रूप में लिंक करें	64	128	96
stdClass.z.free_memory	$ A, $ b और $ c लिंक हटाना	-592	-1152	-800
myclass.a.empty	कक्षा एक विवरण	700	1344	1128
myclass.aa.interface	इंटरफ़ेस विवरण ए	700	1344	1128
myclass.ab.final	अंतिम वर्ग एबी का विवरण	700	1344	1128
myclass.ac.abstract	एसी अमूर्त वर्ग विवरण	700	1344	1128
myclass.b.extended.empty	कक्षा बी का विस्तार ए	700	1344	1128
myclass.c.empty.namespace	खाली नामस्थान C का विवरण	0	0	0
myclass.d.construct	क्लास डी कंस्ट्रक्टर विवरण	1104	2288	1920
myclass.dd.method	विधि के साथ डीडी वर्ग विवरण	1088	2280	1912
myclass.ddd.private.var	एक निजी चर के साथ DDD वर्ग का विवरण	960	1840	1472
myclass.dddd.public.var	सार्वजनिक चर के साथ DDDD वर्ग का विवरण	960	1840	1472
myclass.ddddd.static.var	एक स्थिर चर के साथ DDDDD वर्ग का विवरण	960	1840	1472
myclass.e.extended.destruct	कक्षा डी के विस्तारक के साथ वर्ग ई का विवरण	1344	2704	2272
myclass.e.instance.ab	एक एबी ऑब्जेक्ट और $ ई लिंक इसे बनाने के लिए	264	512	352
myclass.e.instance.ddddd	एक DDDDD ऑब्जेक्ट और $ ई लिंक को इससे बनाना	0	0	0
myclass.e.instance.e	एक वस्तु ई बनाएँ और इसे $ ई लिंक करें	0	0	0
myclass.f.instance.ddddd	एक DDDDD ऑब्जेक्ट और $ f लिंक का निर्माण करना	264	512	352
myclass.z.free_memory	$ ई, $ च लिंक हटाना	-484	-944	-656
zend.a.init.autoload	ZendFramework के लिए ऑटोलॉड की शुरुआत	127 444	276,288	249 232
zend.a.init.model	आधार के लिए डिफ़ॉल्ट एडेप्टर की शुरुआत	1 018 388	२ ०१ ६००	1 871 256
zend.extended.controller1	Zend_Controller_Action से नियंत्रक परिभाषा। रास्ते के साथ, मानक Zend कक्षाएं लोड करना	378,296	809 384	712 816
zend.extended.controller2	नियंत्रक परिभाषा Zend क्लास पहले से ही भरी हुई है, देखें कि हमारी क्लास का वजन कितना है	११ ३२ 11	19 608	16,008
zend.extended.model1	Zend_Db_Table द्वारा मॉडल परिभाषा। रास्ते के साथ, मानक Zend कक्षाएं लोड होती हैं।	२ ९ ३६	४। ५४४	४० २२४
zend.extended.model2	मॉडल की परिभाषा। Zend क्लास पहले से ही भरी हुई है, देखें कि हमारी क्लास का वजन कितना है	२ ९ ३६	४। ५३६	40 208
zend.use.model1.e.instance1	एक Model1 ऑब्जेक्ट और $ e इससे लिंक करें	2492	4648	3432
zend.use.model1.f.instance2	एक Model1 ऑब्जेक्ट बनाना और इसे $ f से लिंक करना	1764	3256	2488
zend.use.model1.g.instance3	Model1 ऑब्जेक्ट और $ g लिंक को इससे बनाना	1764	3256	2488
zend.use.model2.e.instance1	एक Model2 ऑब्जेक्ट और $ ई लिंक इसे बनाने के लिए	740	1400	944
zend.use.model2.f.instance2	एक Model2 ऑब्जेक्ट बनाना और $ f संदर्भ इसके लिए	0	0	0

आप देख सकते हैं कि जेंटू का निर्माण 10-20% कम मेमोरी का उपभोग करता है, और दुर्लभ मामलों में, बचत 50% तक आती है। जाहिरा तौर पर, आंतरिक संरचनाओं का आकार प्रोसेसर के लिए अनुकूलन पर निर्भर करता है। प्रयोग के लिए, मैंने सीएफएलएजीएस के विभिन्न संस्करणों के साथ पीएचपी का पुनर्निर्माण किया, लेकिन इस से अधिक उपभोग करना शुरू नहीं किया। जाहिर है, अंतर स्वयं पीएचपी के पुनर्निर्माण के कारण प्रकट नहीं होता है, लेकिन मानक सिस्टर्न पुस्तकालयों के पुनर्निर्माण से।

जैसा कि ऊपर उल्लेख किया गया है, इसमें $ शामिल_ओवरहेड को सटीक रूप से मापना मुश्किल है, इसलिए यदि आप इन परीक्षणों को चलाते हैं, तो आपको उन मेमोरी की खपत हो सकती है जो 4, 8, 12, 16 बाइट्स में कूदती हैं, यहां तक ​​कि उन परीक्षणों में भी जिनका उपभोग करना चाहिए। इस पर ध्यान मत दो। मैंने परीक्षणों को एक अलग क्रम में चलाया और कमोबेश सही मेमोरी खपत को निर्धारित किया।

आइए ZendFramework से संबंधित परीक्षणों के बारे में बात करते हैं। मेमोरी में Zend की क्लास परिभाषा को लोड करना महत्वपूर्ण संसाधनों को खाता है, जबकि ऑब्जेक्ट संदर्भ पहले से ही इतना उपभोग नहीं करते हैं। नियंत्रक इंटरमीडिएट को यह जांचने की आवश्यकता है कि यदि सभी मध्यवर्ती कक्षाएं पहले से ही स्मृति में हैं तो एक समान नियंत्रक कितना खाएगा। Model2 उसी उद्देश्य के लिए बनाया गया है।
संभावित रूप से, PHP त्वरक का उपयोग करके हमें सभी परिभाषाओं पर मेमोरी को बचाएगा, क्योंकि वे पहले से ही मेमोरी में संग्रहीत होंगे। आइए इस कथन की जाँच करें।

त्वरक परीक्षण

एपीसी को परीक्षण के लिए लिया गया था, और परीक्षण एक स्क्रिप्ट का उपयोग करके वेब के माध्यम से चलाए गए थे:

 php run.testsuite-with-accelerator.php 

परिणाम केवल उन्हीं परीक्षणों को दर्शाते हैं जहाँ त्वरक का प्रभाव होता है:

टेस्ट नाम	विवरण	उबंटू x86, PHP 5.3.10, ZF 1.11.11, खाली कैश	उबंटू x86, PHP 5.3.10, ZF 1.11.11, ताज़ा करना	उबंटू x86-64, PHP 5.3.10, ZF 1.11.11, खाली कैश	उबंटू x86-64, PHP 5.3.10, ZF 1.11.11, ताज़ा करना
myclass.a.empty	कक्षा एक विवरण	840	672	1480	1256
myclass.aa.interface	इंटरफ़ेस विवरण ए	856	676	1512	1264
myclass.ab.final	अंतिम वर्ग एबी का विवरण	844	672	1488	1256
myclass.ac.abstract	एसी अमूर्त वर्ग विवरण	852	680	1504	1264
myclass.b.extended.empty	कक्षा बी का विस्तार ए	912	700	1512	1264
myclass.c.empty.namespace	खाली नामस्थान C का विवरण	176	-16	184	-72
myclass.d.construct	क्लास डी कंस्ट्रक्टर विवरण	1256	960	2448	1736
myclass.dd.method	विधि के साथ डीडी वर्ग विवरण	1268	968	2432	1728
myclass.ddd.private.var	एक निजी चर के साथ DDD वर्ग का विवरण	1140	964	2000	1760
myclass.dddd.public.var	सार्वजनिक चर के साथ DDDD वर्ग का विवरण	1132	952	2000	1760
myclass.ddddd.static.var	एक स्थिर चर के साथ DDDDD वर्ग का विवरण	1124	952	2000	1760
myclass.e.extended.destruct	कक्षा डी के विस्तारक के साथ वर्ग ई का विवरण	1528	1228	2888	2160
myclass.z.free_memory	$ ई, $ च लिंक हटाना	-332	-548	-784	-1024
zend.a.init.autoload	ZendFramework के लिए ऑटोलॉड की शुरुआत	127 596	१६ १ ९ ६	276,440	28,992
zend.a.init.model	आधार के लिए डिफ़ॉल्ट एडेप्टर की शुरुआत	१ ०१64 ५६४	251 840 है	२ ०१ ६ ९ ६	479,280
zend.extended.controller1	Zend_Controller_Action से नियंत्रक परिभाषा। रास्ते के साथ, मानक Zend कक्षाएं लोड करना	378,464	66 804	809 608	120 864
zend.extended.controller2	नियंत्रक परिभाषा कक्षाएं Zend पहले से ही भरी हुई हैं, हम देखते हैं कि हमारी कक्षा का वजन कितना है	११ ४६	११ १४०	19 792	19 056
zend.extended.model1	Zend_Db_Table द्वारा मॉडल परिभाषा। रास्ते के साथ, मानक Zend कक्षाएं लोड होती हैं।	28080	25676	48,704	४२ ९ ४४
zend.extended.model2	मॉडल की परिभाषा। Zend क्लास पहले से ही भरी हुई है, देखें कि हमारी क्लास का वजन कितना है	28080	25704	48,672	42 960

मैंने xcache के साथ कुछ परीक्षण भी किए और APC के 2 अंतरों पर ध्यान दिया। पहला: मेमोरी बचत में 10-15% तक xcache खो जाता है। और दूसरी बात: xcache तुरंत कैश से फाइलें लौटाता है, जबकि APC - केवल बार-बार एक्सेस के बाद। हालांकि बेकार है, लेकिन एक फायदा है।

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

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

ZendFramework पर एक छोटे से आवेदन का परीक्षण

परीक्षण के लिए, हमने अपने प्रोग्रामर ( सरल-ब्लॉग ) में से एक का कार्य लिया: कार्यों के साथ एक सामूहिक ब्लॉग सेवा: पंजीकरण, प्राधिकरण, पदों की सूची पढ़ना, एक पोस्ट खोलना और उस पर टिप्पणी करना। Index.php के अंत में लिखा गया था:

 echo memory_get_peak_usage(); 

यह जांचने के लिए कि पेज जनरेशन के दौरान स्क्रिप्ट की कितनी मेमोरी है। परिणाम:

पृष्ठ प्रकार	उबंटू x86, PHP 5.3.10, ZF 1.11.11, खाली कैश	उबंटू x86, PHP 5.3.10, ZF 1.11.11, ताज़ा करना	उबंटू x86-64, PHP 5.3.10, ZF 1.11.11, खाली कैश	उबंटू x86-64, PHP 5.3.10, ZF 1.11.11, ताज़ा करना
पद सूची	५ ३२ 5 ६४48	१ 1 ९ २ ९ ६68	१० ९ ३38 १६०	३ ३०६ 6२०
पोस्ट और इसके कमेंट	५ ३ 5२ ३५६	१ 1३१ ४५२	११ ०१५ ३२०	३ ३ 3३ ५२28
लॉग इन फॉर्म	6 781 656	2277164	१३ ९ 13२ १०४	4 187 600
पंजीकरण फार्म	6 796 496	2291568	14 009 384	४ २११ ४३२

इसके अतिरिक्त, Gentoo के लिए विधानसभा का परीक्षण किया गया था, यह सभी परीक्षणों में 25% अधिक प्रभावी निकला।

निष्कर्ष

• यदि मेमोरी एक महंगा संसाधन है (उदाहरण के लिए, वीपीएस) और 64-बिट संख्याओं की वास्तव में आवश्यकता नहीं है, तो यह ओएस के 32-बिट संस्करण का उपयोग करने के लिए समझ में आता है। इसका लाभ ~ 1.8 गुना होगा।
• ओएस में जहां मौजूदा वास्तुकला के लिए पैकेज तेज किए जाते हैं, 25% अतिरिक्त मेमोरी को बचाया जा सकता है।
• पीएचपी में मेमोरी की भारी खपत की तरह कुछ भी नहीं होता है। एक्सेलेरेटर का उपयोग करने से आपको भारी फ्रेम के साथ मेमोरी खाने से नहीं बचाया जा सकता है। शायद यह अपने आप को लोकप्रियता / प्रदर्शन के संतुलन के लिए चुनने के लिए PHP चौखटे की तुलना के साथ खुद को परिचित करने के लिए समझ में आता है।
• स्थिति, जिसे ध्यान आकर्षित करने के लिए तस्वीर में दिखाया गया है, अगर एपीसी कैश आकार समाप्त हो जाता है तो प्राप्त किया जा सकता है। यह प्राप्त करना मुश्किल नहीं है यदि आपके पास एक ही मशीन पर कई साइटें हैं, और आपने एपीसी को बिना जांचे स्थापित किया है कि क्या आपके पास पर्याप्त मेमोरी है। इसी समय, आंकड़े (एपीओएफ़पीपी) आपको बताएंगे कि आपके पास अभी भी लगभग 40% मेमोरी है, लेकिन आपको विशेष रूप से इस पर विश्वास नहीं करना चाहिए, क्योंकि एपीसी के पास एक खराब मेमोरी मैनेजर है और यह बस यह नहीं जानता कि इसे प्रभावी ढंग से कैसे उपयोग किया जाए। बेहतर हमेशा हिट्स और मिस वैल्यू पर ध्यान दें।

Kodyara

• टेस्ट सूट
• ZendFramework ब्लॉग

युपीडी

एंटोनशेवुक ने पीएचपी 5.4 के लिए परीक्षा परिणाम जोड़ा। 5.3 की तुलना में PHP 5.4 बहुत अधिक किफायती है। आधिकारिक दस्तावेज भी इसकी पुष्टि करता है।