Retrolyzer + BQL

[adamshalev]

לא רלוונטי במקרה דנן: אדם פתח שרשור על תיק חדש, והוא יודע שתבוא מתקפת קוראים על השרת שתמשך לפחות כמה ימים. אם הוא לא יבצע משהו כזה, אף אחד לא יראה שום דבר גם משאילתן טריוויאליות. מצד שני, תוספת נתונים משבוע נוסף לא תשפיע על בחינת התיק בטווח של יותר מעשור.

זה באמת use case נפרד מה-use case הרגיל שהוא אתה רוצה להעיף מבט על ני"ע או שניים ואז למידע עדכני יש חשיבות גדולה בהרבה.
כיוון שהשרת מחזיר json לדפדפן והדף עצמו אחרי על הרנדור, אני נוטה לכיוון של לשמור את ה-json על השרת כפונק' של השאילתה, אבל להציג בבירור שמדובר במידע לא עדכני ולאפשר להריץ את העדכני. בין אם זה יהיה באותו endpoint או אחד נפרד זה פרט מימושי קטן.

 

[Benjamin W]

@TunaGolem

אם אני מבין אותך, אתה מדבר על פתרון אירעי ידני. אני מדבר על פתרון דומה אך קבוע. כלומר, להחליט שאת התשובות לכל השאילתות שומרים בצד. וכשחוזרת שאילתה זהה פשוט מחזירים את התשובה שכבר ניתנה. Reverse proxy זה תוכנה שעושה בדיוק את זה.

מה שאתה מציע טיפה בעייתי כי אני מניח שהדף מופרד ל html של תצוגה, ולנתונים שמגיעים בצורה אחרת, מה שטיפה טרחה לסדר...

 

[TunaGolem]

אם אני מבין אותך, אתה מדבר על פתרון אירעי ידני.

נכון. דברתי על פתרון נקודתי לבעיה חוזרת, מכיוון שאתה טענת שפתרונות מטמון כלליים הינם מורכבים.

אני מדבר על פתרון דומה אך קבוע. כלומר, להחליט שאת התשובות לכל השאילתות שומרים בצד. וכשחוזרת שאילתה זהה פשוט מחזירים את התשובה שכבר ניתנה.

אבל אין סיבה לעשות זאת לכל שאילתא. כפי שאדם ציין:

זה באמת use case נפרד מה-use case הרגיל שהוא אתה רוצה להעיף מבט על ני"ע או שניים

מה שאתה מציע טיפה בעייתי כי אני מניח שהדף מופרד ל html של תצוגה, ולנתונים שמגיעים בצורה אחרת, מה שטיפה טרחה לסדר...

זו הנקודה שבה אני מתקשה להבין את הקושי: האם אי אפשר להחזיק את מסד הנתונים המינימלי בתוך הHTML, כך שיהיו דפים עם תצוגה קבועה שבכלל לא דורשת שאילתא?

אני נוטה לכיוון של לשמור את ה-json על השרת כפונק' של השאילתה

אם הפתרון הזה פותר את הבעיות, מה טוב. עדיין אשמח להסבר מדוע הפתרון שאני הצגתי, מסובך.

 

[מתכנת]

זה באמת use case נפרד מה-use case הרגיל שהוא אתה רוצה להעיף מבט על ני"ע או שניים ואז למידע עדכני יש חשיבות גדולה בהרבה.
כיוון שהשרת מחזיר json לדפדפן והדף עצמו אחרי על הרנדור, אני נוטה לכיוון של לשמור את ה-json על השרת כפונק' של השאילתה, אבל להציג בבירור שמדובר במידע לא עדכני ולאפשר להריץ את העדכני. בין אם זה יהיה באותו endpoint או אחד נפרד זה פרט מימושי קטן.

