وبلاگ فيکسل برای گرافيست ها
SharpLife وبلاگ شخصی مهدی تقی زاده
بازگشت شاهو طوفانی
اين صداگذاری و ميکس آخرشه!
نکته جالبی در مورد تابع output_add_rewrite_var
کاراکتر های فارسی در عکس توسط PHP
مصاحبه من با مجله وزین IranAMP
واژه های فناوری اطلاعات و برابر های پیشنهادی فرهنگستان
دوره های آموزش IT
استانداردهای کدنويسی PHP
| صفحه قبل


IranPHP
نماينده رسمي سايت PHP.net

webilix
منبعي براي برنامه نويسان PHP

phprun
وبلاگي خواندني براي تمام PHP كارها

ם تعداد بازديدكنندگان
كل: 924791
ديروز: 915
امروز: 841
ם تعداد كاربران آنلاين
3 نفر
ם پنج مراجعه آخر
okpoyei.is.com
pulse.yahoo.com
superdietakbi.knows.nl
maedfineilf59.cm.to
cfgkgdcg.chez.com
 
 
فشرده سازی محتوا
PHP.JET همونطور که احتمالا متوجه شديد، دو سه روزی هست سايت سريعتر از اون چيزی که قبلا بود، بارگذاری و نمايش داده ميشه. البته کاری با تصاوير سايت ندارم، ولی کلا با وارد کردن URL سايت در نوار آدرس مرورگرتون، محتوای سايت يا بهتر بگم متون سايت و لایوت صفحه، خيلی سريعتر ظاهر ميشه. اين بهبود کارايی بنا به تحليل اين سايت، ۴۴۴ درصد برآورد ميشه. (البته این اطلاعات رو قبل از اعمال این تکنیک نشون میده) از طرفی هم در پهنای باند من صرفه جويی عظيمی صورت ميگيره و هم شما به سرعت می تونيد سايت رو در پنجره مرورگرتون ببينيد. البته در زمان دريافت بسته های داده مربوط به سايت، CPU شما به مقدار کمی از حالت تنبلی خارج ميشه و شروع به خارج کردن محتوا از بسته های فشرده شده ارسالی می کنه. اندازه معمول خروجی HTML این سایت، که بعد از تفسير کدها توسط سرويس دهنده به سمت شما که کلاينت باشی فرستاده ميشه حدود ۶۴ کيلوبايت هست. با روش فعلی من تنها ۱۲ کيلوبايت برای شما ارسال می کنم. می بينم که بعضيا چشماشون shocked شده و علاقه مند هستند که نحوه کار و تکنيک پشت پرده رو بدونند.
همونطور که می دونيد HTTP قراردادی بين سرویس گیرنده(Client) و سرویس دهنده(Server) است.
در HTTP نسخه ۱.۰ ما مفهومی داريم به نام Content Encoding يا فارسی اش ميشه رمزگردانی محتوا. با استفاده از اين روش، کلاينت، سرويس دهنده را از اين موضوع مطلع می کند که قابليت هندل کردن محتوايی که به طرق معينی رمز شده اند را دارد. فشرده سازی محتوا به کوچکتر شدن محتوا منتج می شود که دو اثر قابل توجه دارد:
-) استفاده از پهنای باند کاهش می یابد، زیرا حجم کلی داده های ارسالی کم شده است. در بسیاری از شرکتها، پهنای باند از جمله هزینه های تکرار شونده می باشد.
-) تاخیر شبکه یا Network Latency هم کاهش می یابد. چرا؟! چون محتوای کوچکتر شده در بسته های کمتری جای می گیرد و در شبکه ارسال می شود.
اين مزايا، با زمانی که CPU برای انجام فشرده سازی صرف می کند، رنگ کمتری به خود می گيرد.(البته این زمان بسیار بسیار اندک است در حد چند میلی ثانیه) در يک آزمون واقعی که از فشرده سازی محتوا صورت گرفت(با استفاده از mod_gzip)، به اين نتيجه رسيدم که علاوه بر کاهش ۳۰ درصدی استفاده از پهنای باند، بازدهی کلی سایت هم بهتر میشه یعنی با فشرده سازی محتوا Throughput (صفحه/ثانیه) تقریبا ۱۰ درصد افزایش پیدا کرد. اگه این ۱۰ درصد برای شما کافی هم نباشه، هزینه صرفه جویی که در پهنای باند صورت میگیره وسوسه برانگیز هست.
وقتی کلاينت که اکثرا برنامه های مرورگر هستند، درخواستی برای دريافت يک صفحه وب می کنند، Headerهايی به سمت سرويس دهنده می فرستند که ضمن معرفی خود(نوع مرورگر)، قابليت هایی که پشتیبانی می کنند را هم به اطلاع سرویس دهنده می رسانند.
در اين Headerهايی که برای انجام درخواست، ارسال می شود، مرورگر شيوه فشرده سازی محتوایی را که می پذيرد، به صورت زير اعلام می کنند:

Content-Encoding: gzip,defalte

