در سالهای اخیر، instagram.com شاهد تغییرات زیادی بوده است – ما داستانها، فیلترها، ابزارهای ایجاد، اعلانها و پیامهای فوری و همچنین ویژگیها و بهبودهای بیشماری دیگر را راهاندازی کردهایم. با این حال، با رشد محصول، عارضه جانبی آن این بود که عملکرد وب ما شروع به کند شدن کرد. در طول سال گذشته، ما آگاهانه تلاش کردهایم تا این را بهبود بخشیم.
این تلاش مداوم تا کنون منجرب به تقریباً 50٪ بهبود تجمعی در زمان بارگذاری صفحه با فید شده است. این سری از پست های وبلاگ بخشی از کاری که ما انجام دادیم که منجر به این پیشرفت ها شد را شرح می دهد. در قسمت اول در مورد پیش دانلود داده ها و در قسمت دوم در مورد بهبود عملکرد با ارسال مستقیم داده ها به کلاینت به جای منتظر ماندن برای درخواست داده توسط مشتری صحبت کردیم. با فالو وان همراه باشید تا شما را با ترفند های جذاب اینستاگرام آشنا کنیم.
فالووان ارائه دهنده خدمات اینستاگرام نزدیک به 8 سال است که در این زمینه فعالیت می کند و با ارائه خدماتی مانند خرید لایک اینستاگرام یا ارسال انبوه پیام دایرکت به ارتقا پیج شما کمک می کند.
اول پول نقد
از آنجایی که ما در حال ارسال دادهها به مشتری در اولین لحظه ممکن از بارگیری صفحه هستیم – تنها راه سریعتر برای دریافت دادهها به مشتری این است که اصلاً نیازی به دانلود یا فشار دادن دادهها نداشته باشید. ما میتوانیم این کار را با استفاده از رویکرد اول کش انجام دهیم، اگرچه این بدان معناست که باید دادههای فید قدیمی را در مدت زمان کوتاهی به کاربران نشان دهیم. با این رویکرد، هنگامی که صفحه بارگذاری میشود، بلافاصله یک نسخه کش شده از فید قبلی و نوار داستانی به کاربران ارائه میکنیم و پس از در دسترس قرار گرفتن آن را با دادههای جدید جایگزین میکنیم.
ما از Reduk برای مدیریت وضعیت در instagram.com استفاده میکنیم، بنابراین در سطح بالایی روشی که آن را پیادهسازی کردیم این بود که زیرمجموعهای از فروشگاه Reduk خود را بر روی مشتری در یک جدول DB نمایهشده ذخیره کنیم و سپس زمانی که صفحه برای اولین بار بارگیری شد، فروشگاه را آبرسانی کنیم. . با این حال، به دلیل ماهیت ناهمزمان نمایه سازی دسترسی DB، بازیابی داده ها از سرور، و تعاملات کاربر، ممکن است در هنگام تعامل کاربر با حالت حافظه پنهان با مشکلاتی مواجه شویم، اما پس از آن می خواهیم اطمینان حاصل کنیم که این تعاملات همچنان در حالت جدید اعمال می شود. حالت هنگام ورود از سرور. .
به عنوان مثال، اگر به روشی ساده و بی تکلف با حافظه پنهان برخورد کنیم، ممکن است با مشکل زیر مواجه شویم: همزمان بارگذاری را از کش و از شبکه شروع می کنیم و از آنجایی که فید ذخیره شده ابتدا آماده است، آن را به کاربر نشان می دهیم. . سپس کاربر همچنان پست را دوست دارد، اما هنگامی که پاسخ آنلاین برای آخرین فید برگردانده می شود، آن پست را با یک کپی جایگزین می کند که شامل عملکرد مشابهی نیست که کاربر روی کپی ذخیره شده اعمال کرده است (نمودار زیر را ببینید).
برای حل این مشکل، ما به روشی نیاز داشتیم تا بتوانیم تعاملات را در حالت ذخیره شده در حافظه پنهان اعمال کنیم، اما همچنین این تعاملات را ذخیره کنیم تا بتوانیم بعداً روی حالت جدید از سرور پخش شوند. اگر قبلاً از Git یا سیستم های کنترل منبع مشابه استفاده کرده اید، این مشکل ممکن است آشنا به نظر برسد. اگر حالت کش فید را به عنوان یک شاخه در نظر بگیریم و پاسخ سرور به فید را به عنوان پاسخ اصلی در نظر بگیریم، آنچه واقعاً میخواهیم انجام دهیم این است که یک عملیات پایه گذاری مجدد انجام دهیم، با اعمال برش (لایک، کامنت و غیره) از شعبه محلی ما روی سر استاد.
مطالب پیشنهادی: چه زمانی هشتگ خود را در اینستاگرام ایجاد کنید
این ما را به طراحی زیر می رساند:
- هنگام بارگذاری یک صفحه، درخواستی برای داده های جدید ارسال می کنیم (یا منتظر می مانیم تا فشار داده شود)
- یک زیر مجموعه درجه بندی شده از کاهش وضعیت ایجاد کنید
- در حالی که درخواست / فشار در انتظار است، ما همه اقدامات ارسال شده را حفظ می کنیم
- هنگامی که درخواست حل شد، اقدام را با داده های جدید و تمام اقداماتی که در حالت فاز در انتظار بودند اعمال می کنیم.
- هنگامی که حالت مرحله ای انجام شد، به سادگی حالت فعلی را با حالت مرحله ای جایگزین می کنیم.
با داشتن حالت فاز، تمام رفتار کاهنده موجود را می توان دوباره استفاده کرد. همچنین حالت فاز (که آخرین داده ها را دارد) از حالت فعلی جدا نگه می دارد. همچنین از آنجایی که صحنه نگاری با استفاده از Reduk پیاده سازی شده است، ما فقط باید اکشن هایی را برای استفاده از آن ارسال کنیم!
API
Setup API از دو عملکرد اصلی تشکیل شده است: stagingAction
& stagingCommit
(و همچنین چندین مورد دیگر برای رسیدگی به بازگشت و موارد حاشیه ای که در اینجا به آنها نمی پردازیم).
stagingAction
وعده ای را می پذیرد که عملی را که به حالت مرحله ای ارسال می شود، حل می کند. وضعیت فاز را راهاندازی میکند و تمام اقدامات ارسال شده از زمان اولیهسازی آن را نظارت میکند. با قیاس با کنترل اصلی، میتوانیم این را بهعنوان ایجاد یک شعبه محلی تصور کنیم، زیرا تمام اقداماتی که در حال انجام هستند اکنون در صف قرار میگیرند و با رسیدن دادههای جدید به حالت فاز اعمال میشوند.
stagingCommit
حالت صحنه را در وضعیت فعلی حک می کند. اگر برخی از اقدامات ناهمزمان در حالت آماده به کار باشند، قبل از انجام منتظر خواهند ماند. این شبیه به rebasing از نظر کنترل منبع است، به این معنا که ما تمام تغییرات محلی خود (از شاخه کش) را به بالای اصلی (داده های جدید از سرور) اعمال می کنیم و شاخه محلی خود را به روز می کنیم.
برای فعال کردن مرحلهبندی، کاهنده پایه را با یک تقویتکننده کاهنده میپیچیم که عمل stagingCommit را مدیریت میکند و اقدامات تدریجی را در حالت جدید اعمال میکند. برای استفاده از همه اینها فقط باید اقدامات مربوطه را ارسال کنیم و همه چیز برای ما حل شده است. برای مثال، اگر بخواهیم یک فید جدید بگیریم و آن را در حالت فاز اعمال کنیم، میتوانیم این کار را انجام دهیم:
استفاده از اولین رندر کش برای پستهای فید و استوریبرد منجر به 2.5% و 11% بهبود در زمان تکمیل شد و تجربه کاربری مطابق با آنچه در برنامههای اصلی iOS و Android در اینستاگرام موجود است، خریداری کرد.
مطالب پیشنهادی: چرا خرید لایک اینستاگرام از اهمیت بالایی برخوردار است؟ (5 علت مهم)
قسمت 4 را دنبال کنید
در قسمت چهارم به این خواهیم پرداخت که چگونه با بهینه سازی اندازه و اجرای کد، حجم کد خود را کاهش داده و عملکرد آن را بهبود بخشیم. اگر می خواهید در مورد این شغل بیشتر بدانید یا علاقه مند به پیوستن به یکی از تیم های مهندسی ما هستید، از صفحه شغلی ما دیدن کنید، ما را در فیس بوک دنبال کنید