بریم سراغ variable در انسیبل

بخوایم تعریف کنیم به این صورت میگیم که داده‌هایی هستند که میتونن در طول یک playbook تغییر کنن که موجب پویاسازی و اجرای اونها در محیط‌های مختلف میشه

در سری پست‌های قبلی ما به دفعات از متغیر در انسیبل استفاده کردیم که نحوه استفاده از اون به شکل "{{ name_var }}" میباشد


متغیرهارو میشه در بخش‌های مختلفی بکار برد در inventory, role,playbook,template ،task و ...

که نمونه‌هایی رو در زیر براتون میزارم که قبلا ازشون استفاده کردیم و دیدیم در پست هامون

در inventory

deployment:
      ansible_host:"{{ server_ip }}"

در task

  tasks:
    - name: Install required packages
      apt:
        name: "{{ item }}"
        state: present
      with_items:
        - htop
        - ufw

متغیرهارو میتونیم در جایگاه‌های خاصی نوشت درون هر tasks (مانند مثال بالا) ، بصورت گروه بندی، بصورت هاست‌بندی و یا در داخل role

در دایرکتوری کاریمون(base-ansible) دو دایرکتوری group_vars ,host_vars ایجاد میکنیم

در داخل group_vars برای هر دسته بندی موجودیتمون یک فایل yaml میسازیم که ما all.yml میسازیم (میتونیم برای موجودیت develope, deployment هم بیازیم) به این ترتیب مقادیر متغییر گروهی رو میتونیم داخلش بنویسیم


و در host_vars برای هر موجودیت یک فایل yaml با اسم موجودیتمون میسازیم که طبق سناریوی خودمون develope.yml , deployment.yml

ساختار بشکل زیر خواهد بود

base-ansible
├── ansible.cfg
├── group_vars
│   ├── all.yml
├── host_vars
│   ├── develope.yml
│   ├── fdeployment.yml
├── inventory
│   └── main.yml
├── roles
│   └── ...
├── playbooks
│   ├── ....

در طی پست‌های قبلی نیز دیدیم داخل role هامون یک دایکرتوری vars داشتیم که داخلش یک فایل با نام main.yml میسازیم


داخل فایل‌های yml به این شکل میتونیم متغییرهامون رو تعریف کنیم

name: "value"

که در هرجایی که خواستیم ازش استفاده کنیم مقدار name رو صدا میزنیم "{{ name }}"


که هرکدوم رو در صورت استفاده در جایگاه خودش در دایرکتوری مدنظرمون مقداردهی میکنیم برای مثال در role هامون در دایرکتوری vars , در موجودیت هامون در host_vars و اگه یک متغییر داشتیم که در جاهای مختلف و دسته مختلف مورد استفاده بود در group_vars میزاریم

نکته بسیار مهم انسیبل از داخلی ترین به بیرونی ترین دنبال متغییرها میگرده تصور کنید داخل یک تسک از متغییر استفاده کردیم ،انسیبل ابتدا در خود task ،سپس در دایرکتوری vars ،سپس در دایرکتوری host_vars و فایل مربوط به اسم موجودیتمون (اگر داخل playbook موجودیت develope رو برای اون تسک ست کرده باشیم ،انسیبل داخل host_vars درون develope.yml دنبال اون متغییر میگرده) و سپس داخل group_vars به همون منوال در اولین مسیری که اون متغییر رو پیدا کنه از مقدار اون استفاده خواهد کرد


#ansible
#CM

@code_crafters

بکاپ گرفتن از دیتابیس پستگرس و ارسال آن به یک گروه خصوصی و تنظیم زمان بندی جهت اجرای مداوم آن در لینوکس


سناریو از چه قرار خواهد بود
ما یک دیتابیس پستگرس داریم و روی داکر بصورت کانتینر در سرور اجرا شده و میخوایم ازش بکاپ گرفته و در تلگرام اون رو داشته باشیم

ابتدا تلگرام رو آماده میکنیم
مراحل زیر رو گام بگام باهم پیش میریم

مرحله اول:
ابتدا یک بات تلگرامی میسازیم

به بات پدر @BotFather رفته  و استارت رو میزنیم
درخواست newbot/ رو میزنیم
از ما یک اسم میخواد که اسمش رو میزاریم backup
از ما یوزرنیم میخواد که با bot اتمام شود که ترکیبی مینویسیم bakup<projectname>bot

و بعد از اتمام پیغام موفقیت و در آن token bot رو میگیریم و نگه میداریم و این توکن رو با نام BOT_TOKEN میشناسیم

مرحله دوم:
یک گروه خصوصی ساخته و بات بالا رو به همراه کاربرانی که میخواهیم به فایل‌های بکاپ دسترسی داشته باشن رو اضافه میکنیم

به ربات @raw_data_bot رفته استارت رو میزنیم سپس chat رو انتخاب میکنیم و از میان لیست باز شده گروه خصوصی ساخته شده رو بهش میدیم و chat id رو ازش میگیریم و نگه میداریم و با نام CHAT_ID اون رو میشناسیم

اماده سازی سرور
مراحل رو گام بگام پیش میریم

مرحله اول:
با دستور docker ps نام کانتینر پستگرس رو نگه میداریم و با نام CONTAINER_NAME میشناسیم

نام دیتابیس ما در پستگرس رو هم با DB_NAME میشناسیم

اگر پسورد شما با نام دیتابیس متفاوت هست اون رو هم نگه دارید و اگه پورت پیش فرض رو هم تغییر داده‌اید اون رو هم لازم دارید(ما تصور میکنیم که پورت پیش فرض و پسورد دیتابیس با نام اون یکسان است)

مرحله دوم:
ساخت یک دایرکتوری برای بکاپ‌ها

در یک مسیر دلخواه در سرور یک دایرکتوری با اسم backups میسازیم 
mkdir backups
chmod 777 backups
cd backups

سپس مسیر آنرا با دستور زیر خواهیم گرفت
pwd 
این مسیر رو نگه میداریم و با نام PATH میشناسیم

مرحله سوم:
ساخت یک فایل حاوی کدهای بش اسکریپت
یک فایل با نام backup.sh ساخته و کدهای زیر رو در اون قرار میدیم

sudo nano backup.sh

کدهای زیر رو در اون بزارید

#!/bin/bash

docker exec -t <CONTAINER_NAME> pg_dumpall -c -U <DB_NAME> > <PATH> backup_$(date +%Y%m%d-%H%M).sql


curl -s -X POST -F chat_id=<CHAT_ID> -F caption=<CAPTION> -F document=@$(ls -t <PATH> backup_*.sql | head -1) https://api.telegram.org/bot<BOT_TOKEN>/sendDocument


find <PATH> -type f -name "backup_*.sql" -mtime +7 -exec rm {} \;

توضیحات کد
در خط اول به کانتینر وصل شده و فایل بکاپ رو گرفته و در دایرکتوری backups ذخیره میکنیم درون اسم فایل بکاپ تایم رو هم میگذاریم

در خط دوم فایل بکاپ گرفته رو به تلگرام انتقال میدهیم

در خط سوم هر فایل بکاپی که یک هفته از آن گذشته باشه رو حذف میکنیم(بکاپ‌های یک هفته‌ای رو نگه میداریم فقط)

نکته: درون فایل بش اسکریپتی مقادیری رو که گفتیم با این نام میشناسیم رو با مقدار مطابق خودشون در این فایل جابجا کرده و فایل رو ذخیره میکنیم در مقدار <CAPTION> متن دلخواه خود را بزارید


بعد از اتمام یکبار با دستور زیر فایل بش اسکریپت رو اجرا کرده و نتیجه کار رو میبینیم

sudo ./backup.sh

زمان بندی کردن بکاپ گیری جهت اجرا شدن در بازه‌های زمانی متداول

اینکار رو با استفاده از کرون‌جاب‌های لینوکس انجام میدهیم

دستور crontab -e رو میزنیم

سپس یک ادیتور انتخاب میکنیم

و مقدار زیر رو به فایل اصافه کرده و ذخیره میکنم
0 24 * * * <PATH>backup.sh

