پرو ہوسٹر > بلاگ > انتظامیہ > ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast

ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast

اس مضمون میں ہم بات کریں گے کہ ہم نے کیسے اور کیوں ترقی کی۔ تعامل کا نظام - ایک طریقہ کار جو کلائنٹ ایپلی کیشنز اور 1C: انٹرپرائز سرورز کے درمیان معلومات کو منتقل کرتا ہے - ایک کام کو ترتیب دینے سے لے کر فن تعمیر اور نفاذ کی تفصیلات کے ذریعے سوچنے تک۔

تعامل کا نظام (اس کے بعد SV کہا جاتا ہے) ایک تقسیم شدہ، غلطی برداشت کرنے والا پیغام رسانی کا نظام ہے جس کی ضمانت کی ترسیل ہے۔ SV کو ایک ہائی لوڈ سروس کے طور پر ڈیزائن کیا گیا ہے جس میں اعلی اسکیل ایبلٹی ہے، جو آن لائن سروس (1C کے ذریعے فراہم کردہ) اور بڑے پیمانے پر تیار کردہ پروڈکٹ کے طور پر دستیاب ہے جسے آپ کے اپنے سرور کی سہولیات پر تعینات کیا جا سکتا ہے۔

SV تقسیم شدہ اسٹوریج کا استعمال کرتا ہے۔ ہیزل کاسٹ اور سرچ انجن Elasticsearch. ہم جاوا کے بارے میں بھی بات کریں گے اور یہ کہ ہم پوسٹگری ایس کیو ایل کو افقی طور پر کیسے پیمانہ کرتے ہیں۔
ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast

مسئلہ کی تشکیل

یہ واضح کرنے کے لیے کہ ہم نے انٹرایکشن سسٹم کیوں بنایا، میں آپ کو اس بارے میں تھوڑا سا بتاؤں گا کہ 1C میں کاروباری ایپلی کیشنز کی ترقی کیسے کام کرتی ہے۔

شروع کرنے کے لیے، ہمارے بارے میں ان لوگوں کے لیے جو ابھی تک نہیں جانتے کہ ہم کیا کرتے ہیں :) ہم 1C:Enterprise ٹیکنالوجی پلیٹ فارم بنا رہے ہیں۔ پلیٹ فارم میں بزنس ایپلیکیشن ڈویلپمنٹ ٹول کے ساتھ ساتھ رن ٹائم بھی شامل ہے جو کاروباری ایپلیکیشنز کو کراس پلیٹ فارم ماحول میں چلانے کی اجازت دیتا ہے۔

کلائنٹ سرور کی ترقی کا نمونہ

1C پر تخلیق کردہ کاروباری ایپلیکیشنز: انٹرپرائز تین سطحوں پر کام کرتی ہے۔ کلائنٹ سرور فن تعمیر "DBMS - ایپلیکیشن سرور - کلائنٹ"۔ درخواست کا کوڈ لکھا ہوا ہے۔ بلٹ ان 1C زبان، ایپلیکیشن سرور یا کلائنٹ پر عمل میں لایا جا سکتا ہے۔ ایپلیکیشن آبجیکٹ (ڈائریکٹریز، دستاویزات وغیرہ) کے ساتھ ساتھ ڈیٹا بیس کو پڑھنے اور لکھنے کے تمام کام صرف سرور پر کیے جاتے ہیں۔ فارم اور کمانڈ انٹرفیس کی فعالیت بھی سرور پر لاگو ہوتی ہے۔ کلائنٹ فارم وصول کرنے، کھولنے اور ظاہر کرنے، صارف کے ساتھ "مواصلت" کرتا ہے (انتباہات، سوالات...)، فارموں میں چھوٹے حسابات جن کے لیے فوری جواب کی ضرورت ہوتی ہے (مثال کے طور پر، قیمت کو مقدار سے ضرب دینا)، مقامی فائلوں کے ساتھ کام کرنا، سامان کے ساتھ کام کرنا.

ایپلیکیشن کوڈ میں، طریقہ کار اور افعال کے ہیڈرز کو واضح طور پر اس بات کی نشاندہی کرنی چاہیے کہ کوڈ کو کہاں لاگو کیا جائے گا - &AtClient / &AtServer ہدایات (&AtClient / &AtServer زبان کے انگریزی ورژن میں) کا استعمال کرتے ہوئے۔ 1C ڈویلپرز اب مجھے یہ کہہ کر درست کریں گے کہ ہدایات دراصل ہیں۔ بہترلیکن ہمارے لیے یہ اب اہم نہیں ہے۔

آپ کلائنٹ کوڈ سے سرور کوڈ کو کال کرسکتے ہیں، لیکن آپ سرور کوڈ سے کلائنٹ کوڈ کو کال نہیں کرسکتے ہیں۔ یہ ایک بنیادی حد ہے جسے ہم نے کئی وجوہات کی بنا پر بنایا ہے۔ خاص طور پر، کیونکہ سرور کوڈ کو اس طرح لکھا جانا چاہیے کہ یہ اسی طرح عمل میں آتا ہے چاہے اسے کہیں بھی بلایا جائے - کلائنٹ سے یا سرور سے۔ اور دوسرے سرور کوڈ سے سرور کوڈ کال کرنے کی صورت میں، ایسا کوئی کلائنٹ نہیں ہے۔ اور چونکہ سرور کوڈ کے نفاذ کے دوران، اس کو کال کرنے والا کلائنٹ بند کر سکتا ہے، ایپلیکیشن سے باہر نکل سکتا ہے، اور سرور کے پاس اب کسی کو کال کرنے کی ضرورت نہیں ہوگی۔

ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast
کوڈ جو بٹن پر کلک کو ہینڈل کرتا ہے: کلائنٹ سے سرور کے طریقہ کار کو کال کرنا کام کرے گا، سرور سے کلائنٹ کے طریقہ کار کو کال کرنا کام نہیں کرے گا