אניח את שני הסנט שלי,
אתה הרי כבר משתמש ב- key-value-db בשביל לשמור tiny-link.
תוכל לפתוח עוד DB (או רשימה או טופיק, לא מכיר את הטרמינולוגיה) ה-key יהיה ה- tiny-link, ה- value יהיה תוצאת ה-JSON של השאילתה + חתימת זמן.
תוכל להגדיר שאחת לשבוע/יום/whatever תתבצע הרצה חדשה בכל מקרה.
tiny-link תמיד יחזיר תוצאה ממטמון כל עוד לא פג הזמן שהוגדר (וציון אינדיקציה על כך כפי שאמרת), משתמש שעורך את השאילתה גם כך כבר לא משתמש ב-tiny-link ויקבל נתונים עדכניים.
כאשר תבצע שינוי במבנה ה-JSON, כזה שלא יאפשר יותר רנדור התוצאות הישנות על ה-UI החדש תוכל לרוקן את המטמון בצורה יזומה.
כל זה יכול להתרחש באותו endpoint מאחורי הקלעים ושקוף כלפי הדפדפן.
המטרה של @TunaGolem תושג.

אם הפתרון הזה פותר את הבעיות, מה טוב. עדיין אשמח להסבר מדוע הפתרון שאני הצגתי, מסובך.

כיום הרינדור הוא בדפדפן, מה שאתה מציע דורש (1) לרנדר בשרת (2) לשמור דפי HTML סטטיים שיהיו נגישים לדפדפן (3) אחר כך לדאוג שהזבל שיצטבר ינוקה מתישהו וכו'

 

[Benjamin W]

@מתכנת
מה שאתה מציע, זה לממש מחדש, ובצורה ספציפית לאתר, reverse proxy. בטח אם אתה מתבסס על ה URL...
הרבה יותר פשוט, להרים את השירות עצמו ולקנפג אותו 5 דקות. או אם אנחנו רוצים להיות חכמולוגים, לאמץ איזה פתרון output cache ממה שקיים כבר בעולם.

זו הנקודה שבה אני מתקשה להבין את הקושי: האם אי אפשר להחזיק את מסד הנתונים המינימלי בתוך הHTML, כך שיהיו דפים עם תצוגה קבועה שבכלל לא דורשת שאילתא?

אפשר. אבל זה לא מה שקורה באתר כרגע...

לא יודע איך אדם. אני עצלן מידי בשביל לפתור בעיות נקודתיות.

@adamshalev
אגב, תגיד, באז'ור אין איזה שרות קש סופר קסום ומבוזר?

 

[adamshalev]

אגב, תגיד, באז'ור אין איזה שרות קש סופר קסום ומבוזר?

אולי, אבל אני לא מתלהב מלהאציל בעיה קשה להגדרה על שירות קסום ומבוזר. לא כל בקשה לשרת צריכה לעבור דרך קאש.

 

[מתכנת]

מה שאתה מציע, זה לממש מחדש, ובצורה ספציפית לאתר, reverse proxy. בטח אם אתה מתבסס על ה URL...

לא בדיוק.
כיום יש tiny-link שמחזיק את השאילתה עצמה ב- key-value-db מה שאני מציע זה באותו קטע קוד, במקום לקחת את השאילתה ולהעביר אותה למנוע ההרצה, לבדוק ב-DB של המטמון האם קיימת כבר תוצאה.
reverse proxy בדרך כלל זה להפנות לשרתים שונים על פי הנתיב, ההצעה שלי מתייחסת לשמור את תוצאות ההרצה והמפתח יהיה הערך שמתקבל ב-QUERY

לא כל בקשה לשרת צריכה לעבור דרך קאש.

לא יודע את התכוונת לענות גם לי.
בכל אופן כבר כיום בכל בקשה מלינק הקצר אתה פונה לקאש לאחזר את השאילתה.

 

[adamshalev]

לא יודע את התכוונת לענות גם לי.
בכל אופן כבר כיום בכל בקשה מלינק הקצר אתה פונה לקאש לאחזר את השאילתה.

נכון, כוונתי שבקשה זו למשל לא צריכה לעבור דרך הקאש של azure (בהנחה שיש כזה). לכן גם פתרונות קסם מצריכים לקרוא מדריכים על איך הקסם עובד ולהכנס לפרטי המימוש שלו.
מעדיף לממש את הקאש נקודתית במקום שבו הוא נדרש (על הבקשה/החזרה של ה json).

 

[מתכנת]

