diff --git a/star-docs/engineering/02-checklists/elasticsearch/query-analysis.md b/star-docs/engineering/02-checklists/elasticsearch/query-analysis.md
new file mode 100644
index 0000000..99465c1
--- /dev/null
+++ b/star-docs/engineering/02-checklists/elasticsearch/query-analysis.md
@@ -0,0 +1,112 @@
+# بررسی کوئری‌ها
+
+در صورتی که وضعیت کلی کلاستر خوب باشد. ممکن است پاسخ به برخی از کوئری‌های کند باشد و در عمل کارایی مناسب نداشته باشند.
+
+## استخراج کوئری‌های ارسال شده به کلاستر
+
+در حالت عادی کوئری‌های الستیک به صورت مستقیم در کدهای 
+`c#`
+تولید می‌شود و به کلاستر ارسال می‌شود.
+
+در لاگ‌های پرفورمنس فعلی امکان مشاهده‌ی زمان کل درخواست از دید سرویس 
+`DW`
+در کلید
+`details.response_time`
+قابل مشاهده است.
+
+:::tip
+زمان پاسخ کوئری که در پاسخ کلاستر وجود دارد و مستقل از پهنای باند و گلوگاه‌های شبکه‌ای است در کلید
+`details.took`
+قابل مشاهده است.
+:::
+
+:::tip
+تعداد نتایجی که در کوئری واکشی می‌شوند در کلید
+`details.fetch_count`
+مشخص می‌شود. در برخی از کوئری‌های فقط
+`Aggregation`
+ها اهمیت دارند و چون به خود سندها نیاز نیست اندازه و تعداد اسناد واکشی شده 
+`0`
+است.
+:::
+
+:::tip
+در صورتی که برای درخواست‌هایی که 
+تعداد کمی سند واکشی کرده‌اند، اختلاف زمان بین 
+`details.response_time`
+و 
+`details.took`
+زیاد باشد به معنی اختلال شبکه‌ای بین سرویس و کلاستر الستیک است و در این حالت شبکه گلوگاه شده است.
+
+در درخواست‌هایی که تعداد زیادی سند واکشی می‌کنند این اختلاف به دلیل زمان ارسال اطلاعات در شبکه قابل تفسیر است.
+:::
+
+
+### مشاهده‌ی دقیق کوئری ارسال شده
+
+برای مشاهده‌ی متن کوئری
+در سرویس انبارداده ستاره لازم است کانفیگ 
+`LogLevel`
+را در فایل 
+`LADW.config`
+به مقدار 
+`Trace`
+تغییر داده شود.
+بعد از این تغییر و ریست کردن سرویس تمام کوئری‌هایی که به الستیک‌سرچ ارسال می‌شود به صورت کامل در لاگ‌های پرفورمنس در کلید
+`details.debugInforamtion_query`
+ثبت می‌شود.
+
+با بررسی دقیق کوئری می‌توان نابهینگی‌های احتمالی را شناسایی کرد و نتایج را بررسی کرد.
+
+
+## استفاده از Query profiler برای بررسی دقیق علت کندی
+در صورتی که یک کوئری داشته باشیم و بخواهیم دقیقا دلیل کندی و اینکه روی کدام شارد اجرای این کوئری طولانی است را تشخیص دهیم از ابزار
+Query profiler
+استفاده می‌شود.
+
+توضیحات کلی این ویژگی در کیبانا در 
+[این آدرس](https://www.elastic.co/guide/en/kibana/current/xpack-profiler.html)
+قابل مشاهده است.
+
+### زمانی که Build scorer زیاد است
+در صورتی که در یک شارد تعداد اسناد ذخیره شده زیاد باشد.
+(در این مورد منظور از زیاد بیش‌از 100 میلیون سند است)
+بررسی و امتیازدهی به همه‌ی سندها در یک شارد ممکن است بسیار طولانی بشود و کندی‌های زیادی ایجاد کند.
+
+در این حالت لازم است کوئری‌ها به صورت بهینه‌تری تغییر کند که باعث بهبود عملکرد می‌شود و کندی‌های زیاد را کاهش می‌دهد.
+
+#### استفاده از کوئری Filter به جای Must
+همان‌طور که در 
+[این آدرس](https://stackoverflow.com/questions/43349044/what-is-the-difference-between-must-and-filter-in-query-dsl-in-elasticsearch)
+توضیح داده شده است استفاده از 
+Filter 
+به دلیل عدم امتیازدهی به اسناد بهینه‌تر است.
+
+#### نابهینگی کوئری Terms
+یکی از کوئری‌هایی که در الستیک‌سرج مطرح است
+[`Terms query`](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-terms-query.html)
+طبق تست‌های انجام شده این کوئری در زمانی که تعداد اسناد یک شارد خیلی زیاد می‌شود بهینه نیست و بهتر است از
+[`Term query`](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-term-query.html)
+استفاده شود. و در صورت نیاز انتخاب چند مقدار از
+Bool query 
+و عبارت
+Should
+استفاده شود.
+
+:::tip
+در انبارداده ستاره
+برای مواجه با این مشکل کانفیگی برای تغییر منطق کوئری ایجاد شده است. در صورتی که تعداد منابع مورد نظر در یک کوئری کم‌تر از مقدار کانفیگ 
+`RecordWarehouseIdQueryThreshold`
+باشد.
+کوئری با ساختار
+Bool query 
+و لیستی از 
+Should ها
+قرار می‌گیرد.
+
+در صورتی که تعداد منابع خیلی زیاد شود برای جلوگیری از زیاد شدن تعداد کلازها و عدم مواجه با خطای 
+`max clause`
+الستیک‌سرچ کوئری‌ها به صورت 
+Terms
+ساخته می‌شود.
+:::
\ No newline at end of file