هر روز ساعت دوازده شب یک فایل بکاپ براتون ارسال خواهد شد در تلگرام


#postgresql

@code_crafters

اسکریپت اصلاح شده توسط سعید(کاکوی گروه)

پروکسی اضافه شد(برای استفاده در کشورهای جهان اولی فیلتری و تحریمی)
فایل زیپ شد(از تغییر ناگهانی هنگام انتقال و نگهداری فایل‌ بکاپ جلوگیری میکنه و سبکتر هم جهت ارسال ارسال میشه)
متغییرها کاملتر و بهتر کنترل شده
چندین بار جهت اطمینان از ارسال فایل چک میکنه برامون

-----------------

#!/bin/bash


CONTAINER_NAME=<your_container_name>
DB_NAME=<your_database_name>
PATH=<your_backup_path>
CHAT_ID=<your_chat_id>
CAPTION=<your_caption>
BOT_TOKEN=<your_bot_token>
PROXY_URL=<your_proxy_url>
 


docker exec -t $CONTAINER_NAME pg_dumpall -c -U $DB_NAME | gzip > $PATH/backup_$(date +%Y%m%d-%H%M).sql.gz


send_backup() {
    curl -s -X POST \
         -F chat_id=$CHAT_ID \
         -F caption=$CAPTION \
         -F document=@$(ls -t $PATH backup_*.sql.gz | head -1) \
         --proxy $PROXY_URL 
         https://api.telegram.org/bot$BOT_TOKEN/sendDocument
}


MAX_RETRIES=3
for ((i=1; i<=MAX_RETRIES; i++)); do
    send_backup && break || sleep 5  # Retry with 5-second delay
done

# Remove files older than a week
find $PATH -type f -name "backup_*.sql.gz" -mtime +7 -exec rm {} \;


--------------

حالا که خوشتون اومده یکم‌ بهتر تر اش کنیم
- هم وضعیت هر تسک رو لاگ کنه
- هم چک کنه اگر بکاپ‌ای تنبلی کرده نرفته جایی که باید بره 😁 مجدد بفرسته در اجرای بعدی تا برههه
- عملیات رفته توی یک فانکشن.
- پراکسی اختیاری برای سرورای ایران که تلگرام فیلتره
- هندل خطا و retry در صورت ناموفق بودن
ابتدای فایل متغیر های محلی رو تمیز تر تعریف کردیم که خوانا و منطبق با فرمایشات آنکل باب باشه:

dbBackupSyncScript.sh:

-------------

#!/bin/bash

# Configuration (replace with your details)
CONTAINER_NAME=<your_container_name>
DB_NAME=<your_database_name>
PATH=<your_backup_path>
CHAT_ID=<your_chat_id>
CAPTION=<your_caption>
BOT_TOKEN=<your_bot_token>
PROXY_URL=<your_proxy_url>  # Optional for limited network environments

# Function to send backup with retries and logging
send_backup() {
    local filename=$(ls -t $PATH backup_*.sql.gz | head -1)
    for ((i=1; i<=MAX_RETRIES; i++)); do
        if curl -s -X POST \
             -F chat_id=$CHAT_ID \
             -F caption="$CAPTION (Attempt $i)" \
             -F document=@"$filename" \
             --proxy $PROXY_URL \  # Uncomment if using proxy
             https://api.telegram.org/bot$BOT_TOKEN/sendDocument; then
            echo "$(date +%Y-%m-%d-%H:%M): Backup $filename sent successfully." >> $PATH/backup_log.txt
            return 0
        else
            echo "$(date +%Y-%m-%d-%H:%M): Error sending backup $filename (Attempt $i): $?" >> $PATH/backup_log.txt
            sleep 5
        fi
    done
    return 1
}

# Constants
MAX_RETRIES=3
LOG_FILE="$PATH/backup_log.txt"

# Create log file if it doesn't exist
touch "$LOG_FILE"

# Make compressed database backup dump file
docker exec -t $CONTAINER_NAME pg_dumpall -c -U $DB_NAME | gzip > $PATH/backup_$(date +%Y%m%d-%H%M).sql.gz

# Send backup and handle retries
send_backup || echo "$(date +%Y-%m-%d-%H:%M): Failed to send backup after $MAX_RETRIES attempts. See $LOG_FILE for details."

# Check and resend undelivered backups (if any)
unsent_files=$(find $PATH -type f -name "backup_*.sql.gz" ! -name "$(tail -n 1 $LOG_FILE | cut -d ':' -f 2- | cut -d ' ' -f 2)")
if [[ ! -z "$unsent_files" ]]; then
    echo "$(date +%Y-%m-%d-%H:%M): Found undelivered backups. Retrying..." >> $LOG_FILE
    for file in $unsent_files; do
        send_backup "$file" && echo "$(date +%Y-%m-%d-%H:%M): Undelivered backup $file sent successfully." >> $LOG_FILE
    done
fi

# Remove files older than a week
find $PATH -type f -name "backup_*.sql.gz" -mtime +7 -exec rm {} \;

-----------

ریلیز 1.1.2

ریلیز 1.1.3 هم در داخل کامنت ،پشتیبانی ارسال پیامک

و ریلیز 1.1.4 با قابلیت تست بکاپ بصورت اتومات در کانتینر پستگرس

@code_crafters

بخونید جالبه.
چرا کلادفلیر تصمیم گرفت استفاده از nginx رو کنار بزاره و خودش یک ریورس پراکسی خیلی بهینه تر با rust بنویسه (که گویا یک سوم طراحی قبلی شون مصرف منابع داره و منعطف تره، بعلاوه حل بسیاری از ضعف ها و چالش هاشون با nginx مثل کامیونیتی نه چندان فعال که گویا زیاد اجازه بهتر کردنش رو بهشون نمیداده، با زبان C خالص بودن و ریسک و مشکلات حافظه ای، توسعه خیلی پیچیده بخاطر زبان C، مشکلات مقیاس پذیری، ورکر پراسس ها کانکشن های زیاد، retry، load balance و ... )در مقیاس یک cdn واقعا بزرگ حرف میزنیم!))
واقعا rust قابل تحسینه 👌 (و پروژه کلادفلیر)

https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet

Physics

#free

@code_crafters

بچه‌هایی که بهم نزدیک هستند و میشناسن من رو میدونن که من هیچ علاقه‌ای به کامپیوتر و رشته‌ام ندارم ، علاقه وافر من در واقع به منطق کلام هست بابت همین بیشتر کتاب‌های فلسفه و روانشناسی میخونم (بگذریم)


ایشون اسلاوی ژیژک هستش نویسنده و از دیدگاه من فیلسوف میان رده معاصر، کتابی که از ایشون خوندم و بخوام بهتون معرفیش کنم با نام خشونت هستش و من از این کتاب باهاشون آشنا شدم

کتاب یک سیر تاریخی بیشتر در رویدادهای معاصر هستش که با برشمردن و نگارش وقایع به ما در درک دقیقتر و ریزبینانه‌تر در خصوص شناخت خشونت و ابزارهای اعمال اون کمک میکنه


یادمه یبار یکی از دوستان ازم خواست تا چیزی بهش بگم که در طول زندگی بهش کمک کنه و یجورایی به این ویدیو هم مربوطه و من این رو بهش گفتم

مراقب افکارت باش، افکار آدمی میتونه بزرگترین موهبت و در عین حال خطرناکترین سلاح یک انسان باشه


#book
#free

@code_crafters

در ادامه مبحث انسیبل بریم سراغ کانفیگ کردنش

در پست‌های قبلی ما راجب inventory ,eole, playbook , task و ... خوندیم

اما اگه دستور اجرای یک playbook رو بزنیم با خطا مواجه میشیم و دلیل این قضیه هم این هست که ما اومدیم ساختار خودمون رو ساختیم و انسیبل بصورت پیش فرض از پیکربندی خودش استفاده میکنه خطایی که با اون مواجه میشیم هم اشاره به عدم شناخت موجودیت‌هامون داره