לא רעיון כל כך טוב, זה רק מעביד את השרת עוד יותר. עשיתי לו ריסט לפני כשעה כי הוא טחן דברים נון סטופ. הוא באמת לא בנוי כרגע ל-heavy lifting (את זה אני עושה מקומית). מקווה לשפר את זה.

חשבת להעביר את עיבוד השאילתות ל- Queue ?
כלומר יהיה תהליך אחד (או n) שיקבל את הבקשות מהתור, יעבד ויחזיר את הפלט לתור תגובות, ה request ימתין בינתיים (long pooling), בשגרה כלל לא יורגש, אמנם בזמני עומס יהיה דיליי אבל ימנע את קריסת השרת וצרות נוספות. (כמובן שאם יש timeout של azure זה בעיה שתיפתר רק על ידי async מול הדפדפן)
בתצורה זו ייתכן מצב קצה של שאילתה אינסופית במקרי תקלה וכד', כדי למנוע זאת אפשר להגדיל 2 תורים ובנוסף לנטר בקשות שעיבוד שלהם נמשך יותר מ-X זמן.

אתה הרי כבר משתמש ב- key-value-db בשביל לשמור tiny-link.
תוכל לפתוח עוד DB (או רשימה או טופיק, לא מכיר את הטרמינולוגיה) ה-key יהיה ה- tiny-link, ה- value יהיה תוצאת ה-JSON של השאילתה + חתימת זמן.
תוכל להגדיר שאחת לשבוע/יום/whatever תתבצע הרצה חדשה בכל מקרה.
tiny-link תמיד יחזיר תוצאה ממטמון כל עוד לא פג הזמן שהוגדר (וציון אינדיקציה על כך כפי שאמרת), משתמש שעורך את השאילתה גם כך כבר לא משתמש ב-tiny-link ויקבל נתונים עדכניים.
כאשר תבצע שינוי במבנה ה-JSON, כזה שלא יאפשר יותר רנדור התוצאות הישנות על ה-UI החדש תוכל לרוקן את המטמון בצורה יזומה.
כל זה יכול להתרחש באותו endpoint מאחורי הקלעים ושקוף כלפי הדפדפן.