برای دستيابی و اجرای اين تکنيک در سمت سرويس دهنده، چندين راه وجود دارد. اگر PHP با پشتيبانی از zlib کامپايل شده باشد، (در زمان کامپایل گزینه enable-zlib- را اضافه کنید.) ساده ترين راه استفاده از gzip output handler است که Built-in يعنی از قبل روی سيستم سوار شده است. برای فعالسازی اين ويژگی، کافيست دستورالعملی را در فايل پيکربندی PHP يعنی php.ini تنظيم کنيد.

zlib.output_compression On

با فعال کردن اين دستورالعمل يا Directive در فايل php.ini، قابليتهای مرورگر متقاضی توسط Headerهايی که ارسال می کند، تشخيص داده شده و در صورتی که از امکان فشرده سازی محتوا پشتيبانی کند، بر طبق آن محتوا فشرده می شود، در غير اين صورت، صفحه وب بدون اعمال هيچگونه فشرده سازی به سمت کلاينت ارسال می شود. تنها خرده ای که ميشه به فشرده سازی محتوای PHP گرفت اينست که اين ويژگی تنها به روی صفحات توليد شده توسط PHP اعمال می شود.اگه سرويس دهنده شما تنها صفحات php را Serve می کنه، ديگه هيچ غمتون نباشه! در غير اين صورت، بايد برای رسيدن به اين مهم به ماجولهای Third-party آپاچی نظير mod_deflate و mod_gzip نگاهی بیاندازيد.
البته من تابع بسیار ساده ای برای اين کار نوشتم که همین کار رو انجام ميده و کافيه هر صفحه HTML رو از طريق يک صفحه واسطه php خوانده و اين تابع رو روی محتويات اعمال کنیم تا نتیجه همون چیزی بشه که می خواهیم. (البته مسلما باید خروجی رو بافر کنیم) فقط یادتون باشه اندازه محتوا و CRC32 رو هم به آخر محتوای فشرده شده اضافه کنید.(البته مرورگرها، اگه ۴ بایت آخر رو حذف نکنید و دو تا چیزی که گفتم اضافه نکنید، بازم کارشون رو درست انجام میدن ولی بهتره استانداردها رو رعایت کرد!)
نکات (اشاره ضمنی):
-) gzip از همون الگوریتم فشرده سازی Zip استفاده میکنه. فکر کنم LZ777 ها؟!(اگه اشتباه می کنم، تذکر بدید) اما تفاوت اونها اینه که gzip تنها یک فایل رو فشرده میکنه.
-) بسته به سطح فشرده سازی که تعیین می کنید،(سطح فشرده سازی اینجا رو ۹ گذاشتم) زمان بیشتری از CPU گرفته میشه که بازم ناچیزه!
-) کاربران ویندوز توجه: از نسخه 4.3.0 به بعد پشتیبانی از zlib بصورت توکار تعبیه شده است.(همون Built-in رو میگم!)
-) با استفاده از ForceType کاری کنید که با فایلهای HTML، مانند اسکریپتهای php رفتار بشه تا بتونید بدون ماجول اضافی، این تکنیک رو روی این فایلها هم اعمال کنید.
-) مرورگری نداریم که از deflate پشتیبانی کنه اما از gzip نه! smile
-) در حال حاضر، 80.8۰ درصد، حجم خروجی این صفحه ای که مشاهده می کنید، کمتر شده است! باور نداری؟! از PipeBoost بپرس!
-) mod_deflate رو برای نسخه ۱.۳ آپاچی، از اينجا دریافت کنید. البته این ربطی به mod_deflate نسخه ۲ آپاچی نداره. مستند این پروژه به زبان روسی تهیه شده است.
-) mod_gzip توسط Remote Communication توسعه یافته است، اما در حال حاضر این پروژه، خانه جدیدی در Sourceforge به خود اختصاص داده است.[...]
-) نکته دیگری اگه شما می دونید، اضافه کنید.
ASP.JET پ.ن: سهيل مدتی هست که يک ماجول نوشته برای اپليکيشنهای ASP.NET که دقيقا همين کار رو انجام ميده و لطف کرده و نمونه ای از اون رو به ما داده و ما روی ديجيتال پرشيا نصب کرديم. توضيحات سهيل رو در معرفی برنامه ASP.JET اينجا بخونيد. اين مطلب رو به اين خاطر عنوان کردم که تکنيکی که سهیل به کار برده، توسط خود PHP پشتيبانی ميشه و نياز به ماجول يا اکستنشن خاصی نيست. ولی مشتريان ويندوز حتما به ASP.JET سهيل نیاز خواهند داشت. wink
سطح: پيشرفته
نوشته شده در تاريخ: دوشنبه، 28 ارديبهشت 1383
ساعت: 20:24		  
نظرات شما(92)  
آپاچی ۲ و کاراکتر ست پيش فرض
Apche هنوزم که هنوزه، Apache 2 برای استفاده در محيط Production به همراه PHP 4 توصيه نميشه و همچنان Experimental (آزمایشی) اطلاق ميشه. بنابراين از اونجايی که هوستهای لينوکس هنوز از نسخه ۱.۳.۲۹ استفاده ميکنند، بنابراين برای محيط Development (توسعه) هم معمولا پيشنهاد ميشه از اين نسخه استفاده بشه که احيانا مشکلات ناسازگاری پيش نياد.
اگه صفحات وبی داريد که بصورت لوکال اونها رو مشاهده ميکنيد و کاراکتر ست UTF-8 هستند، وقتی آپاچی نسخه ۲.۰.۴۸ اونها رو Serve می کنه می بينيد که با يکسری کاراکترهای عجيب غريب مواجه می شيد و وقتی از منوی View مرورگر IE قسمت Encoding رو نگاه ميکنيد می بينيد علی رغم اينکه شما کارکتر ست صفحه رو در متا تگها روی UTF-8 تنظیم میکنید ولی صفحات با انکدینگ (Western European(ISO نمايش داده ميشوند. اين به خاطر اينه که آپاچی ۲ يه دستورالعملی در فايل پيکربندی خودش يعنی httpd.conf داره که يک انکدينگ پيش فرض برای صفحاتی که Serve ميکنه در نظر گرفته و اون انکدينگ پيش فرض هم ISO-8859-1 هست، بنابراين هر صفحه ای که Serve ميکنه يه هدر charset بهش اضافه ميکنه که ديگه متا تگها رو ناديده ميگيره. بنابراين هنگام مشاهده صفحات با مشکل مواجه می شيد. برای حل اين مشکل فايل پيکربندی رو باز کنيد و خطی که با دستورالعمل AddDefaultCharset می باشد رو با مقدار UTF-8 ست کنيد. يعنی:

AddDefaultCharset UTF-8

سطح: مقدماتي
نوشته شده در تاريخ: دوشنبه، 3 فروردين 1383
ساعت: 08:40		  
نظرات شما(3)  
هفت نکته جهت سفارشی کردن htaccess.(نکته ۱ از ۷)
Error Documents
وقتی خطايی رخ ميده، آپاچی به فايل htaccess. مراجعه می کنه تا پاسخ مناسب رو اتخاذ کنه. اگه در اين فايل هيچ پاسخی پيدا نکنه يا اين فايل اصلا وجود نداشته باشه، به صفحه Error Document پیش فرض مرورگر رجوع ميشه.
رایج ترین کدهای وضعيت خطا در زير ليست شده است:

200 - OK (don't do this)
401 - Authorization Required
403 - Forbidden
404 - Page Not Found
405 - Method Not Allowed
500 - Internal Server Error

نکته: هرگز کد وضعيت خطای ۲۰۰ رو در فايل htaccess. به کار نبريد.
خوب حالا وقت يک نمونه عملی رسيده، ميخواهيم يک سند خطا برای کد وضعيت خطای ۴۰۴ که يکی از متداولترين خطاها در اينترنت است تنظيم کنيم. اين خطا زمانی رخ ميده که يک صفحه وب پيدا نشه.

ErrorDocument 404 /errorpages/404.html
با نگاهی به کد بالا، می بينيم که:
ErrorDocument: به سرويس دهنده ميگه که اين خط دارای يک گرداننده صفحه خطا هست و کد وضعيت خطا هم به دنبال آن می آيد.
errorpages/404.html/: صفحه ای که سرويس دهنده در هنگام مواجه شدن با اين شماره خطا بايد برای سرويس گيرنده ارسال کند.
در مثال بالا وقتی سرويس دهنده، صفحه مورد نظر رو پيدا نکند، فايل htaccess. به سرويس دهنده فرمان ميدهد که صفحه جايگزينی که در مسير errorpages/404.html/ قرار دارد را نمايش دهد. دقت کنيد که من لينک نسبی را از روت شروع کرده ام، از آنجايی که فايل htaccess. در ساب دايرکتوری ها هم تفسير ميشود، بنابراين همواره بايد لينکها را از روت شروع کنيم وگرنه سرويس دهنده قادر به يافتن صفحه موردنظر نخواهد بود.
برای ساير کدهای خطا هم ميتوان به طريق مشابه عمل کرد:

ErrorDocument 403 /errorpages/403.html 
ErrorDocument 500 /errorpages/500.html
سطح: مقدماتي
نوشته شده در تاريخ: پنج شنبه، 28 اسفند 1382
ساعت: 09:48		  
نظرات شما(222)  
| صفحه قبل
  
 
نام: نيما شايافر
متولد: 7/7/1362
تحصيلات: دانشجو
شغل: طراح وب و برنامه نويس
وضعيت: آفلاين

ماهيانه
مرداد 86 (2)
خرداد 86 (1)
دي 84 (4)
آذر 84 (5)
مرداد 84 (1)
تير 84 (1)
ارديبهشت 84 (2)
دي 83 (1)
آذر 83 (2)
آبان 83 (2)
مهر 83 (4)
شهريور 83 (6)
مرداد 83 (3)
تير 83 (7)
خرداد 83 (7)
ارديبهشت 83 (8)
فروردين 83 (13)
اسفند 82 (12)

موضوعي






جستجوي پيشرفته

BlogRolling is currently inaccessible.
©2004, Design & Developed by: Nima Shayafar. All rights reserved.