در خط فرمان مسیر دایرکتوری کاریمون

ansible-playbook playbooks/main.yml

که با معرفی مسیر inventory به شکل زیر میتونیم این مشکل رو برطرف کنیم

ansible-playbook -i inventory/main.yml playbooks/main.yml

اما بازهم خطای شناخت roles هارو داریم

ما باید مسیر هرکدوم رو برای انسیبل مشخص کنیم که اینکار رو در فایلی با نام ansible.cfg در دایرکتوری کاریمون(base-ansible) انجام میدهیم

که محتویات این فایل بشکل زیر خواهد بود

[defaults]
inventory           = ./inventory/main.yml
remote_tmp          = /tmp
forks               = 150
sudo_user           = root
remote_user         = root
roles_path          = ./roles
host_key_checking   = False
log_path            = ./log/ansible.log

[privilage_escalation]
#become=True
#become_method      = sudo
#become_user        = root
#become_ask_pass    = False

[ssh_connection]
scp_if_ssh  = True

توضیحات مربوط به این پیکربندی

در قسمت default

در قسمت inventory مسیر موجودیت‌هامون رو مشخص میکنیم

در قسمت remote temp مسیر نگه داشتن فایل‌های موقت در طول زمان احرا در سرور

در قسمت forks تعداد فرایندهای موازی جهت احرای وظایف در انسیبل رقم بالا موجب بهبود کاری در استقرارهای بزرگ شود

در قسمت sudo user مشخص میکنیم که انسیبل با چه سطح دسترسی وظایف رو در سرورها اجرا کند که با دسترسی sido کاربر root براش معین کردیم 

در قسمت remote user هم مشخص کردیم که با چه کاربری به سرورها دسترسی پیدا کند که کاربر root رو مشخص کردیم

در قسمت roles هم مسیر roles رو مشخص کردیم 

در قسمت host key checking مشخص میکنیم آیا انسیبل کلید ssh بررسی کند که در اینجا غیرفعال هست چون تو محیط یادگیری و تست هستیم

در قسمت log path مشخص کردیم که انسیبل لاگ‌های حین اجرا رو در کجا بزاره (بنابراین دایرکتوری با نام log در مسیر دایرکتوری کاریمون base-ansible میسازیم و داخل اون یک فایل ansible.log میسازیم ازین ببعد لاگ خروجی رو میتونیم در این فایل مشاهده کنیم بعد هربار اجرا کردن انسیبل)

در بخش privilege escalation رو داریم که کامیت شده و دلیل اون استفاده از کاربر root در بخش قبلی بود اگر کاربر دیگه رو انتخاب میکردیم در این بخش مشخص میکردیم که هر playbook ی که دارای مقدار become بود با سطح دسترسی چه کاربری این تسک رو انجام بده

و در نهایت در بخش سوم هم اجازه استفاده از s p جهت انتقال فایل‌هامون از طریق ssh رو به انسیبل داده‌ایم (برای مثال فایل‌هایی که در بخش files و ... در role هامون مشخص کرده بودیم)

و در نهایت ساختار این فایلمون هم بصورنچت init میباشد

فراموش نکنید که انسیبل از طریق ssh ارتباط برقرار میکنه و کدهای زیر جهت راه اندازی ssh و انتقال کلید، برای اتصال انسیبل به سرور هم قرار میدم

ansible-playbook playbooks/git.yml

نکته قابل توجه این است که ارتباط با ssh صورت میگیرد پس لازمه اجرا شدن اون ساخت و کپی کردن ssh بر روی سرورهامون میباشد

ssh-keygen -t rsa

ssh-copy-id username@server_address

ssh username@server_address

حالا کافیه که دستور زیر رو بزنیم تا بدون مشکل انسیبل اجرا بشه و لاگ رو هم در مسیر log و فایل ansible.log که داخلش ساختیم هم ببینیم و نگه داریم برای بعدا

ansible-playbook playbooks/main.yml

با توجه به ساختار کانفیگ انسیبل ما میتونیم اسامی دیگری برای دایرکتوری‌هامون انتخاب کنیم ،بله میتونیم اما طبق یک قانون نانوشته یکی از موارد کلین نوشتن انسیبل رعایت کردن درست و بجای اسامی می باشد

#ansible
#CM

@code_crafters

با یکی از دوستان در حال خوندن این کتاب هستیم و خلاصه‌ای از هر بخش و مهمترین مباحث رو در طی سلسه پست‌هایی با هشتک مشخص براتون میزاریم

این کتاب به مسائل مهمی میپردازد مانند همزمانی در رشته، ناهمزمانی ،پردازش موازی و شناخت سخت افزاری تا حدودی ، شناخت سیستم و چگونه ایجاد کردن سیستم‌های توزیع پذیر و پیاده سازی تسک‌های مستقل ، رفع بن بست و گرفتگی‌های نرم افزار و ....



سعی میکنم تا جای ممکن کامل و جامع توضیحات اون رو بهتون برسونم


لینک وبسایت

#book
#concurrency

@code_crafters

Top 5 #Caching Strategies


https://www.linkedin.com/posts/isharanimicrosoftleader_%3F%3F%3F-5-%3F%3F%3F%3F%3F%3F%3F-%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F-activity-7110477190512721920-AVBG?trk=public_profile_like_view

کتاب همزمانی (concurrency) از جمله کتاب‌های خیلی باحاله

یک مقداری در اوایل کتاب موضوعات رو موشکافی نکرده و پیش رفته که حقیقتا نمیشه بهش ایراد گرفت چون اصل موضوعیت کتاب بر روی برنامه نویسی هستش نه بر روی یکسری توضیحات سخت افزاری منتها جایی لازم بود و من در حد توان و سوادم موارد رو بهش اضافه میکنم

تصویر اول در کامنت‌هارو ببینید در این کتاب قراره تا حد امکان راجب موضوعات این تصویر حرف بزنیم


همزمانی در مهندسی نرم افزار بسیار موضوع حیاتی هست با افزایش تقاضا برای برنامه‌های کاربردی با توانایی بالا و رشد سریع سیستم‌ها (افزایش تعداد هسته‌ها و منابع) همزمانی بیشتر و عمیقتر در باطن مهندسین جا گرفت تا جایی که امروز تقاضای شرکت‌ها برای مهندسینی که به همزمانی تسلط داشته باشن بسیار حائز اهمیت هستش

موضوعی که در همزمانی بشدت مورد توجه قرار گرفت افزایش توان عملیاتی هستش که در این کتاب بر روی این موضوع تمرکز شده


با این سوال پیش بریم
ما اگر نیاز به عملکرد بهتری داریم چرا سخت افزارهای بهتری نخریم، خب اینکاری هست که قبلا انجام دادیم اما محدودیت اون تا جایی بود که سخت افزار پیشرفت کرده بود و فراتر از اون امکان پذیر نبود


جناب مور (نقطه عطف تغییر مسیر)
از بنیانگذاران اینتل پی برد که نسل‌های جدید پردازنده‌ها ترانزیستورهای بیشتری نسبت به قبل دارن که این موجب افزایش سرعت میشه ، بعنوان یک مهندس نرم افزار فقط کافیه بشینم نسل بعدی پردازنده بیاد تا با سرعت بیشتر روبرو بشم (بهش میگیم قانون مور)

ترانزیستور چکاری میکنه؟؟؟
ما در طی مسیر برد واحدهایی رو قرار میدیم که موجب افزایش سرعت پالس الکتریکی میشه 

-همون فرکانس پردازنده (سرعت پردازش) که موقع خرید دنبالش میگردیم

اما چندی نگذشت که جناب جدیدی کشفی کرد که قانون رو تغییر داد

جناب هرب
این جناب که از افراد تاثیرگذار بر روی ++c هستش پی برد که رابطه مستقیمی بین اندازه پردازنده و فرکانس پردازنده وجود دارد

زمان انجام یک عملیات به طول مدار و سرعت نور بستگی دارد ما تا زمانی میتوانیم ترانزیستور اضافه کنیم که فضای خالی داشته باشیم که البته باید افزایش دما رو هم در نظر بگیریم، بهبود عملکرد بهتر نمیتواند تنها به افزایش فرکانس پردازنده مربوط شود