اس کا مطلب یہ ہے کہ اگر ہم سرور سے کلائنٹ ایپلیکیشن کو کچھ پیغام بھیجنا چاہتے ہیں، مثال کے طور پر، کہ ایک "طویل عرصے سے چلنے والی" رپورٹ کی جنریشن ختم ہو گئی ہے اور رپورٹ دیکھی جا سکتی ہے، ہمارے پاس ایسا کوئی طریقہ نہیں ہے۔ آپ کو ٹرکس استعمال کرنے ہوں گے، مثال کے طور پر، وقتاً فوقتاً کلائنٹ کوڈ سے سرور کو پول کریں۔ لیکن یہ نقطہ نظر سسٹم کو غیر ضروری کالوں کے ساتھ لوڈ کرتا ہے، اور عام طور پر بہت خوبصورت نہیں لگتا۔

اور ضرورت بھی ہے، مثلاً جب کوئی ٹیلی فون آئے آئی پی- کال کرتے وقت، کلائنٹ ایپلیکیشن کو اس بارے میں مطلع کریں تاکہ وہ کال کرنے والے کا نمبر استعمال کر کے اسے کاؤنٹر پارٹی ڈیٹا بیس میں تلاش کر سکے اور صارف کو کال کرنے والے کاؤنٹر پارٹی کے بارے میں معلومات دکھا سکے۔ یا، مثال کے طور پر، جب گودام میں کوئی آرڈر آتا ہے، تو اس کے بارے میں گاہک کے کلائنٹ کی درخواست کو مطلع کریں۔ عام طور پر، بہت سے معاملات ہیں جہاں اس طرح کا طریقہ کار مفید ہو گا.

پیداوار خود

پیغام رسانی کا طریقہ کار بنائیں۔ تیز، قابل اعتماد، ضمانت شدہ ترسیل کے ساتھ، لچکدار طریقے سے پیغامات تلاش کرنے کی صلاحیت کے ساتھ۔ میکانزم کی بنیاد پر، 1C ایپلی کیشنز کے اندر چلنے والے میسنجر (پیغامات، ویڈیو کالز) کو لاگو کریں۔

نظام کو افقی طور پر توسیع پذیر ہونے کے لیے ڈیزائن کریں۔ بڑھتے ہوئے بوجھ کو نوڈس کی تعداد میں اضافہ کرکے پورا کیا جانا چاہیے۔

Реализация

ہم نے SV کے سرور حصے کو براہ راست 1C:Enterprise پلیٹ فارم میں ضم نہ کرنے کا فیصلہ کیا، بلکہ اسے ایک علیحدہ پروڈکٹ کے طور پر لاگو کرنے کا فیصلہ کیا، جس کا API 1C ایپلیکیشن سلوشنز کے کوڈ سے طلب کیا جا سکتا ہے۔ یہ کئی وجوہات کی بنا پر کیا گیا تھا، جن میں سے ایک اہم وجہ یہ تھی کہ میں مختلف 1C ایپلی کیشنز کے درمیان پیغامات کا تبادلہ ممکن بنانا چاہتا تھا (مثال کے طور پر، ٹریڈ مینجمنٹ اور اکاؤنٹنگ کے درمیان)۔ مختلف 1C ایپلیکیشنز 1C کے مختلف ورژنز پر چل سکتی ہیں: انٹرپرائز پلیٹ فارم، مختلف سرورز پر واقع ہو، وغیرہ۔ ایسے حالات میں، 1C تنصیبات کے "سائیڈ پر" واقع ایک علیحدہ پروڈکٹ کے طور پر SV کا نفاذ بہترین حل ہے۔

