مرحباً @Juergen_Geiser أهلاً وسهلاً!
في تنفيذ واحد، يقوم n8n بتشغيل عقدة واحدة في كل مرة، لذا فإن عقدتي HTTP Request على فروع منفصلة تعملان دائماً الواحدة تلو الأخرى، وإعداد ترتيب التنفيذ يغير فقط الفرع الذي يذهب أولاً. عقدة HTTP Request واحدة تحتوي على عنصرين ترسل كلا الاستدعاءات مرة واحدة.
لذا قم ببناء عنصرين بدلاً من فرعين، واحد لكل webhook:
const q = $input.first().json;
return [
{ json: { ...q, url: 'https://<your-instance>/webhook/pro' } },
{ json: { ...q, url: 'https://<your-instance>/webhook/contra' } }
];
ثم أشر عقدة HTTP Request واحدة إلى {{ $json.url }} واترك Batching مطفأً. تعود كلا الإجابتين كعنصرين بنفس الترتيب، لذا تختفي عقدة Merge وتغذي هذه العقدة “Prepare Summary” مباشرة.
انظر إلى هذا:
السلام عليكم @Juergen_Geiser
هذا ليس خللاً. داخل تنفيذ واحد، يقوم n8n بتشغيل الفروع بالترتيب بدلاً من إطلاقها في نفس اللحظة. مع executionOrder: v1، يتم تشغيل الفرع الموضوع في الأعلى على لوحة الرسم أولاً، لذلك لن يغيّر ترتيب الاتصالات ذلك.
إذا كان سير العمل الثالث يستدعي webhook احترافي باستخدام عقدة HTTP Request، فإن تلك العقدة تنتظر الاستجابة قبل أن يبدأ n8n فرع contra. سأجعل كلا webhook الفرعيين يقرّان فوراً، ثم يستمران في عملهما الفعلي بعد الاستجابة. هذا يسمح للأب بتفعيل webhook الثاني بسرعة بينما لا يزال سير العمل الفرعي الأول قيد المعالجة.
أستخدم نفس النمط لاستدعاءات الأدوات المباشرة لأن الانتظار للتسجيل أو الإشعارات تسبب انتهاء انتظار المتصل حتى وإن اكتملت العملية لاحقاً.
آمل أن يكون مفيداً!
عادةً ما يسبب هذا شيئان:
من الجدير بالملاحظة أيضاً: سجل التنفيذ في n8n يعرض العقد بالترتيب الذي تم إرسالها فيه، وليس بالضرورة الترتيب الذي انتهت فيه — لذلك قد تكون الفروع التي تبدو متسلسلة في السجل تعمل في الواقع بالتوازي تحت الغطاء إذا كانت مكالمات HTTP خالصة. تحقق من الطوابع الزمنية الفعلية والمدة على كل عقدة للتأكد مما إذا كانت متسلسلة حقاً أم مجرد عرض بهذه الطريقة.
إذا ظلت متسلسلة بعد التحقق من التوصيل، هل يمكنك مشاركة كيف تتصل عقدة المشغل بكلا استدعاءات webhook؟ سيسهل ذلك تحديد الاختناق.
شيء إضافي واحد أود اختباره هو التوقيت خارج عرض لوحة الرسم.
يمكن لمخطط التنفيذ أن يجعل العمل الذي يبدو متوازيًا يشعر بأنه متسلسل لأنه لا يزال يسجل العقد بترتيب مرئي. أضف طابع زمني قبل كل استدعاء webhook وكل مخطط عمل فرعي يسجل متى يبدأ وينتهي. سيخبرك ذلك ما إذا كانت الاستدعاءات تتداخل فعلاً أم أن الأب ينتظر الرد الأول قبل بدء الثاني.
إذا كنت بحاجة إلى سلوك حقيقي “أطلق واستعد”, فسأحافظ على مخطط العمل الأصلي صغيرًا: حضّر الحمولات، وشغّل مخططات العمل الفرعية، واترك كل عملية فرعية تتعامل مع عملها طويل الأجل وتحديثات الحالة الخاصة بها.
شكراً جزيلاً Anshul، لقد ساعد ذلك وحصلت الآن على:
بعد ذلك لدي في الكود:
const question = $(‘When chat message received’).first().json.chatInput;
return [
{
json: {
question,
type: ‘pro’,
url: ‘https://appwbs.app.n8n.cloud/webhook-test/parallel-pro-agent’
}
},
{
json: {
question,
type: ‘contra’,
url: ‘https://appwbs.app.n8n.cloud/webhook-test/parallel-contra-agent’
}
}
];
بصراحة، لا أرى ميزة حتى الآن، فهو يستغرق وقتاً تقريباً كما في التنفيذ المتسلسل، هل لديك نصيحة أخرى هنا؟
شكراً Juergen
شكراً جزيلاً على الأفكار،
لقد تعاملت الآن مع المعالجة المتوازية باستخدام Javascript:
حيث حصلت أيضاً على الكود:
لا أرى حتى الآن أي تحسن حقيقي، فهو سريع تقريباً بنفس سرعة المعالجة المتسلسلة. لذلك لا توجد في الواقع “عقدة متوازية في n8n”، بمعنى آخر يجب أن أبرمجها بنفسي وأتحكم بها. هل لديكم نصائح أخرى؟ أحتاجها الآن لندوة تدريبية عن المعالجة المتوازية لوكلاء الذكاء الاصطناعي والمشاركين لدي، وأشكركم مسبقاً. مع أطيب التحيات Juergen
يمكنك نقل عقد HTTP إلى سير العمل الفرعي وتعطيل خيار “الانتظار حتى اكتمال سير العمل الفرعي”. بهذه الطريقة، ستكون هناك تنفيذتان، واحدة تلو الأخرى، وكلاهما سيعمل بشكل مستقل. بعد ذلك، ستحتاج إلى التعامل مع البيانات المُرجعة، حيث لن تُرجع عقدة Execute Workflow أي شيء. للقيام بذلك، أسهل إعداد هو استخدام جدول بيانات لتخزين مخرجات كلا التنفيذين.
في العقدة الرئيسية، تحقق من عقدة Wait متى ستكون كلا المخرجات موجودة
عناوين URL في عقدة Code هذه هي عناوين الاختبار، /webhook-test/، والتي تعمل فقط أثناء جلوس كل سير عمل فرعي في “Listen for test event” وتتوقف عن الاستماع بعد 120 ثانية. انشر كلا الطفلين وقيسها مقابل عناوين URL الإنتاج /webhook/ بدلاً من ذلك.
الباقي هو الحسابات. التكاليف المتسلسلة هي إيجابيات زائد سلبيات زائد وكيل الملخص، والتكاليف المتوازية هي أبطأ من الإيجابيات والسلبيات زائد وكيل الملخص، لذا فإن التوفير هو تشغيل وكيل واحد. في ثلاث خطوات LLM مماثلة، هذا يقل تقريباً بمقدار الثلث وليس النصف، وفي عرض توضيحي يبدو درامياً فقط إذا كان وكيلا الطفل هو الجزء البطيء والخطوة الملخصة تافهة.