این جناب با فرمودن این حرف ساده موجب ایجاد بحران چند هسته‌ای شد

جناب هرب گفت دوست عزیز وقتی میری موبایل بخری یا سیستم فقط به فرکانس پردازش بالا دقت نکن، قطر پردازنده هم تاثیر گذاره که هرچه قطرش همون نانومتر پردازنده پایینتر باشه بهبود عملکرد داریم

پیشرفت پردازنده‌ها از نظر سرعت کلاک بابت محدودیت های جدید متوقف و کاهش پیدا کرد سخت افزار سمت سیستم‌های جدید چند پردازنده متعدد رفتن

ولی مگه کارفرماها دست از سر مهندسین نرم افزار و توسعه دهندگان کشیدن؟؟؟ مجبورمون کردن خودمون رو با سیستم جدید تطبیق دهیم

تصویر دوم در کامنت‌هارو نکاه کنید

کلاک سرعتی که ریزپردازنده می‌تواند یک دستورالعمل را طی یک زمان خاص اجرا کند

-خب تا اینجا راجب توان پردازشی حرف زدیم راجب زمان و ... حرف زدیم وقتی بهتون میگیم گولنگ زاده دوران تایمینگ و کلاک هست باید درک‌ کنید منظورمون چیه دقیقا و چطور و چرا این بچه خودش خیلی از این موارد رو به بهترین شکل ممکن هندل میکنه

لینک وبسایت

#concurrency

@code_crafters

کدوم مغز داری در دنیا زندگیش رو صرف دستمزد و حقوق گرفتن کرده تا بجای خلق ارزش افزوده؟؟؟


کدوم یک از صاحب کمپانی‌های بزرگ دنیا بابت دستمزد کار میکنن؟؟

کدوم یک از شرکت داران امروزی بابت دستمزد کار میکنن؟؟؟


حالا این سوال رو از خودت بپرس کدوم شرکتی حاضره بجای حقوق بهتون سهام بده؟؟؟

یکم کتاب‌های رابرت کیوساکی رو بخونید درک کردن حرفاش بهتون کمک میکنه رفتار اقتصادی بهتری انجام بدید


#free

@code_crafters

در ادامه مبحث کتاب همزمانی

زمان تاخیر (latency) و توان عملیاتی

بسته به نگاه ما میتوان عملکرد سیستم را به گونه‌های مختلفی ارزیابی و بررسی کرد، یکی از راه‌های افزایش عملکرد کاهش زمان تسک‌های تکی می باشد

با یک مثال پیش بریم
شما میخواهید از نقطه A به نقطه B بروید شما میتونید این فاصله رو پیاده برید یا با یک موتور، در حالت دوم با استفاده از موتور شما زمان کمتری رو مصرف میکنید

حالا اگه بخواید چند نفر رو در بین این دو نقطه جابجا کنید الزاما شما از یک اتوبوس استفاده خواهید کرد ، در این حالت دیگه شما بفکر زمان نیستید بلکه بفکر جابجایی نفرات بیشتر هستید، به این سناریو توان عملیاتی گفته میشه: تعداد وظایفی که یک سیستم در یک بازه زمانی میتونه انجام بده


درسته یک موتور سریعتر از اتوبوس هستش اما اتوبوس بار عملیاتیش چند برابر موتوره، اگر موتور این مسافت رو یک ساعته بره، اتوبوس دو ساعته میره ، اما موتور یک نفر رو جابجا میکنه اتوبوس ۳۰ نفر رو ،در واقع در ازای هر ساعت اتوبوس ما ۱۵ نفر رو جابجا کرده‌ایم

درک تفاوت تاخیر و توان عملیاتی بسیار مهم هستش

به عبارت دیگر، توان عملیاتی بیشتر سیستم لزوماً به معنای تأخیر کمتر نیست.
هنگام بهینه سازی عملکرد، بهبود یک عامل (مانند توان عملیاتی) ممکن است منجر به بدتر شدن عامل دیگر (مانند تأخیر) شود


همزمانی میتواند تاخیر را کاهش دهد، با شکستن یک تسک طولانی مدت به چند تسک کوچکتر و اجرای آنها بصورت موازی ،موجب کاهش کلی زمان اجرایی میشود ،همزمان همچنین میتواند با اجازه دادن به پردازش چندکار بطور همزمان به افزایش توان عملیاتی کمک کند، علاوه بر این میتواند تاخیر را پنهان کند(خوندن سلسله پست‌های این آموزش در اتوبوس بالا)

بنابراین، استفاده از همزمانی می تواند عملکرد سیستم را به سه روش اصلی بهبود بخشد:

 -کاهش تاخیر (یعنی یک واحد کار را سریعتر کند)

-پنهان کردن تاخیر(یعنی به سیستم اجازه دهد تا در طی عملیاتی با تأخیر بالا چیز دیگری را انجام دهد)

-افزایش توان عملیاتی (یعنی سیستم را قادر به انجام کارهای بیشتر کند)
 

همزمانی چطور در سیستم‌های پیچیده و بزرگ موثر است؟؟؟

حل مسائل بزرگ و پیچیده‌ که هنگام توسعه سیستم با اون سروکار داریم بدون استفاده از یک سیستم ترتیبی غیر ممکن است. پیچیدگی می تواند ناشی از اندازه مشکل یا سختی درک بخشی از سیستم هایی باشد که توسعه می دهیم.


مقیاس پذیری(scalability)
اندازه یک مشکل شامل مقیاس پذیری یا ویژگی یک سیستم است که میتواند با افزودن منابع بیشتر عملکرد را افزایش دهد

اسکیل کردن به دو صورت عمودی و افقی هست

اسکیل عمودی
که شامل بروز رسانی سخت افزاری و افزایش منابع سخت افزاری هستش، هسته قویتر، حافظه بیشتر و ...
که خب همیشه محدودیت داریم و تا جایی میتونیم این کار رو ادامه بدیم

اسکیل افقی
این قسمت بیشتر سمت مهمدسین نرم افزار و توسعه دهندگان هستش که شامل کاهش زمان انجام یک کار خاص و کوچک کردن سیستم‌های خودمون، اسکیل افقی در واقع افزایش عملکرد سیستم با توزیع بار بین منابع موجود هستش اینکار بشدت سختتر و زمانبرتر از اسکیل عمودی هستش

روند ناشی از تقاضای سیستم‌های بلادرنگ، حجم بالای داده، قابلیت اطمینان از طریق افزونگی و بهبود استفاده از طریق استراک‌گذاری منابع به دلیل مهاحرت به محیط‌های ابری (SaaS)، این صنعت تصمیم به رویکرد اسکیل افقی گرفت

جداسازی (decoupling)
موضوع مورد مناقشه بعدی پیچیدگی هستش، که بدون تلاش مهندسان نرم افزار هیچگاه کاهش پیدا نمیکند

وقتی شروع میکنید یک سیستم رو قدرتمندتر و کاربردی تر کنید پیچیدگی اجتناب ناپذیر میشه بالاخص در بیس کد هاتون، زیرساختتون و همچین نگهداری اون سیستم

در نهایت باید یک رویکرد بیابیم که سیستم رو به واحدهای ارتباطی ساده‌تر پیاده سازی کند

معماری میکروسرویس و معماری DDD اینکار رو برامون انجام میدن اما همانطور که دیدیم پیچیدگی درونشون هم اجتناب ناپذیر هست

اصل تقسیم و تسخیر در مهندسی موجب پدید اومدن سیستم‌هایی شده که باهم جفت میشن ، بابت همین در مخمدسی نرم افزار همیشه از تفکیک وظایف استقبال میشه

گروه بندی کدهای مرتبط (tightly coupled components) و جداسازی کدهای نامرتبط (loosely coupled components) درک و آزمایش برنامه ها و تعداد باگ‌ها رو در تئوری کاهش میده