עוד משהו בנוסף לכל האמור, אתה יכול להוסיף תיבת סימון ליד הלחצן GO שתציין האם להביא נתונים חדשים או מהמטמון (הנ"ל), וזה יהיה פרמטר נוסף ל-endpoint ב-azure, כברירת מחדל יהיה מסומן להביא ממטמון מי שירצה יוכל לבקש נתונים עדכניים, המטמון יכול להיות של שבוע~ שזה מספיק טוב והפתרון הזה יכול לחסוך לשרת ים עבודה.

 

[adamshalev]

כמה עדכונים:
- מסתבר שיאהו שברו את ה-API שלהם למשיכת נתונים, משהו שאינספור אנשי פיננס הסתמכו עליו. אם זה לא מספיק שהם סגרו את ה-API ההיסטורי שלהם, והפכו אותו למורכב הרבה יותר לגישה עם session/crumb validation, הם גם שינו את סדר העמודות, הפכו את סדר השורות ושברו את מבנה ה-data adjustment כך שהוא לא dividend adjusted יותר, אלא רק split adjusted. למזלי, כל הבעיות הללו היו פתירות וכעת השליפה של נתוני ני"ע זרים צריך לעבוד תקין (בשבוע האחרון עבד רק מה שלשרת היה עבורו עותק מקומי).
- רעננתי על הדרך את כל האופן שבו אני מתשאל מקורות חיצוניים, מה שאמור לפתור מספר באגים ולהקטין את זמן הריצה בהרבה מקרים (עדיין יש גורמים אחרים שמעכבים ריצות, מקווה לפתור גם אותם).
- מימשתי server side response caching כפי שדוסקס פה. כל קישור לרטרולייזר שמורכב אך ורק מ-URL מקוצר כמו זה, או מקריאה למודול כמו זה, יחזיר כברירת מחדל גרסה שמורה (cached) של התוצאה אם קיימת כמו. ניתן לעקוף את ה-cache ע"י הוספת פרמטר מעקף ל-URL בצורת:

&cache=0

כל הקישורים בשרשור על MaxSharpe Volatility למשל צריכים לחזור כעת תוך שניות ספורות.

זה הרבה שינויים, אם שברתי משהו תודיעו לי.

 

[מתכנת]

@adamshalev תודה רבה!

מימשתי server side response caching כפי שדוסקס פה. כל קישור לרטרולייזר שמורכב אך ורק מ-URL מקוצר כמו זה,

ממה נובע העיכוב?

- מסתבר שיאהו שברו את ה-API שלהם למשיכת נתונים, משהו שאינספור אנשי פיננס הסתמכו עליו. אם זה לא מספיק שהם סגרו את ה-API ההיסטורי שלהם, והפכו אותו למורכב הרבה יותר לגישה עם session/crumb validation, הם גם שינו את סדר העמודות, הפכו את סדר השורות ושברו את מבנה ה-data adjustment כך שהוא לא dividend adjusted יותר, אלא רק split adjusted. למזלי, כל הבעיות הללו היו פתירות וכעת השליפה של נתוני ני"ע זרים צריך לעבוד תקין (בשבוע האחרון עבד רק מה שלשרת היה עבורו עותק מקומי).

תגיד, חשבת ליצור deep copy של כל המידע מיאהו למקרה שהם יסגרו את הבסטה ביום בהיר?

 

[adamshalev]

ממה נובע העיכוב?

לא בטוח. צריך להריץ פרופיילר.

לגבי deep copy - חשבתי ועשיתי לפני כמה שנים, אבל זה חצי פלסטר. נניח שהם היו סוגרים את הבסטה לפני כמה שנים יום אחרי ה deep copy שלי, מה תעשה עכשיו עם הפער שנוצר?
הבעיה היא שאין אלטרנטיבה טובה חינמית חלופית למידע מיאהו עד כמה שאני מכיר. אני *מאד* אשמח לגלות אחרת.

 

[adamshalev]

ממה נובע העיכוב?

פתרתי את זה. כבר אין עיכוב. נבע כי למרות הגישה ל-cache, ה-endpoint היה מבצע parsing מלא ל-builtins שזה די הרבה לפרסר (זה גם חלק ממה שמאט כל שאילתה, אפילו הכי פשוטה. דורש קצת חשיבה על נוחות שימוש מול ביצועים, לא הייתי רוצה שיהיה צורך לעשות import bultins יותר מדי).

 

[מתכנת]

איך אפשר להגדיר סדר מכירת ני"ע עבור איזון תיקים עם 2 ני"ע ויותר?

 

[adamshalev]

איך אפשר להגדיר סדר מכירת ני"ע עבור איזון תיקים עם 2 ני"ע ויותר?

ככה

 

[FIYaacov]

ככה

הסבר למתקשים? איך אבין מה סדר המכירה הרצוי?

 

[adamshalev]

הסבר למתקשים? איך אבין מה סדר המכירה הרצוי?

מה זה סדר המכירה הרצוי?
האלגוריתמים lifo / fifo / maxLoss נידונו בשרשור הנפרד בנושא.
שכבות המחיר הנפרדות נוצרות כתוצאה מאיזון שוטף תחת תנאי שוק שונים.
את הביצוע בפועל אפשר לראות בלוג הפעולות של כל אסטרטגיה בטבלאת התוצאות.

 

[FIYaacov]

מה זה סדר המכירה הרצוי?

סליחה פירשתי את השאלה של @מתכנת כאילו הוא מחפש שיטה אופטימלית.

ד.א. זה לא מוזר שה-CAGR של MaxLoss הוא הכי נמוך?

 

[adamshalev]

סליחה פירשתי את השאלה של @מתכנת כאילו הוא מחפש שיטה אופטימלית.

ד.א. זה לא מוזר שה-CAGR של MaxLoss הוא הכי נמוך?

הוא הכי גבוה.
אתה מסתכל במובייל במקרה?

 

[FIYaacov]

הוא הכי גבוה.
אתה מסתכל במובייל במקרה?

כן. להפוך את סדר העמודות?

עריכה: ראיתי מה הבעיה. בחלק מהתרחישים ה-cagr גולש לשורת הנתונים השנייה ובחלק לא.