Jak można zmierzyć wygaśnięcie zlecenia oczekującego?

Bezpośrednia odpowiedź

Wygaśnięcie zlecenia oczekującego można zmierzyć, rejestrując (1) znacznik czasu utworzenia zlecenia, (2) znacznik czasu, kiedy zlecenie staje się uprawnione do realizacji, (3) skonfigurowaną regułę wygaśnięcia i jej czas docelowy oraz (4) znacznik czasu (i status), kiedy platforma oznacza zlecenie jako wygasłe lub anulowane. Aby mierzyć to dokładnie, zdefiniuj, co uznasz za czas startu, co uznasz za czas wygaśnięcia oraz jak obsłużysz przypadki niejednoznaczne, takie jak „zrealizowane w okolicach wygaśnięcia” lub „wygasłe po ponownym połączeniu”.

Mechanizm i definicja

„Zlecenie oczekujące” to zlecenie, które nie jest realizowane natychmiast; czeka, aż warunki rynkowe będą zgodne z jego wyzwalaczem (na przykład, gdy cena osiągnie określony poziom). „Wygaśnięcie” to reguła zakończenia, która zatrzymuje zlecenie oczekujące przed pozostawaniem aktywnym po ustalonym punkcie w czasie.

Aby mierzyć wygaśnięcie zlecenia oczekującego, używaj mierzalnych pól zamiast nieformalnych sformułowań. Typowe pola, na których możesz oprzeć obliczenia, to:

1. Znacznik czasu startu: moment, w którym uznajesz, że rozpoczyna się odliczanie. Często jest to czas utworzenia zlecenia, ale niektóre systemy rozdzielają „utworzone”, „zaakceptowane” i „stało się aktywne”.

2. Konfiguracja wygaśnięcia: reguła określająca, kiedy zlecenie ma przestać być aktywne (na przykład, stały czas zakończenia albo czas trwania od momentu złożenia). Konfiguracja jest potrzebna, ponieważ dwa zlecenia mogą oba „wygasnąć”, ale w różnych momentach.

3. Docelowy znacznik czasu wygaśnięcia: wyliczony czas końcowy wynikający z konfiguracji (na przykład, czas złożenia + czas trwania albo wskazany czas zegarowy). To planowana wartość, którą możesz obliczyć.

4. Zaobserwowany rezultat: znacznik czasu i status raportowane przez platformę, wskazujące, co faktycznie się wydarzyło (na przykład, status staje się „wygasło”, „anulowane” lub „zrealizowane”). To zmierzona wartość.

Praktyczny pomiar to różnica między zaobserwowanym znacznikiem czasu dla statusu końcowego a docelowym znacznikiem czasu wygaśnięcia albo różnica między zaobserwowanym znacznikiem czasu końcowego a znacznikiem czasu startu. Użyj tej samej podstawy czasu dla obu wartości.

Dowód lub przykład

Przykładowe podejście pomiarowe (podane założenia):

• Zakładaj, że wszystkie znaczniki czasu są raportowane w tej samej strefie czasowej, albo że konwertujesz je konsekwentnie do jednej strefy czasowej.
• Zakładaj, że platforma udostępnia wpis historii zleceń zawierający znacznik czasu statusu „expired”.

Kroki do pomiaru:

1. Zarejestruj znacznik czasu utworzenia zlecenia (start). Nazwij go T_start.

2. Zarejestruj konfigurację wygaśnięcia i wyprowadź docelowy znacznik czasu wygaśnięcia. Nazwij go T_target.

3. Zlokalizuj zdarzenie końcowe odpowiadające wygaśnięciu. Nazwij znacznik czasu platformy T_observed i zapisz status końcowy.

4. Oblicz dwie wartości:

• Planowany czas trwania: Δ_planned = T_target − T_start
• Rzeczywiste opóźnienie wygaśnięcia: Δ_delay = T_observed − T_target

Interpretacja:

• Jeśli Δ_delay jest bliskie zeru, platforma oznaczyła zlecenie jako wygasłe w pobliżu zamierzonego czasu.
• Jeśli Δ_delay jest konsekwentnie dodatnie, twój system może rejestrować wygaśnięcie po pewnym opóźnieniu przetwarzania, opóźnieniu ponownego połączenia lub aktualizacji na koniec cyklu.
• Jeśli status końcowy nie jest „expired” (na przykład „filled”), to wygaśnięcie nie było rezultatem końcowym dla tego konkretnego zlecenia; pomiar nadal jest poprawny, ponieważ odpowiada na inne pytanie: „Jaki status końcowy wystąpił i o jakim czasie?”

To podejście pomaga ci zweryfikować „wygaśnięcie” jako właściwość cyklu życia zlecenia w twoim systemie, a nie jako domysł oparty na zewnętrznych notowaniach.

Ograniczenia i ryzyka (istotne tryby awarii)

Istnieje kilka ograniczeń wpływających na pomiar:

1. Niezgodność zegara i strefy czasowej Jeśli T_start, T_target i T_observed pochodzą z różnych źródeł lub stref czasowych, Δ_planned i Δ_delay mogą wprowadzać w błąd nawet wtedy, gdy platforma działa poprawnie.

2. Niejednoznaczne stany końcowe W okolicach momentu wygaśnięcia zlecenie może się zrealizować, zrealizować częściowo albo zostać oznaczone jako wygasłe po decyzjach dotyczących realizacji. Twój pomiar zależy od definicji platformy dotyczących przejść statusów i tego, jak je znaczkuje czasem.

3. Czasowanie danych i łączność Nawet bez zakładania danych rynkowych w czasie rzeczywistym, możesz nadal obserwować pozorne „odchylenie wygaśnięcia” spowodowane opóźnionymi aktualizacjami statusu, czasem odświeżania aplikacji lub kolejnością wpisów w logach audytu.

4. Zmienne warunki rynkowe Warunki wyzwalania zlecenia oraz czas, w którym zostałoby zrealizowane (gdyby nadal było aktywne), mogą zmieniać się szybko. Zależności historyczne nie gwarantują, że przyszłe zlecenia będą zachowywać się podobnie.

5. Reguły cyklu życia specyficzne dla dostawcy lub jurysdykcji Różne miejsca realizacji, infrastruktura i reguły operacyjne mogą wpływać na to, co operacyjnie oznacza „expired” (na przykład, kiedy platforma przestaje kierować zlecenie). Twój pomiar może więc odzwierciedlać politykę platformy, a nie uniwersalną regułę.