لہذا، ہم نے SV کو ایک علیحدہ پروڈکٹ کے طور پر بنانے کا فیصلہ کیا۔ ہم تجویز کرتے ہیں کہ چھوٹی کمپنیاں CB سرور کا استعمال کریں جو ہم نے اپنے کلاؤڈ (wss://1cdialog.com) میں انسٹال کیا ہے تاکہ سرور کی مقامی تنصیب اور ترتیب سے وابستہ اوور ہیڈ لاگت سے بچا جا سکے۔ بڑے کلائنٹس کو یہ مشورہ دیا جا سکتا ہے کہ وہ اپنی سہولیات پر اپنا سی بی سرور انسٹال کریں۔ ہم نے اپنے کلاؤڈ SaaS پروڈکٹ میں اسی طرح کا طریقہ استعمال کیا۔ 1c تازہ - یہ کلائنٹس کی سائٹس پر انسٹالیشن کے لیے بڑے پیمانے پر تیار کردہ پروڈکٹ کے طور پر تیار کیا جاتا ہے، اور ہمارے کلاؤڈ میں بھی تعینات کیا جاتا ہے۔ https://1cfresh.com/.

درخواست

لوڈ اور فالٹ ٹولرنس کو تقسیم کرنے کے لیے، ہم ایک جاوا ایپلیکیشن نہیں، بلکہ کئی، ان کے سامنے لوڈ بیلنسر کے ساتھ تعینات کریں گے۔ اگر آپ کو کوئی پیغام نوڈ سے نوڈ میں منتقل کرنے کی ضرورت ہے تو Hazelcast میں شائع/سبسکرائب کریں۔

کلائنٹ اور سرور کے درمیان مواصلت ویب ساکٹ کے ذریعے ہوتی ہے۔ یہ ریئل ٹائم سسٹمز کے لیے موزوں ہے۔

تقسیم شدہ کیش

ہم نے Redis، Hazelcast اور Ehcache کے درمیان انتخاب کیا۔ یہ 2015 کی بات ہے۔ ریڈیس نے ابھی ایک نیا کلسٹر جاری کیا (بہت نیا، خوفناک)، بہت ساری پابندیوں کے ساتھ سینٹینیل ہے۔ Ehcache ایک کلسٹر میں جمع ہونے کا طریقہ نہیں جانتا ہے (یہ فعالیت بعد میں ظاہر ہوئی)۔ ہم نے اسے ہیزل کاسٹ 3.4 کے ساتھ آزمانے کا فیصلہ کیا۔
ہیزل کاسٹ کو باکس سے باہر ایک کلسٹر میں جمع کیا جاتا ہے۔ سنگل نوڈ موڈ میں، یہ زیادہ کارآمد نہیں ہے اور اسے صرف کیش کے طور پر استعمال کیا جا سکتا ہے - یہ نہیں جانتا کہ ڈیٹا کو ڈسک پر کیسے پھینکا جائے، اگر آپ واحد نوڈ کھو دیتے ہیں، تو آپ ڈیٹا کھو دیتے ہیں۔ ہم کئی Hazelcasts تعینات کرتے ہیں، جن کے درمیان ہم اہم ڈیٹا کا بیک اپ لیتے ہیں۔ ہم کیشے کا بیک اپ نہیں لیتے ہیں - ہمیں اس پر کوئی اعتراض نہیں ہے۔

ہمارے لیے، Hazelcast ہے:

  • صارف کے سیشنوں کا ذخیرہ۔ ہر بار سیشن کے لیے ڈیٹا بیس میں جانے میں کافی وقت لگتا ہے، اس لیے ہم نے تمام سیشنز کو ہیزل کاسٹ میں رکھا ہے۔
  • کیشے اگر آپ صارف پروفائل تلاش کر رہے ہیں تو، کیشے کو چیک کریں۔ ایک نیا پیغام لکھا - اسے کیشے میں ڈالیں۔
  • درخواست کی مثالوں کے درمیان مواصلت کے لیے موضوعات۔ نوڈ ایک واقعہ تیار کرتا ہے اور اسے ہیزل کاسٹ کے عنوان میں رکھتا ہے۔ اس موضوع پر سبسکرائب کردہ دیگر ایپلیکیشن نوڈس ایونٹ کو وصول کرتے اور اس پر کارروائی کرتے ہیں۔
  • کلسٹر تالے مثال کے طور پر، ہم ایک منفرد کلید (1C ڈیٹا بیس کے اندر سنگلٹن ڈسکشن):

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

ہم نے چیک کیا کہ کوئی چینل نہیں ہے۔ ہم نے تالا لیا، اسے دوبارہ چیک کیا، اور اسے بنایا۔ اگر آپ لاک لینے کے بعد لاک کو چیک نہیں کرتے ہیں، تو امکان ہے کہ اس وقت کسی اور تھریڈ نے بھی چیک کیا ہو اور اب وہی بحث کرنے کی کوشش کریں گے - لیکن یہ پہلے سے موجود ہے۔ آپ مطابقت پذیر یا ریگولر جاوا لاک کا استعمال کرکے لاک نہیں کرسکتے ہیں۔ ڈیٹا بیس کے ذریعے - یہ سست ہے، اور یہ ڈیٹا بیس کے لیے افسوس کی بات ہے؛ ہیزل کاسٹ کے ذریعے - یہ وہی ہے جس کی آپ کو ضرورت ہے۔

ڈی بی ایم ایس کا انتخاب

ہمارے پاس PostgreSQL کے ساتھ کام کرنے اور اس DBMS کے ڈویلپرز کے ساتھ تعاون کرنے کا وسیع اور کامیاب تجربہ ہے۔

PostgreSQL کلسٹر کے ساتھ یہ آسان نہیں ہے - وہاں ہے۔ XL, XC, سائٹس، لیکن عام طور پر یہ NoSQLs نہیں ہیں جو باکس سے باہر ہیں۔ ہم نے NoSQL کو مرکزی اسٹوریج کے طور پر نہیں سمجھا؛ یہ کافی تھا کہ ہم نے Hazelcast لیا، جس کے ساتھ ہم نے پہلے کام نہیں کیا تھا۔

اگر آپ کو متعلقہ ڈیٹا بیس کی پیمائش کرنے کی ضرورت ہے، تو اس کا مطلب ہے۔ شارڈنگ. جیسا کہ آپ جانتے ہیں، شارڈنگ کے ساتھ ہم ڈیٹا بیس کو الگ الگ حصوں میں تقسیم کرتے ہیں تاکہ ان میں سے ہر ایک کو الگ سرور پر رکھا جا سکے۔

ہمارے شارڈنگ کے پہلے ورژن نے ہماری ایپلیکیشن کے ہر ٹیبل کو مختلف سرورز پر مختلف تناسب میں تقسیم کرنے کی صلاحیت کو فرض کیا۔ سرور A پر بہت سارے پیغامات ہیں - براہ کرم، آئیے اس ٹیبل کے کچھ حصے کو سرور B میں منتقل کریں۔ یہ فیصلہ صرف قبل از وقت اصلاح کے بارے میں چیختا ہے، اس لیے ہم نے خود کو کثیر کرایہ دار تک محدود رکھنے کا فیصلہ کیا۔

آپ ملٹی کرایہ دار کے بارے میں پڑھ سکتے ہیں، مثال کے طور پر، ویب سائٹ پر سائٹس ڈیٹا.

SV میں درخواست اور سبسکرائبر کے تصورات ہیں۔ ایپلیکیشن ایک کاروباری ایپلیکیشن کی مخصوص تنصیب ہے، جیسے ERP یا اکاؤنٹنگ، اس کے صارفین اور کاروباری ڈیٹا کے ساتھ۔ سبسکرائبر ایک تنظیم یا فرد ہے جس کی جانب سے درخواست SV سرور میں رجسٹرڈ ہے۔ ایک سبسکرائبر کے پاس کئی ایپلیکیشنز رجسٹر ہو سکتی ہیں، اور یہ ایپلیکیشنز ایک دوسرے کے ساتھ پیغامات کا تبادلہ کر سکتی ہیں۔ سبسکرائبر ہمارے سسٹم میں کرایہ دار بن گیا۔ متعدد سبسکرائبرز کے پیغامات ایک فزیکل ڈیٹا بیس میں موجود ہو سکتے ہیں۔ اگر ہم دیکھتے ہیں کہ ایک سبسکرائبر نے بہت زیادہ ٹریفک پیدا کرنا شروع کر دیا ہے، تو ہم اسے ایک علیحدہ فزیکل ڈیٹا بیس (یا یہاں تک کہ ایک علیحدہ ڈیٹا بیس سرور) میں منتقل کر دیتے ہیں۔

ہمارے پاس ایک اہم ڈیٹا بیس ہے جہاں ایک روٹنگ ٹیبل تمام سبسکرائبر ڈیٹا بیس کے محل وقوع کے بارے میں معلومات کے ساتھ محفوظ کیا جاتا ہے۔

ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast

مرکزی ڈیٹا بیس کو رکاوٹ بننے سے روکنے کے لیے، ہم روٹنگ ٹیبل (اور دیگر اکثر درکار ڈیٹا) کو کیشے میں رکھتے ہیں۔

اگر سبسکرائبر کا ڈیٹا بیس سست ہونا شروع ہو جائے تو ہم اسے اندر سے پارٹیشنز میں کاٹ دیں گے۔ دوسرے منصوبوں پر جو ہم استعمال کرتے ہیں۔ pg_pathman.

چونکہ صارف کے پیغامات کو کھونا برا ہے، اس لیے ہم اپنے ڈیٹا بیس کو نقل کے ساتھ برقرار رکھتے ہیں۔ ہم وقت ساز اور غیر مطابقت پذیر نقلوں کا امتزاج آپ کو مرکزی ڈیٹا بیس کے ضائع ہونے کی صورت میں خود کو بیمہ کرنے کی اجازت دیتا ہے۔ پیغام کا نقصان صرف اس صورت میں ہوگا جب بنیادی ڈیٹا بیس اور اس کی ہم وقت ساز نقل بیک وقت ناکام ہوجائے۔

اگر ایک ہم وقت ساز نقل گم ہو جائے تو، غیر مطابقت پذیر نقل مطابقت پذیر ہو جاتی ہے۔
اگر مرکزی ڈیٹا بیس کھو جاتا ہے تو، ہم وقت ساز نقل مرکزی ڈیٹا بیس بن جاتی ہے، اور غیر مطابقت پذیر نقل ایک ہم وقت ساز نقل بن جاتی ہے۔

تلاش کے لیے لچکدار تلاش

چونکہ، دیگر چیزوں کے علاوہ، SV بھی ایک میسنجر ہے، اس کے لیے غلط مماثلتوں کا استعمال کرتے ہوئے، مورفولوجی کو مدنظر رکھتے ہوئے، تیز، آسان اور لچکدار تلاش کی ضرورت ہے۔ ہم نے وہیل کو دوبارہ ایجاد نہ کرنے اور لائبریری کی بنیاد پر بنائے گئے مفت سرچ انجن Elasticsearch کو استعمال کرنے کا فیصلہ کیا ہے۔ لوسن. ہم ایپلیکیشن نوڈس کی ناکامی کی صورت میں مسائل کو ختم کرنے کے لیے ایک کلسٹر (ماسٹر – ڈیٹا – ڈیٹا) میں Elasticsearch کو بھی تعینات کرتے ہیں۔

گیتھب پر ہمیں ملا روسی مورفولوجی پلگ ان Elasticsearch کے لیے اور اسے استعمال کریں۔ Elasticsearch انڈیکس میں ہم لفظ کی جڑیں (جس کا تعین پلگ ان کرتا ہے) اور N-grams کو محفوظ کرتے ہیں۔ جیسا کہ صارف تلاش کرنے کے لیے متن داخل کرتا ہے، ہم N-grams کے درمیان ٹائپ شدہ متن کو تلاش کرتے ہیں۔ انڈیکس میں محفوظ ہونے پر، لفظ "متن" مندرجہ ذیل N-grams میں تقسیم ہو جائے گا:

[وہ، ٹیک، ٹیکس، متن، متن، ایک، سابق، ایکسٹ، متن، ks، kst، ksty، st، sty، آپ]،

اور لفظ "متن" کی جڑ بھی محفوظ رہے گی۔ یہ نقطہ نظر آپ کو شروع میں، درمیان میں اور لفظ کے آخر میں تلاش کرنے کی اجازت دیتا ہے۔

مجموعی طور پر تصویر

ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast
مضمون کے آغاز سے تصویر کو دہرائیں، لیکن وضاحت کے ساتھ:

  • بیلنسر انٹرنیٹ پر بے نقاب؛ ہمارے پاس nginx ہے، یہ کوئی بھی ہو سکتا ہے۔
  • جاوا ایپلیکیشن کی مثالیں ہیزل کاسٹ کے ذریعے ایک دوسرے کے ساتھ بات چیت کرتی ہیں۔
  • ویب ساکٹ کے ساتھ کام کرنے کے لیے ہم استعمال کرتے ہیں۔ Netty.
  • جاوا ایپلیکیشن جاوا 8 میں لکھی گئی ہے اور بنڈلز پر مشتمل ہے۔ او ایس جی آئی. منصوبوں میں جاوا 10 میں منتقلی اور ماڈیولز میں منتقلی شامل ہے۔

ترقی اور جانچ

SV کو تیار کرنے اور جانچنے کے عمل میں، ہم نے جو پروڈکٹس ہم استعمال کرتے ہیں ان کی متعدد دلچسپ خصوصیات کو دیکھا۔

لوڈ ٹیسٹنگ اور میموری لیک

ہر ایس وی ریلیز کی ریلیز میں لوڈ ٹیسٹنگ شامل ہوتی ہے۔ یہ کامیاب ہے جب:

  • ٹیسٹ کئی دنوں تک کام کرتا رہا اور سروس میں کوئی ناکامی نہیں ہوئی۔
  • کلیدی کارروائیوں کے لیے رسپانس ٹائم آرام دہ حد سے زیادہ نہیں تھا۔
  • پچھلے ورژن کے مقابلے کارکردگی کی خرابی 10٪ سے زیادہ نہیں ہے

ہم ٹیسٹ ڈیٹا بیس کو ڈیٹا سے بھرتے ہیں - ایسا کرنے کے لیے، ہم پروڈکشن سرور سے سب سے زیادہ فعال سبسکرائبر کے بارے میں معلومات حاصل کرتے ہیں، اس کے نمبروں کو 5 سے ضرب دیتے ہیں (پیغامات، بات چیت، صارفین کی تعداد) اور اس طرح اس کی جانچ کرتے ہیں۔

ہم تعامل کے نظام کی لوڈ ٹیسٹنگ تین کنفیگریشنز میں کرتے ہیں:

  1. دباؤ کی جانچ پڑتال
  2. صرف رابطے
  3. سبسکرائبر رجسٹریشن

تناؤ کے امتحان کے دوران، ہم کئی سو تھریڈز لانچ کرتے ہیں، اور وہ بغیر رکے سسٹم کو لوڈ کرتے ہیں: پیغامات لکھنا، بات چیت کرنا، پیغامات کی فہرست وصول کرنا۔ ہم عام صارفین کے اعمال (میرے بغیر پڑھے ہوئے پیغامات کی فہرست حاصل کریں، کسی کو لکھیں) اور سافٹ ویئر سلوشنز (مختلف کنفیگریشن کا پیکج منتقل کریں، الرٹ پر کارروائی کریں) کی تقلید کرتے ہیں۔

مثال کے طور پر، تناؤ کے ٹیسٹ کا یہ حصہ ایسا لگتا ہے:

  • صارف لاگ ان ہوتا ہے۔
    • آپ کے بغیر پڑھے ہوئے مباحثے کی درخواست کرتا ہے۔
    • 50% پیغامات پڑھنے کا امکان
    • 50% متن کا امکان
    • اگلا صارف:
      • ایک نئی بحث تخلیق کرنے کا 20% امکان ہے۔
      • بے ترتیب طور پر اس کے کسی بھی مباحثے کو منتخب کرتا ہے۔
      • اندر جاتا ہے۔
      • پیغامات، صارف پروفائلز کی درخواست کرتا ہے۔
      • اس بحث سے بے ترتیب صارفین کے لیے پانچ پیغامات تخلیق کرتا ہے۔
      • بحث چھوڑ دیتا ہے۔
      • 20 بار دہرایا جاتا ہے۔
      • لاگ آؤٹ، اسکرپٹ کے آغاز پر واپس چلا جاتا ہے۔

    • ایک چیٹ بوٹ سسٹم میں داخل ہوتا ہے (ایپلی کیشن کوڈ سے پیغام رسانی کی تقلید کرتا ہے)
      • ڈیٹا ایکسچینج کے لیے ایک نیا چینل بنانے کا 50% موقع ہے (خصوصی بحث)
      • 50% امکان ہے کہ موجودہ چینلز میں سے کسی کو پیغام لکھیں۔

"صرف کنکشنز" کا منظر نامہ ایک وجہ سے ظاہر ہوا۔ ایک صورت حال ہے: صارفین نے سسٹم کو جوڑ دیا ہے، لیکن ابھی تک اس میں شامل نہیں ہوئے ہیں۔ ہر صارف صبح 09:00 بجے کمپیوٹر آن کرتا ہے، سرور سے رابطہ قائم کرتا ہے اور خاموش رہتا ہے۔ یہ لوگ خطرناک ہیں، ان میں سے بہت سے ہیں - ان کے پاس صرف PING/PONG ہیں، لیکن وہ سرور سے کنکشن برقرار رکھتے ہیں (وہ اسے برقرار نہیں رکھ سکتے - اگر کوئی نیا پیغام ہے تو کیا ہوگا)۔ ٹیسٹ ایک ایسی صورتحال کو دوبارہ پیش کرتا ہے جہاں ایسے صارفین کی ایک بڑی تعداد آدھے گھنٹے میں سسٹم میں لاگ ان ہونے کی کوشش کرتی ہے۔ یہ تناؤ کے ٹیسٹ کی طرح ہے، لیکن اس کی توجہ بالکل اس پہلے ان پٹ پر ہے - تاکہ کوئی ناکامی نہ ہو (ایک شخص سسٹم کا استعمال نہیں کرتا ہے، اور یہ پہلے ہی گر جاتا ہے - اس سے بدتر کے بارے میں سوچنا مشکل ہے)۔

سبسکرائبر رجسٹریشن اسکرپٹ پہلی لانچ سے شروع ہوتی ہے۔ ہم نے ایک تناؤ کا ٹیسٹ کیا اور ہمیں یقین تھا کہ خط و کتابت کے دوران نظام سست نہیں ہوا۔ لیکن صارفین آئے اور وقت ختم ہونے کی وجہ سے رجسٹریشن ناکام ہونا شروع ہو گئی۔ رجسٹریشن کرتے وقت ہم نے استعمال کیا۔ / dev / بے ترتیب، جس کا تعلق نظام کی اینٹروپی سے ہے۔ سرور کے پاس کافی انٹراپی جمع کرنے کا وقت نہیں تھا اور جب ایک نئے SecureRandom کی درخواست کی گئی تو یہ دسیوں سیکنڈ کے لیے منجمد ہو گیا۔ اس صورت حال سے نکلنے کے بہت سے طریقے ہیں، مثال کے طور پر: کم محفوظ /dev/urandom پر سوئچ کریں، ایک خاص بورڈ انسٹال کریں جو اینٹروپی پیدا کرے، پہلے سے بے ترتیب نمبر تیار کریں اور انہیں پول میں محفوظ کریں۔ ہم نے پول کے ساتھ مسئلہ کو عارضی طور پر بند کر دیا، لیکن اس کے بعد سے ہم نئے سبسکرائبرز کو رجسٹر کرنے کے لیے ایک الگ ٹیسٹ چلا رہے ہیں۔

ہم لوڈ جنریٹر کے طور پر استعمال کرتے ہیں۔ جے میٹر. یہ نہیں جانتا کہ ویب ساکٹ کے ساتھ کیسے کام کرنا ہے؛ اسے ایک پلگ ان کی ضرورت ہے۔ سوال "jmeter websocket" کے تلاش کے نتائج میں سب سے پہلے یہ ہیں: BlazeMeter سے مضامین، جو تجویز کرتے ہیں۔ Maciej Zaleski کی طرف سے پلگ ان.

یہیں سے ہم نے شروع کرنے کا فیصلہ کیا۔

سنجیدہ جانچ شروع کرنے کے تقریباً فوراً بعد، ہم نے دریافت کیا کہ JMeter نے میموری کو لیک کرنا شروع کر دیا ہے۔

پلگ ان ایک الگ بڑی کہانی ہے؛ 176 ستاروں کے ساتھ، اس کے گیتھب پر 132 فورک ہیں۔ مصنف نے خود 2015 سے اس کا ارتکاب نہیں کیا ہے (ہم نے اسے 2015 میں لیا تھا، پھر اس سے شکوک پیدا نہیں ہوئے)، میموری لیک کے حوالے سے کئی گیتھب مسائل، 7 غیر بند پل کی درخواستیں۔
اگر آپ اس پلگ ان کا استعمال کرتے ہوئے لوڈ ٹیسٹنگ کرنے کا فیصلہ کرتے ہیں، تو براہ کرم درج ذیل بات چیت پر توجہ دیں:

  1. ملٹی تھریڈڈ ماحول میں، ایک باقاعدہ LinkedList استعمال کی گئی تھی، اور نتیجہ یہ نکلا تھا۔ این پی ای رن ٹائم میں یہ یا تو ConcurrentLinkedDeque پر سوئچ کر کے یا مطابقت پذیر بلاکس کے ذریعے حل کیا جا سکتا ہے۔ ہم نے اپنے لیے پہلا آپشن چنا (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
  2. میموری لیک؛ منقطع ہونے پر، کنکشن کی معلومات کو حذف نہیں کیا جاتا ہے (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
  3. اسٹریمنگ موڈ میں (جب ویب ساکٹ نمونے کے آخر میں بند نہیں ہوتا ہے، لیکن بعد میں پلان میں استعمال ہوتا ہے)، جوابی نمونے کام نہیں کرتے ہیں (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

یہ گیتوب پر ان میں سے ایک ہے۔ ہم نے کیا کیا:

  1. لے چکے ہیں۔ فورک ایلیران کوگن (@elyrank) - یہ مسائل 1 اور 3 کو ٹھیک کرتا ہے۔
  2. حل شدہ مسئلہ 2
  3. جیٹی کو 9.2.14 سے 9.3.12 تک اپ ڈیٹ کیا گیا۔
  4. ThreadLocal میں سمپل ڈیٹ فارمیٹ لپیٹ کر SimpleDateFormat تھریڈ سے محفوظ نہیں ہے، جس کی وجہ سے رن ٹائم پر NPE ہوا۔
  5. ایک اور میموری لیک کو ٹھیک کیا (منقطع ہونے پر کنکشن غلط طریقے سے بند ہو گیا تھا)

اور پھر بھی یہ بہتا ہے!

یادداشت ایک دن میں نہیں دو میں ختم ہونے لگی۔ بالکل وقت باقی نہیں تھا، اس لیے ہم نے کم تھریڈز شروع کرنے کا فیصلہ کیا، لیکن چار ایجنٹوں پر۔ یہ کم از کم ایک ہفتے کے لیے کافی ہونا چاہیے تھا۔

دو دن گزر گئے...

اب ہیزل کاسٹ کی یادداشت ختم ہو رہی ہے۔ لاگز سے پتہ چلتا ہے کہ چند دنوں کی جانچ کے بعد، ہیزل کاسٹ نے یادداشت کی کمی کی شکایت کرنا شروع کر دی، اور کچھ دیر بعد کلسٹر الگ ہو گیا، اور نوڈس ایک ایک کر کے مرنے لگے۔ ہم نے JVisualVM کو ہیزل کاسٹ سے منسلک کیا اور ایک "بڑھتی ہوئی آری" دیکھی - اسے باقاعدگی سے GC کہا جاتا ہے، لیکن میموری کو صاف نہیں کر سکا۔

ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast

یہ پتہ چلا کہ ہیزل کاسٹ 3.4 میں، نقشہ / ملٹی میپ (map.destroy()) کو حذف کرتے وقت، میموری مکمل طور پر آزاد نہیں ہوتی ہے۔

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

بگ کو اب 3.5 میں ٹھیک کر دیا گیا ہے، لیکن اس وقت یہ ایک مسئلہ تھا۔ ہم نے متحرک ناموں کے ساتھ نئے ملٹی میپس بنائے اور اپنی منطق کے مطابق انہیں حذف کر دیا۔ کوڈ کچھ اس طرح نظر آیا:

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

کال کریں:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

ملٹی میپ ہر سبسکرپشن کے لیے بنایا گیا تھا اور جب اس کی ضرورت نہیں تھی تو اسے حذف کر دیا گیا تھا۔ ہم نے فیصلہ کیا کہ ہم نقشہ شروع کریں گے۔ ، کلید سبسکرپشن کا نام ہو گا، اور اقدار سیشن شناخت کنندگان ہوں گی (جس سے آپ پھر صارف کے شناخت کنندگان حاصل کر سکتے ہیں، اگر ضروری ہو)۔

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

چارٹس میں بہتری آئی ہے۔

ہم نے کیسے اور کیوں 1C کے لیے ایک ہائی-لوڈ اسکیل ایبل سروس لکھی: انٹرپرائز: Java، PostgreSQL، Hazelcast

ہم نے لوڈ ٹیسٹنگ کے بارے میں اور کیا سیکھا ہے؟

  1. JSR223 کو گرووی میں لکھنے کی ضرورت ہے اور اس میں تالیف کیش شامل ہے - یہ بہت تیز ہے۔ لنک.
  2. Jmeter-Plugins کے گراف کو معیاری گرافس کے مقابلے میں سمجھنا آسان ہے۔ لنک.

ہیزل کاسٹ کے ساتھ ہمارے تجربے کے بارے میں

ہیزل کاسٹ ہمارے لیے ایک نئی پروڈکٹ تھی، ہم نے ورژن 3.4.1 سے اس کے ساتھ کام کرنا شروع کیا، اب ہمارا پروڈکشن سرور ورژن 3.9.2 چلا رہا ہے (تحریر کے وقت ہیزل کاسٹ کا تازہ ترین ورژن 3.10 ہے)۔

شناختی نسل

ہم نے انٹیجر شناخت کنندگان کے ساتھ شروع کیا۔ آئیے تصور کریں کہ ہمیں ایک نئی ہستی کے لیے ایک اور لانگ کی ضرورت ہے۔ ڈیٹا بیس میں ترتیب مناسب نہیں ہے، میزیں شارڈنگ میں شامل ہیں - یہ پتہ چلتا ہے کہ DB1 میں ایک پیغام ID=1 ہے اور DB1 میں ایک پیغام ID=2 ہے، آپ اس ID کو Elasticsearch میں نہیں ڈال سکتے اور نہ ہی Hazelcast میں ، لیکن سب سے بری بات یہ ہے کہ اگر آپ دو ڈیٹا بیس کے ڈیٹا کو ایک میں جوڑنا چاہتے ہیں (مثال کے طور پر یہ فیصلہ کرنا کہ ان سبسکرائبرز کے لیے ایک ڈیٹا بیس کافی ہے)۔ آپ Hazelcast میں کئی AtomicLongs شامل کر سکتے ہیں اور کاؤنٹر کو وہاں رکھ سکتے ہیں، پھر ایک نئی ID حاصل کرنے کی کارکردگی incrementAndGet کے علاوہ Hazelcast کی درخواست کا وقت ہے۔ لیکن ہیزل کاسٹ میں کچھ زیادہ ہی بہترین ہے - FlakeIdGenerator۔ ہر کلائنٹ سے رابطہ کرتے وقت، انہیں ایک ID کی حد دی جاتی ہے، مثال کے طور پر، پہلا - 1 سے 10 تک، دوسرا - 000 سے 10 تک، وغیرہ۔ اب کلائنٹ اپنے طور پر نئے شناخت کنندگان کو جاری کر سکتا ہے جب تک کہ اسے جاری کردہ رینج ختم نہ ہو جائے۔ یہ تیزی سے کام کرتا ہے، لیکن جب آپ ایپلیکیشن (اور ہیزل کاسٹ کلائنٹ) کو دوبارہ شروع کرتے ہیں، تو ایک نیا سلسلہ شروع ہوتا ہے - اس لیے اسکپس، وغیرہ۔ مزید برآں، ڈویلپرز حقیقت میں یہ نہیں سمجھتے کہ IDs کیوں عددی ہیں، لیکن اتنی متضاد ہیں۔ ہم نے ہر چیز کا وزن کیا اور UUIDs میں تبدیل ہو گئے۔

ویسے، ان لوگوں کے لیے جو ٹوئٹر کی طرح بننا چاہتے ہیں، ایسی سنو کاسٹ لائبریری موجود ہے - یہ ہیزل کاسٹ کے اوپر سنو فلیک کا نفاذ ہے۔ آپ اسے یہاں دیکھ سکتے ہیں:

github.com/noctarius/snowcast
github.com/twitter/snowflake

لیکن ہم اب اس کے ارد گرد نہیں ملے ہیں.

TransactionalMap.replace

ایک اور حیرت: TransactionalMap.replace کام نہیں کرتا۔ یہاں ایک ٹیسٹ ہے:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

مجھے getForUpdate کا استعمال کرتے ہوئے اپنا متبادل لکھنا پڑا:

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

نہ صرف باقاعدہ ڈیٹا ڈھانچے بلکہ ان کے لین دین کے ورژن کی بھی جانچ کریں۔ ایسا ہوتا ہے کہ IMap کام کرتا ہے، لیکن TransactionalMap اب موجود نہیں ہے۔

ڈاؤن ٹائم کے بغیر نیا JAR داخل کریں۔

سب سے پہلے، ہم نے اپنی کلاسوں کی اشیاء کو ہیزل کاسٹ میں ریکارڈ کرنے کا فیصلہ کیا۔ مثال کے طور پر، ہمارے پاس ایپلی کیشن کلاس ہے، ہم اسے محفوظ کرنا اور پڑھنا چاہتے ہیں۔ محفوظ کریں:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

ہم پڑھتے ہیں:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

سب کچھ کام کر رہا ہے۔ پھر ہم نے تلاش کرنے کے لیے ہیزل کاسٹ میں ایک انڈیکس بنانے کا فیصلہ کیا:

map.addIndex("subscriberId", false);

اور ایک نئی ہستی لکھتے وقت، انہیں ClassNotFoundException موصول ہونا شروع ہوا۔ ہیزل کاسٹ نے انڈیکس میں اضافہ کرنے کی کوشش کی، لیکن وہ ہماری کلاس کے بارے میں کچھ نہیں جانتا تھا اور چاہتا تھا کہ اس کلاس کے ساتھ ایک JAR اسے فراہم کیا جائے۔ ہم نے ایسا ہی کیا، سب کچھ کام ہوا، لیکن ایک نیا مسئلہ سامنے آیا: کلسٹر کو مکمل طور پر روکے بغیر JAR کو کیسے اپ ڈیٹ کیا جائے؟ ہیزل کاسٹ نوڈ بائی نوڈ اپ ڈیٹ کے دوران نیا JAR نہیں اٹھاتا ہے۔ اس موقع پر ہم نے فیصلہ کیا کہ ہم انڈیکس تلاش کیے بغیر رہ سکتے ہیں۔ سب کے بعد، اگر آپ Hazelcast کو کلیدی قدر کی دکان کے طور پر استعمال کرتے ہیں، تو سب کچھ کام کرے گا؟ واقعی نہیں۔ یہاں ایک بار پھر IMap اور TransactionalMap کا رویہ مختلف ہے۔ جہاں IMap کو پرواہ نہیں ہے، TransactionalMap ایک غلطی پھینک دیتا ہے۔

IMap ہم 5000 اشیاء لکھتے ہیں، انہیں پڑھتے ہیں۔ سب کچھ متوقع ہے۔

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

لیکن یہ کسی لین دین میں کام نہیں کرتا، ہمیں ClassNotFoundException ملتا ہے:

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

3.8 میں، یوزر کلاس کی تعیناتی کا طریقہ کار ظاہر ہوا۔ آپ ایک ماسٹر نوڈ نامزد کر سکتے ہیں اور اس پر JAR فائل کو اپ ڈیٹ کر سکتے ہیں۔

اب ہم نے اپنا نقطہ نظر مکمل طور پر بدل دیا ہے: ہم اسے خود JSON میں سیریلائز کرتے ہیں اور اسے Hazelcast میں محفوظ کرتے ہیں۔ ہیزل کاسٹ کو ہماری کلاسوں کی ساخت جاننے کی ضرورت نہیں ہے، اور ہم بغیر وقت کے اپ ڈیٹ کر سکتے ہیں۔ ڈومین آبجیکٹ کی ورژننگ کو ایپلی کیشن کے ذریعے کنٹرول کیا جاتا ہے۔ ایپلی کیشن کے مختلف ورژن ایک ہی وقت میں چل سکتے ہیں، اور ایسی صورت حال ممکن ہے جب نئی ایپلی کیشن نئی فیلڈز کے ساتھ اشیاء لکھتی ہے، لیکن پرانی کو ان فیلڈز کے بارے میں ابھی تک علم نہیں ہے۔ اور ایک ہی وقت میں، نئی ایپلی کیشن پرانی ایپلی کیشن کے ذریعہ لکھی گئی اشیاء کو پڑھتی ہے جن میں نئے فیلڈ نہیں ہوتے ہیں۔ ہم اس طرح کے حالات کو ایپلی کیشن کے اندر ہینڈل کرتے ہیں، لیکن سادگی کے لیے ہم فیلڈز کو تبدیل یا ڈیلیٹ نہیں کرتے، ہم صرف نئے فیلڈز شامل کرکے کلاسز کو بڑھاتے ہیں۔

ہم کس طرح اعلی کارکردگی کو یقینی بناتے ہیں۔

ہیزل کاسٹ کے چار دورے - اچھے، دو ڈیٹا بیس کے لیے - خراب

ڈیٹا کے لیے کیشے میں جانا ہمیشہ ڈیٹا بیس میں جانے سے بہتر ہوتا ہے، لیکن آپ غیر استعمال شدہ ریکارڈز کو بھی اسٹور نہیں کرنا چاہتے۔ ہم ترقی کے آخری مرحلے تک اس بات کا فیصلہ چھوڑ دیتے ہیں کہ کیا کیش کرنا ہے۔ جب نئی فعالیت کو کوڈ کیا جاتا ہے، تو ہم PostgreSQL (log_min_duration_statement to 0) میں تمام سوالات کی لاگنگ آن کر دیتے ہیں اور 20 منٹ تک لوڈ ٹیسٹنگ چلاتے ہیں۔ جمع شدہ لاگز کا استعمال کرتے ہوئے، pgFouine اور pgBadger جیسی افادیتیں تجزیاتی رپورٹیں بنا سکتی ہیں۔ رپورٹس میں، ہم بنیادی طور پر سست اور متواتر سوالات تلاش کرتے ہیں۔ سست سوالات کے لیے، ہم ایک ایگزیکیوشن پلان بناتے ہیں (EXPLAIN) اور اس بات کا جائزہ لیتے ہیں کہ آیا اس طرح کے استفسار کو تیز کیا جا سکتا ہے۔ ایک ہی ان پٹ ڈیٹا کی بار بار کی درخواستیں کیشے میں اچھی طرح سے فٹ ہوجاتی ہیں۔ ہم سوالات کو "فلیٹ" رکھنے کی کوشش کرتے ہیں، فی سوال ایک میز۔

استحصال

ایک آن لائن سروس کے طور پر SV کو 2017 کے موسم بہار میں عمل میں لایا گیا تھا، اور ایک علیحدہ پروڈکٹ کے طور پر، SV کو نومبر 2017 میں جاری کیا گیا تھا (اس وقت بیٹا ورژن کی حیثیت میں تھا)۔

آپریشن کے ایک سال سے زیادہ عرصے میں، سی بی آن لائن سروس کے آپریشن میں کوئی سنگین مسئلہ نہیں ہے۔ ہم آن لائن سروس کے ذریعے نگرانی کرتے ہیں۔ زبیبس، سے جمع اور تعینات کریں۔ بانس.

SV سرور کی تقسیم مقامی پیکجوں کی شکل میں فراہم کی جاتی ہے: RPM, DEB, MSI۔ پلس ونڈوز کے لیے ہم ایک واحد EXE کی شکل میں ایک انسٹالر فراہم کرتے ہیں جو سرور، ہیزل کاسٹ اور ایلسٹک سرچ کو ایک مشین پر انسٹال کرتا ہے۔ ہم نے ابتدائی طور پر انسٹالیشن کے اس ورژن کو "ڈیمو" ورژن کہا تھا، لیکن اب یہ واضح ہو گیا ہے کہ یہ سب سے زیادہ مقبول تعیناتی کا آپشن ہے۔

ماخذ: www.habr.com

نیا تبصرہ شامل کریں