همزمانی استراتژی جداسازی هستش، تقسیم وظایف بین ماژولها یا واحدهای همزمان موجب تمرکز قطعات روی عملکردهای خاص میشه قابلیت نگهداری رو بالا میبره و پیچیدگی رو کاهش میده

مهندسین آنچه را انجام میشود از زمانی که انجام میشود تفکیک میکنند این بشکل چشمگیری موجب افزایش عملکرد، مقیاس پذیری، قایلیت اطمینان و ساختار داخلی رو بهبود میده

لینک وبسایت

#concurrency

@code_crafters

همزمانی جایگاه ویژه و مورد استفاده گسترده‌ای در سیستم‌های محاسباتی مدرن، سیستم عامل و خوشه های توزیع پذیر دارد، این مدل سازی از دیدگاه کاربران و توسعه دهندگان کارایی سیستم رو افزایش میده و به توسعه دهندگان اجازه میده تا مشکلات و پیچیدگی رو حل کنن

لایه‌های همزمانی
تصویر اول در کامنت‌ها
مانند اکثر مشکلات پیچیده طراحی، همزمانی با استفاده از چندین لایه ساخته میشود

در یک معماری چند لایه، یک مفهوم متناقض یا منحصر بفرد ممکن در سطوح مختلفی بصورت همزمان وجود و یا دیده بشه

هر لایه فرآیند یکسانی را در سطوح مختلف توصیف می کند، اما جزئیات متفاوت و گاهی متناقضی داره

تصویر دوم در کامنت‌ها رو ببینید

این اتفاق در همزمانی هم روی میده:
در لایه سخت افزار ما با دستورات ماشینی روبرو‌ هستیم که با استفاده از سیگنالها میتوانیم به دیگر تجهیزات جانبی متصل به سخت افزار دسترسی پیدا کنیم ،معماری مدرن پیچیدگی خاص خودش رو داره به همین دلیل بهینه سازی عملکرد برنامه در این معماری نیاز به درک عمیقی از تعاملات برنامه با سخت افزار داریم


لایه سیستم زمان اجرا، با توجه به قرار گیری الگوریتم‌های زمان بندی ،فراخوانهای سیستمی و درایورها در این لایه تاثیر شگرفی بر همزمانی خواهد داشت این لایه توسط سیستم عامل نشان داده میشه و نیاز به درک کاملی از آن داریم

در نهایت، در لایه کاربرد، انتزاعاتی که از نظر روحی به نحوه عملکرد دنیای فیزیکی نزدیک‌تر هستند، در دسترس قرار می‌گیرند. مهندسان نرم افزار کد منبعی را می نویسند که می تواند الگوریتم های پیچیده را پیاده سازی کند و منطق تجاری را نشان دهد. این کد همچنین می تواند جریان اجرا را با استفاده از ویژگی های زبان برنامه نویسی تغییر دهد و به طور کلی مفاهیم بسیار انتزاعی را نشان می دهد که فقط یک مهندس نرم افزار می تواند به آن فکر کند.


لینک وبسایت

#concurrency

@code_crafters

بنچمارکینگ ( benchmark test) چیست؟؟؟

همیشه بحث بر سر کدهامون هست
مدام و مدام کد میزنیم چه در قالب فردی، چه در قالب گروهی و موضوع اصلی همیشه پابرجاست کد ما چقدر خوب و سریع هستش

یک کد رو از دیدگاه‌های مختلفی میشه بررسی کرد سرعت اجرایی اون در حالت‌های مختلف، محک گذاری برای یافتن تنگناها، ناکارآمدی ها و رگرسیون‌ها

تست عملکرد (benchmark) شامل قراردادن کد در معرض عوامل استرس زا و سناریوهای مختلف جهت سنجش پاسخگویی، ثبات و مقیاس پذیری است

از طرفی هم معیارسنجی فرآیند اندازه‌گیری زمان اجرای کد یا استفاده از منابع برای ایجاد یک خط پایه عملکرد و پیگیری تغییرات در طول زمان است

در خصوص موضوع این پست pytest متحد ما خواهد بود و در کنار آن pytest benchmark همراه ما خواهد بود


چرا باید کدهای خود را محک بزنیم؟؟؟

۱-برای بهینه سازی الگوریتم‌ها و تکه‌های کد، شناسایی تنگناهای عملکرد و اعتبارسنجی پیشرفت‌ها 

۲-در مقایسه نسخه‌های متفاوت کمک میکند و اطمینان حاصل میکند که نسخه‌های جدید عملکرد را حفظ یا بهبود داده

۳-به تست سازگاری سخت افزار و پلتفرم کمک میکند و اختلافات را در محیط‌های مختلف برجسته میکند

۴-در خطوط لوله یکپارچه سازی پیوسته،  محک زدن بعنوان یک سیستم هشدار اولیه عمل میکند و از رگرسیون عملکرد جلوگیری میکند(به این معنی که کد جدید بر عملکرد قبلی تاثیر منفی نمیگذارد)

۵-در نهایت کمک میکند تا با مقایسه عملکرد کتابخانه‌ها مختلف، انتخاب‌های فناوری آگاهانه داشته باشیم

و اما BIG O NOTATION (درک این قسمت مناسب مهندسین نرم افزار)
یکی از مسائل بشدت مهم ساختمان داده‌ها و الگوریتم‌ها تحلیل زمانی کد می‌باشد ،این موضوع به ما مهندسین نرم افزار در درک بهتر معیارها و درک اصول اولیه کمک میکند

این نماد بر مهمترین عوامل موثر بر زمان اجرا یا استفاده از منابع الگوریتم تمرکز میکند و جزئیات دقیق‌تر را انتزاع میکند

بعنوان مثال با توجه به ورودی بزرگتر، آیا انتظار می‌رود زمان اجرا کد بصورت خطی، نمایی یا لگاریتمی مقیاس شود
یا زمان اجرا مستقل از اندازه ورودی است؟یعنی صرف نظر از اینکه ورودی چقدر بزرگ است همان زمان را می‌گیرد

دانش BIG O و عملکرد میتونه به ما قدرتی بده که انتخاب‌های آگاهانه‌ای داشته باشیم که در حوزه تست عملکرد ضروری است

پیش نیازها

دانش پایه‌ای از پایتون و ساختارهای داده‌(list, tuple, string)

دانش پایه‌ای از pytest

اندکی دانش از الگوریتم‌ها

pip install pytest
pip install pytest-benchmark

این کتابخونه به ما امکان این رو میده که کدهامون رو تو حالت‌های مختلف و تعداد بالا محک بزنیم با استفاده از pytest گروه بندی کنیم خروجی هارو نگه داریم و هنگام توسعه خروجی‌ها رو با هم مقایسه کنه و اینکه هیستوگرام بنچمارک رو هم برامون رسم کنه


به طور پیش فرض، pytest-benchmark محک گذاری مبتنی بر زمان را انجام می دهد. زمان اجرای کد مورد آزمایش را اندازه گیری می کند و آماری در مورد زمان بندی هر اجرا ارائه می دهد.
که موارد زیر رو شامل میشه

Min
Max
Mean
StdDev
Median
IQR
Outliers
OPS (Mops/s)
Rounds
Iterations

توضیحات رو در کامنت‌ها براتون میزارم

در پست بعدی یک نمونه عملی رو باهم انجام میدیم

لینک وبسایت
#monitoring

@code_crafters

خب بیاید با یک پروژه ساده پیش بریم دایرکتوری کاری ما به شکل زیر خواهد بود

Plbenchmark-test
├── src
│   └── sorting_examples.py
└── test
    ├── conftest.py
    └── test_benchmark.p

از این ریپوزیتوری میتونید دریافت کنید

توضیحات

در داخل فایل sorting_example.py سه الگوریتم مرتب سازی قرار دادیم

در فایل conftest.py دو نوع داده ورودی کوچک و بزرگ برای تست‌هامون ساختیم

در فایل test_benchmark.py تست‌هامون رو نوشتیم

با دستور زیر گروه sort_small رو اجرا میکنیم

pytest -m sort_small -v -s 

