Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Direct Line API fungerar som ett kommunikationsgränssnitt för klientappar för att interagera med konversationsagenter skapade i Copilot Studio. Direct Line API möjliggör överföring av meddelanden mellan klientappen och agenten via antingen WebSocket-strömmar eller HTTP-förfrågningar. För prestandatestning möjliggör Direct Line för belastningstestverktyg att simulera verkligt användarbeteende, skapa belastning och mäta svarstider.
Kommunicera med Direct Line via WebSockets
Du kan distribuera konversationsagenter som skapats med Copilot Studio till webbprogram som antingen inbäddade iframes eller genom att använda en anpassad arbetsyta. Båda distributionsalternativen använder WebSocket-kommunikation med Direct Line. Om du distribuerar din konversationsagent till en app med någon av dessa metoder bör ditt prestandatestskript använda WebSocket-kommunikation för att generera belastning som liknar verkligt användarbeteende och mäta prestanda med hög grad av tillförsikt.
Klientappar som använder Direct Line och WebSocket-kommunikation bör följa detta flöde:
- För att initiera en konversation måste en klientapp först hämta en konversationstoken. Om din agent har konfigurerats med en Direct Line-hemligheter ska du hämta en token genom att anropa Regional slutpunkt för Direct Line. Token för agenter som inte använder hemligheter kan erhållas från tokenslutpunkten.
- Klientappen startar en konversation genom att använda tokenen och får ett konversations-ID och en WebSocket-ström-URL.
- Användarmeddelanden skickas genom att skicka en HTTP POST-förfrågan med konversations-ID:t.
- Meddelanden från konversationsagenten tas emot via WebSocket-strömmen.
Kommunicera med Direct Line genom HTTP GET
Om ditt belastningstestverktyg inte kan använda WebSocket-kommunikation, eller om din klientapp inte använder WebSocket-kommunikation, kan du ta emot aktiviteter genom att skicka HTTP GET istället. Som visas i diagrammet nedan förändras inte samtalsinitieringsflödet.
Mät svarstider
För att bedöma hur belastningen påverkar användarupplevelsen, se till att dina prestandatestskript spårar och rapporterar svarstid för följande steg:
| Steg | Påverkan på användarupplevelse |
|---|---|
| Generera token | Tiden det tar att starta en ny konversation |
| Starta en konversation | Tiden det tar att starta en ny konversation |
| Skicka aktivitet | Tiden det tar att skicka ett nytt användarmeddelande (inkluderar inte agentens svar) |
| Ta emot aktiviteter/Hämta aktiviteter | Tiden det tar för en agent att svara |
Att spåra svarstider för Generera token, Starta konversation och Skicka aktiviteten är okomplicerat för lasttestningsverktyg, eftersom dessa steg använder standard HTTP-förfrågningar. Att mäta tiden det tar för en agent att svara på användarmeddelanden är dock mer komplext, av följande skäl:
Sändning och mottagande av aktiviteter över Direct Line följer ett asynkront mönster. När ett användarmeddelande skickas med en Skicka aktivitet-begäran är svaret inte ett meddelande från agenten. Istället bekräftar den endast att användarens meddelande har postats framgångsrikt.
Baserat på dess design kan en konversationsagent skicka ett godtyckligt antal meddelanden tillbaka som svar på ett användarmeddelande. Därför bör du i de flesta fall mäta agentens svarstid som tiden som går mellan ett användarmeddelande och det sista agentmeddelandet. I följande exempel triggar ett enskilt användarmeddelande tre agentmeddelanden, med API-anrop som körs däremellan. Varje meddelande tar ungefär två sekunder att levereras; men ur användarens perspektiv tar det agenten sex sekunder att svara på användarens begäran.
Identifiera agentens sista svar
För att mäta hur lång tid det tar för en agent att ge sina svar behöver ditt prestandatestningsskript:
- Identifiera det sista agentmeddelandet som följer efter ett användarmeddelande
- Beräkna tidsskillnaden mellan de två
Det underliggande protokollet som Copilot Studio använder har inget begrepp om ett 'sista svar', eftersom både agenter och användare kan skicka meddelanden när som helst. Därför måste ditt prestandatestningsskript anta att om agenten inte skickar ett meddelande inom en given tidsram, skickas inga fler meddelanden förrän nästa användarmeddelande skickas. Implementeringen av denna logik varierar beroende på hur ditt skript kommunicerar med Direct Line.
Använd WebSocket
Vid kommunikation med Direct Line över WebSockets, anta att agenten inte skickar fler meddelanden när det inte går att läsa fler ramar från WebSocket. Du kan se detta indikeras av en tidsgräns när du försöker läsa nästa ram, även om det exakta beteendet beror på din implementering. För en referensimplementation som använder WebSockets kan du överväga att använda HTTP GET.
Använda HTTP GET
Prestandatestskript som använder HTTP GET istället för WebSockets bör polla Activities-endpointen för att få hela uppsättningen användar- och agentmeddelanden. När du pollar, se till att ge din agent tillräckligt med tid att svara. Till exempel, om din agent behöver anropa ett backend-API för att svara på en användarfråga, och API:et tar upp till fem sekunder att svara, ska ditt script inte polla Activities-endpointen förrän fem sekunder har gått.
Följande förenklade nyttolast representerar svaret som kommer tillbaka från slutpunkten Aktiviteter.
[
{
"type": "message",
"id": "98SryQaHr2rGthOGpChPK2-us|0000012",
"timestamp": "2025-01-07T09:12:22.0329242Z",
"from": {
"id": "a688eb7d-092a-42a8-8ef5-73123b9c2aaa",
"name": ""
},
"conversation": {
"id": "98SryQaHr2rGthOGpChPK2-us"
},
"text": "I also want to set up a new account",
},
{
"type": "message",
"id": "98SryQaHr2rGthOGpChPK2-us|0000017",
"timestamp": "2025-01-07T09:12:24.5478686Z",
"from": {
"id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
"name": "Load Testing",
"role": "bot"
},
"conversation": {
"id": "98SryQaHr2rGthOGpChPK2-us"
},
"text": "Sure, please bear with me as I set up your new account",
"replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
},
{
"type": "message",
"id": "98SryQaHr2rGthOGpChPK2-us|0000018",
"timestamp": "2025-01-07T09:12:33.1960413Z",
"from": {
"id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
"name": "Load Testing",
"role": "bot"
},
"conversation": {
"id": "98SryQaHr2rGthOGpChPK2-us"
},
"text": "Almost done! Thank you for your patience",
"replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012",
},
{
"type": "message",
"id": "98SryQaHr2rGthOGpChPK2-us|0000019",
"timestamp": "2025-01-07T09:12:41.9166159Z",
"from": {
"id": "4b56bfa5-5574-5bb3-7aa3-99b8798b9d90",
"name": "Load Testing",
"role": "bot"
},
"conversation": {
"id": "98SryQaHr2rGthOGpChPK2-us"
},
"text": "All done! Your new account is now active.",
"inputHint": "acceptingInput",
"replyToId": "98SryQaHr2rGthOGpChPK2-us|0000012"
}
]
När du tolkar nyttolasten och beräknar svarstider, överväg följande riktlinjer:
- Meddelanden från agenten har egenskapen
role: bot, medan meddelanden från användaren saknar egenskapenrole. - Agentmeddelanden som skickas som svar på användarmeddelanden har egenskapen
replyToId, som har värdet av egenskapenidför användarmeddelandet. - Du kan beräkna agentens svarstider genom att ta tidsskillnaden mellan användarmeddelandet och det sista agentmeddelandet som svarar på det.