و خروجی سه تستی که برای اون نوشتیم رو میبینیم که شامل موارد ذکر شده در پست قبلی میباشد

با دستور زیر میتونیم هیستوگرام اون رو هم ببینیم

pip install pygal

pytest --benchmark-histogram -m sort-larg

هیستوگرام رو در یک تصویر در مسیر جاریتون خواهد ساخت هر تابع تست شده رو به شکل یک کندل نشون میده 

در پست قبلی گفته بودیم که این کتابخونه پیش فرض بر روی زمان اجرا تمرکز دارد با دستور زیر و احرا کردن یک قسمت خاص از کدهای تست میتونید این مورد رو مشاهده کنید

pytest --benchmark-histogram -m benchmark

خروجی تست عملکرد در خط فرمان و هیستوگرام در یک فایل تصویری بصورت کندل

و با دستور زیر در هربار اجرا میتوانید بنچمارک رو ذخیره کنید

pytest -m sort_large --benchmark-autosave

در مسیر جاری و در دایرکتوری benchmarks. این فایل‌هارو مطابق با ورژن پایتون ذخیره میکند در ابتدای هر فایل یک مقدار چهر عددی قرار میده که بعدا از این برای مقابسه دو بنچمارک باهم استفاده میکنیم

جالبه بدونید که مشخصات سخت افزار و نود ،تاریخ و ورژن ، مشخصات پردازنده بصورت و ... روکامل هم ذخیره میکنه تا در هربار بنچمارک بتونید مقایسه کاملی انجام دهید

و اخرین دستور جهت مقایسه دو مقدار بنچمارک ذخیره شده

pytest-benchmark compare 0001 0002

نتایج خروجی رو در خط فرمان میتونید مشاهده کنید


و اما یک سوال
ایا اگر در تابع تستی نیاز به خوندن داده از کسیر خاصی یا دیتابیس خاصی باشد آیا این تایم صرف شده رو در بررسی سطح عملکر و محک تاثیر میده؟؟؟ طبق اسناد این کتابخونه خیر

تصاویر خروجی دستورات در کامنت‌ها

لینک وبسایت

#monitoring

@code_crafters

در ادامه مبحث بنچمارکینگ روی یک پروژه جنگویی پیاده سازی میکنیم و در نهایت با تست عملکرد برای ویوهای ساخته شده با FBV ,CBV بررسی میکنیم عملکرد و محک زدن کدوم بهتره

ابتدا یک پروژه جنگویی همراه یک اپ core ایجاد میکنیم

pip install django

django-admin startproject config .

python manage.py startapp core

در دایرکتوری config

فایل settings.py
INSTALLED_APPS = [
...    
"core",
]

فایل urls.py  
path('', include('core.urls')),

در اپ core کدهای زیر رو وارد میکنیم


models.py

class CategoryModel(models.Model):
    title = models.CharField(max_length=255)

views.py

from django.views.generic import DetailView, ListView
from .models import CategoryModel


def category_list_view(request):
    objs = CategoryModel.objects.all()
    return render(request, 'core/list.html', {"objs":objs})

def category_detail_view(request, pk):
    obj = CategoryModel.objects.get(id=pk)
    return render(request, 'core/detail.html', {"obj":obj})

class CategoryListView(ListView):
    model = CategoryModel
    template_name = 'core/list.html'
    context_object_name = 'objs'

class CategoryDetailView(DetailView):
    model = CategoryModel
    template_name='core/detail.html'
    context_object_name = 'obj'

urls.py

from .views import category_list_view, category_detail_view, CategoryDetailView, CategoryListView

app_name = 'core'

urlpatterns = [
    path('fbv/', category_list_view),
    path('fbv/<pk>/', category_detail_view),
    path('cbv/', CategoryListView.as_view()),
    path('cbv/<pk>/', CategoryDetailView.as_view()),
]

دستورات makemigrations و migrate رو فراموش نکنید

الزامات مربوط به templates در settings و فایلهای list.html , detail.html رو برای اپ core بصورت ساده انجام دهید


جهت راه اندازی بنچمارکینگ نیاز به نصب سه کتابخانه داریم

pip install pytest pytest-benchmark pytest-django

در دایرکتوری root پروژه یک فایل با نام pytest.ini ساخته کدهای زیر رو در ان قرار دهید

[pytest]
DJANGO_SETTINGS_MODULE = config.settings

دلیل اینکار ازین بابت هست که بخشی از کدهای ما وابسته به اجرا شدن پروژه جنگویی می‌باشد و اجرا کردن پروژه جنگویی با صدا زدن فایل تنظیمات آن می‌باشد و به این صورت pytest اینکار رو انجام میدهد


دایرکتوری tests ساخته و داخل ان فایل test_view.py رو میسازیم و کدهای زیر رو داخل اون میزاریم

import pytest
from core.models import CategoryModel
from django.test import RequestFactory
from core.views import category_list_view, category_detail_view, CategoryListView, CategoryDetailView


@pytest.fixture
def rf():
    return RequestFactory()

@pytest.mark.fbv
def test_fbv_list(benchmark, rf):
    request = rf.get('/fbv/')
    result = benchmark(category_list_view, request)
    assert result.status_code == 200

@pytest.mark.fbv
@pytest.mark.django_db
def test_fbv_detail(benchmark, rf):
    blog_comment = CategoryModel.objects.create(title='Test')
    request = rf.get(f'/fbv/{blog_comment.pk}/')
    result = benchmark(category_detail_view, request, pk=blog_comment.pk)
    assert result.status_code == 200

@pytest.mark.cbv
def test_cbv_list(benchmark, rf):
    request = rf.get('/cbv/')
    view = CategoryListView.as_view()
    result = benchmark(view, request)
    assert result.status_code == 200

@pytest.mark.cbv
@pytest.mark.django_db
def test_cbv_detail(benchmark, rf):
    blog_comment = CategoryModel.objects.create(title='Test')
    request = rf.get(f'/cbv/{blog_comment.pk}/')  
    view = CategoryDetailView.as_view()
    result = benchmark(view, request, pk=blog_comment.pk)
    assert result.status_code == 200

دستورات زیر رو در خط فرمان بزنید

pytest -m cbv --benchmark-autosave

pytest -m fbv --benchmark-autosave

pytest-benchmark compare 0001 0002

خروجی بنچمارکینگ و تست عملکرد رو برای ویوهای FBV و CBV در جنگو رو باهم مقایسه کنید


لینک وبسایت

#monitoring

@code_crafters

گرچه بلوچستان در تبعید یکعده هست، اما وجب به وجب خاک آن سرزمین مادری ماست

ممنون از کارخانه x tak بابت فراهم کردن ماشین جهت انتقال کمک‌های مردمی و تمامی مردمان عزیزی که خون در خون انسانیت دارند

فصل دوم کتاب از فصل‌های بشدت محبوب برای من هستش که سعی داره هر اصطلاحی رو در برنامه بنویس بصورت دقیق توصیف کنه


اجرای سریالی و موازی سازی

از بزرگترین معضلات همزمانی و دنیای مهندسی کامپیوتر میتوان به نام گذاری های بد برای توصیف‌ها اشاره کرد ،اسامی نامربوط یا چند اسم داشتن یک موضوع

قبل از بررسی اجرا لازم است خود آنچه اجرا میشود و اصطلاحات مربوط به آن را بشناسیم

یک برنامه بطور کل به مجموعه‌ای از دستورالعمل‌ها گفته میشود که بصورت متوالی اجرا میشود

پردازنده قدرت تحلیل معنایی ندارد، نمیتواند یک جستجو با معنی انجام دهد یا نمیتواند مرتب سازی کند، پردازنده فقط میتونه محدود کارهای ساده‌ای رو انجام بده و تمام تفکر حاصل اون رو برنامه شما مشخص میکنه، تبدیل یک کار به مجموعه‌ای از دستورالعمل‌ها جهت اجرا کاریست که یک توسعه دهنده انجام میدهد

توسعه دهندگان از زبانهای مختلفی جهت پیش برد اهداف خود استفاده میکنن اما پردازنده درکی از کد منبع شما ندارد و تنها زبان ماشین را میفهمد پس لازم هست بیس کدهای شما بوسیله کامپایلر به زبان مناسبی برای پردازنده تبدیل گردد، پردازنده هنگام اجرای کد ماشین میتواند چندین رویکرد داشته باشد که اساسی ترین آن جهت اجرای یک مجموعه دستورالعمل بصورت سریالی است

اجرای سریالی
یک برنامه لیستی از دستورالعمل هاست و البته ترتیب اجرای آن مهم هست

در خصوص برنامه نویسی هم به همین روال هست یک مسئله رو ابتدا به وظایف کوچکی تقسیم میکنیم و سپس آنرا بصورت یکی پس از دیگری یا بصورت سریالی اجرا خواهیم کرد

برنامه نویسی بصورت وظیفه این امکان رو بهمون میده که بصورت مستقل از زبان ماشین محاسبات خود را انجام دهیم که به آن برنامه نویسی ماژولار میگوییم

یک تسک میتواند بخشی از یک کار باشد، اگر جامعه کلامی ما پردازنده باشد میتونیم اون رو یک دستورالعمل بنامیم
یک تسک میتونه یک توالی از عملیات باشه که انتزاعی از یک مدل در دنیای واقعی هست (مثه نوشتن متن در یک فایل)

اما در نهایت میتونیم task رو بعنوان یک واحد اجرا از انتزاع کلی دانست تصویر اول

اجرای سریالی مجموعه‌ای از تسک‌ها هستش که بصورت زنجیروار قرار گرفتن تسک دوم تسک اول رو دنبال میکنه، و تسک دوم توسط تسک سوم دنبال میشه


محاسبات متوالی
برای توصیف پدیده‌های پویا مرتبط با زمان از اصطلاح متوالی استفاده میکنیم تصویر دوم کامنت‌ها برای درک بیشتر یک بازی دونفره رو تصور کنید که نفرات به نوبت و پس از بازی نفر دیگری حق بازی دارند برای درک بهتر بازی شطرنج رو تصور کنید

برنامه دارای مراحل سریال برای حل مشکل است. هر مرحله متکی به نتیجه مرحله قبل است. از این رو، هر مرحله مانع از اجرای مراحل بعدی می شود. ما فقط می توانیم چنین برنامه ای را با استفاده از رویکرد برنامه نویسی متوالی پیاده سازی کنیم. وابستگی آشکاری بین وظایف وجود دارد که به هیچ وجه قابل تجزیه نیست

نقطه مقابل برنامه نویسی متوالی، برنامه ریزی همزمان است. همزمانی بر این ایده استوار است که محاسبات مستقلی وجود دارد که می‌توانند به ترتیب دلخواه با نتیجه یکسان اجرا شوند.

مزایا و معایب محاسبات متوالی
سادگی: هر برنامه ای را میتوان در این پارادایم نوشت یک مفهوم ساده و قابل پیش بینی و رایج است
محاسبات متوالی یک رویکرد ساده با محمچعه‌ای واضح از دستورالعمل‌های گام به گام در مورد اینکه چه باید کرد و در چه زمانی انجام داد هستش

مقیاس پذیری: توانایی یک سیستم برای رسیدگی به مقدار فزاینده‌ای از کار، یا پتانسیل افزایش توانایی سیستم برای رسیدگی به کار برای سازگاری با رشد، با افزودن منابع سخت افزاری اگر بهبودی در سیستم دیده شود سیستم مقیاس پذیر می‌باشد ،اسکیل عمودی تنها راه افزایش مقیاس در محاسبات متوالی هستش

سربار: در محاسبات متوالی هیچ‌ ارتباط یا هماهنگی بین مراحل برنامه مورد نیاز نیست اما یک سربار وجود دارد که ممکن هست از همه منابع استفاده نکنیم


اجرای موازی(parallel)
همانطور که دیدیم، در اجرای سریال، تنها یک دستور در یک زمان اجرا می شود.
برنامه نویسی متوالی همان چیزی است که بیشتر مردم ابتدا یاد می گیرند و اکثر برنامه ها به این صورت نوشته می شوند: اجرا از ابتدای تابع اصلی شروع می شود و به صورت سریالی ادامه می یابد، یک کار/تابع، فراخوانی/عملیات در یک زمان.

وقتی این فرض را حذف می‌کنیم که می‌توانیم فقط یک کار را در یک زمان انجام دهیم، امکان کار موازی را باز می‌کنیم

لینک وب‌سایت

#concurrency

@code_crafters

تصور کنید با شما تماس گرفته و باید سریع به مسافرت برید چهار دست لباس دارید که باید شسته بشن میتونید شروع به شستن کنید اما اگر در نزدیکی شما یک خشکشویی وجود داشته باشد چه؟؟؟سریع به آنجا میروید و همه لباس‌هاتون رو باهم توسط دستگاه‌های متعدد آماده میکنن

در برنامه نویسی زمان لازم برای برای اجرای برنامه متوالی به سرعت پردازنده و سرعت اجرای ان سری از دستورالعمل‌ها محدود میشود مانند شستن لباس توسط خودتون، اما اگر خشکویی وجود داشته باشه چی؟؟؟همه لباس‌ها بصورت موازی شستشو داده میشوند توان عملیاتی شما افزایش می یابد ،در اینجا همان رویکرد اسکیل افقی رو در پیش گرفتیم

اجرای موازی به این معنی است که اجرای کار از نظر فیزیکی همزمان است. اجرای موازی برعکس اجرای سریال است. موازی بودن را می توان با تعداد کارهایی که می توان به صورت موازی اجرا کرد اندازه گیری کرد تصویر اول در کامنت‌ها

استقلال وظیفه در مبحث محاسبات متوالی ما فقط نیاز به پردازنده با کلاک بالاتر بودیم، اما در محاسبات موازی عمدتاً برای کاهش تأخیر با تقسیم یک مسئله به وظایفی که می‌توانند به طور همزمان و مستقل از یکدیگر اجرا شوند، استفاده می‌شود.

استفاده از محاسبات موازی مشکل خاصی است. برای اعمال محاسبات موازی برای یک مسئله، باید این امکان وجود داشته باشد که مسئله به مجموعه ای از وظایف مستقل تجزیه شود تا هر منبع پردازش بتواند بخشی از الگوریتم را به طور همزمان با بقیه اجرا کند. استقلال در اینجا به این معنی است که منابع پردازش می توانند وظایف را به هر ترتیبی که دوست دارند و هر کجا که دوست دارند پردازش کنند، تا زمانی که نتیجه یکسان باشد.
عدم انطباق با این الزام، مشکل را غیرقابل موازی سازی می کند.
کلید درک اینکه آیا یک برنامه می تواند به صورت موازی اجرا شود این است که تجزیه و تحلیل شود که کدام وظایف را می توان تجزیه کرد و کدام وظایف را می توان به طور مستقل اجرا کرد

 برنامه ای که می تواند به صورت موازی اجرا شود، همیشه می تواند متوالی شود، اما یک برنامه متوالی همیشه نمی تواند موازی شود

استقلال کار همیشه امکان پذیر نیست زیرا هر برنامه یا الگوریتمی را نمی توان از ابتدا تا انتها به وظایف مستقل تقسیم کرد. برخی از کارها می توانند مستقل باشند، و برخی نمی توانند اگر به وظایفی که قبلاً اجرا شده اند وابسته باشند.این امر به توسعه دهندگان نیاز دارد تا قطعات مختلف وابسته یک برنامه را برای به دست آوردن نتایج صحیح همگام سازی کنند
همگام سازی به معنای مسدود کردن اجرای وظیفه در انتظار وابستگی است(مثال بازی شطرنج)
هماهنگ کردن محاسبات موازی وابسته به هم از طریق همگام سازی می تواند موازی بودن برنامه را به شدت محدود کند و چالش مهمی را در نوشتن برنامه های موازی در مقایسه با برنامه های متوالی ساده ایجاد می کند.

پشتیبانی سخت افزاری محاسبات موازی نیاز به پشتیبانی سخت افزاری دارد. برنامه های موازی به سخت افزار با منابع پردازشی متعدد نیاز دارند. بدون حداقل دو منبع پردازش، ما نمی توانیم به موازی کاری واقعی دست یابیم

محاسبات موازی
محاسبات موازی از تجزیه برای تقسیم مسائل بزرگ یا پیچیده به وظایف کوچک استفاده می کند و سپس از اجرای موازی سیستم زمان اجرا برای حل موثر آنها استفاده می کند.(برای مثال رویکرد معروف به brute-force)

قانون امدال
اگر فکر میکنید با افزودن منابع بیشتر و موازی سازی کردن بیشتر سرعت رو مدام و مدام افزایش میدهید سخت در اشتباه هستید
تصور کنید سه تسک دارید که زمان اجرایی آنها متفاوت هستش (۱,۴,۳) تسک ۴ رو میتونید به دو تسک دوتایی بشکنید و موازی کنید اما تسک ۳ یک تسک متوالی هست پس هرکاری کنید نمیتونید زمان برنامه رو به کمتر از ۳ برسونید

یک برنامه موازی به سرعت کندترین قسمت متوالی آن اجرا می شود یک فرمول هم داره در تصویر دوم کامنت‌ها

قانون گوستافسون
قانون امدال نباید شما رو نا امید کنه، گوستافسون دیدگاه خوش بینانه تری از محدودیت های موازی ارائه می دهد. اگر مدام حجم کار را افزایش دهیم، قسمت های متوالی اثر کمتر و کمتری خواهند داشت و متناسب با تعداد پردازنده هایی که در اختیار داریم، می توانیم سرعت را مشاهده کنیم
بنابراین اگر زمانی شنیدید که قانون امدال به عنوان دلیلی برای عدم کارایی موازی در مورد شما ذکر شده است، می توانید مشاهده کنید که گوستافسون توضیحی برای آنچه باید انجام دهید داشت.

همزمانی (concurrency) و موازی سازی (parallelism)

همزمانی در مورد وظایف متعددی است که بدون ترتیب خاصی در بازه های زمانی همپوشانی شروع، اجرا و تکمیل میشند

موازی بودن یک ویژگی اجرایی است. این اجرای فیزیکی همزمان وظایف در زمان اجرا است و به سخت افزار با منابع محاسباتی متعدد نیاز دارد روی لایه سخت افزاری قرار دارد

همزمانی و موازی بودن یک چیز نیستند

لینک وب‌سایت

#concurrency

@code_crafters

تفاوت پروفایلینگ و بنچمارکینگ

در چند پست قبلی راجب دو‌موضوع profiling و benchmarking صحبت کردیم
با ابزارهای اون آشنا و بصورت عملی هم اجرا کردیم

تفاوت این دو در چیست؟؟؟
اندازه گیری و بررسی پرفورمنس معمولا شامل دو فرآیند متفاوت است پروفایلینگ و بنچمارکینگ، هر دو روش‌های ضروری برای بهبود عملکرد یک برنامه کاربردی هستند و بسته به موقعیت، تنها تنها یکی از این دو ممکن است اجرا بشه، در حالیکه در موارد دیگر این دو مکمل همدیگه هستند


پروفایلینگ
پروفایلینگ یا نمایه سازی فرآیند جمع اوری معیارها در مورد یک برنامه است. مانند زمان اجرا، حافظه مورد استفاده، تعداد توابع فراخوانی شده و ... در حین اجرای برنامه است. این میتواند زمانی مفید باشد که به دنبال بهینه سازی بخش‌هایی از برنامه هستید


بنچمارکینگ
بنچمارکینگ یا محک زدن فرآیندی است که برای مقایسه دو یا چند سیستم با استفاده از یک اندازه گیری مشترک استفاده میشود تا بتوانید تشخیص دهید کدامیک در برابر آن تست خاص عملکرد بهتری دارد، این برای مقایسه راه حل‌های مختلف نرم افزار یا برای مقایسه تغییرات در نسخه‌های مختلف یک نرم افزار مفید است


در سطح بالایی، تفاوت بین پروفایلینگ و بنچمارکینگ، به بهترین وجه با سوالی که هر تمرین به ترتیب به آن پاسخ میدهد توضیح داده میشود:

پروفایلینگ به شما کمک میکند تا دریابید چرا یک نرم افزار یا زیر سیستم به روش خاصی عمل میکند
بنچمارکینگ به شما کمک میکند تا میزان عملکرد یک نرم افزار یا زیرسیستم را ارزیابی کنید

از آنجایی که هم پروفایلینگ و هم بنچمارکینگ عملکرد را در برخی ظرفیت ها اندازه گیری می کنند، این دو تعریف «چرا در مقابل چقدر خوب» ممکن است هنوز به طور کامل تفاوت آنها را روشن نکنند. نگاه کردن به موقعیت‌های نمونه باید به انتقال تفاوت بین آنها کمک کند:

فرض کنید می‌خواهیم راه‌هایی برای بهبود عملکرد پروژه خود تا آنجا که ممکن است پیدا کنیم:

 برای این کار، باید پروفایل‌سازی را انجام دهیم. ما باید بررسی کنیم که کدام عملکردها طولانی‌ترین زمان را برای اجرا می‌برند تا بتوانیم روی بهبود عملکرد آنهایی که بدترین گلوگاه‌ها هستند تمرکز کنیم. 

فرض کنید می خواهیم عملکرد را بین دو نسخه اصلی پروژه خود مقایسه کنیم تا ببینیم چرخه انتشار دوم چگونه بر عملکرد تأثیر می گذارد. برای این کار، باید بنچمارکینگ انجام دهیم:

 آنها را در مقابل یکدیگر قرار می دهیم و برای مثال، زمان بارگذاری محتوای خاصی را در یک نسخه پروژه خود با زمان بارگذاری همان محتوا در نسخه دیگر مقایسه می کنیم

اساساً، بنچمارک همیشه شامل نوعی مقایسه است:
اگر عملکرد یک نسخه اصلی پروژه را معیار قرار دهیم و هرگز آن را با چیزی مقایسه نکنیم، واقعاً ارزش زیادی ارائه نمی دهد. تا زمانی که آن را با یک نقطه مرجع مقایسه نکنیم، نمی‌توانیم بگوییم که انتشار به‌ویژه خوب است یا نه
با این حال، پروفایل کردن فقط از نگاه یک نسخه ارزشمند است، ما مجبور نیستیم نتایج پروفایل را با مجموعه دیگری از نتایج مقایسه کنیم تا ارزشی از آن بدست آوریم.

یکی دیگر از رابطه‌های بین پروفایلینگ و بنچمارکینگ در توالی آن‌ها است:
در حالی که در برخی موقعیت‌ها، تنها یکی از این دو ممکن است اعمال شود
به طور کلی، پروفایلینگ قبل از اقدام در مورد تغییرات کد اتفاق می‌افتد، در حالی که بنچمارک پس از آن اتفاق می‌افتد

وضعیت زیر را در نظر بگیرید:

-ما می‌خواهیم زمان پاسخ‌دهی سرور اصلی پروژه خود را بهبود بخشیم، بنابراین پروژه را نمایه (profile) می‌کنیم و تشخیص می‌دهیم که یک عملکرد خاص 10٪ از زمان کلی را تشکیل می‌دهد

 -بنابراین ما تصمیم داریم بر روی بهبود عملکرد آن عملکرد تمرکز کنیم، ما منطق را در آن تابع بهبود می‌دهیم تا کارآمدتر باشد، به این امید که تاثیر کلی عملکرد منفی آن را کاهش دهیم

پس از تکمیل تغییر کد، با مقایسه زمان پاسخ سرور قبل از تغییر با زمان پاسخ سرور پس از تغییر، پروژه خود را محک (benchmark) می زنیم تا تأیید کنیم که تغییر (امیدوارم) تا چه اندازه باعث بهبود آن شده است.

لینک وب‌سایت

#monitoring

@code_crafters