בחוזר בדיקת ומיתוג של ממשקי API כדי לשמור על זרימה של תרגומים

[Simon Lloyd]

יש לי שלי מגבלת תווים עבור גוגל כ- 100,000 perday כך עם ההגדרות שלי תמיד השתמש גוגל, "השתמש גוגל API V2", "השתמש Google איתור" כאשר ניתן להגיע להגבלה זו ולקבל עוד תוצאות מ- Google בתשלום האם זה אפשרי ללא תשלום ממשקי Api להתחיל לאחר מכן מניבות תוצאות?

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

המסופקים
גוגל בחר תווים 100,000 ליום > נגמרה > vBET לעבור API הבא ברשימה > Microsoft 400 k לכל שעה או 4 מ' כאשר למגבלה של API של vBET הסימון הבא, הקודם כדי לראות אם הוא הרים או יש חלק הקצבה > אחת להעביר הבא API או בחזרה ל- Google ששולם בעת למגבלה שוב > בדוק API הבא... ועוד וכך בדיקת מעגלית לאחר בקבלת קוד שגיאה היו נושאים, אז די הרבה יכולת קבוע יש תרגומים.

[vBET]

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

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

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

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

ללא תלות באופן בו יבוצע, גוגל תהיה כאל אחד API (v1 או v2 בהתאם לתצורה) - אין טעם לפצל אותו, כי גוגל v1 ייסגרו בקרוב מאוד.

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

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

ספרי איזה פתרון עדיף.

[vBET]

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

[vBET]

הודעה מהירה רק - אנו מיישמים כבר תכונה זו.

אנחנו רוצים לשחרר אותו הרצה (BETA) עקב בעיות נפוצות, נגרם על-ידי בגבולות המוגדרים על-ידי ספקי תרגום. אנו מחפשים גם יישומים אחרים יכולים להיות נתמך על-ידי vBET:)

[Simon Lloyd]

המחשבות שלי היו לשלוח את התרגום הסימון תחילה כדי לראות אם מועדף ספק זמין, כך שנתת לנו קוד כדי לבדוק אם google או MS מגיבה, כך בזמן השיחה עבור תרגום הבדיקה googleapi (שם של קובץ בדיקה שלי עם הקוד הבדיקה שלך) אם התרגום הוא true להשתמש preffered, אם התרגום flase, או קוד אינו 200 ולאחר מכן נסה ספק הבא ברשימה, לבצע את המבחן api שלהם לפני השימוש.

יכול להיות לך תיבת רשימה בה המשתמש יכול להציג כל ספק אחד בכל שורה לפי סדר עדיפות (מאפשר בעת הוספת תמיכה עבור יישומים אחרים המשתמש פשוט להוסיף אותם לרשימה), כך רשימת שלי יכול להיראות כך:
מיקרוסופט
MyTranslator
Google
YourTranslator
AnOtherTranslator

בהנחה שמות דאפט נכנסתי היו ספקי אמיתי, שיחה עבור קוד מבחן תרגום MS יפעל, אם בשימוש תגובת 200 MS אם לא קוד בדיקה MyTranslator ריצה, בדוק אם התגובה עבור 200 אם כן להשתמש בו אם לא להפעיל קוד מבחן גוגל ********** ועוד

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

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

[Simon Lloyd]

הודעה מהירה רק - אנו מיישמים כבר תכונה זו.

אנחנו רוצים לשחרר אותו הרצה (BETA) עקב בעיות נפוצות, נגרם על-ידי בגבולות המוגדרים על-ידי ספקי תרגום. אנו מחפשים גם עבור יישומים אחרים יכולים להיות נתמך על-ידי vBET:) שלחתי לך אחד או שניים (בהודעה שמחקת בשל הקישורים) יכול לגשת, אם ברצונך ביתא מתנדבים הגבר שלך:)

[vBET]

שלחתי לך אחד או שניים (בהודעה שמחקת בשל הקישורים) יכול לגשת, אם ברצונך ביתא מתנדבים הגבר שלך:)

ההודעה שלך חרש נמחק, כיוון התוכן שלו היה המודעה נכתב על ידי מישהו אחר, אבל יש לנו גישה להודעה זו, אנו עומדים על אותו:)

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

כך אנו פועלים לשיפור vBET והפכה אותו כ זולים שימוש ככל האפשר:)

[vBET]

אנחנו בשלבים האחרונים של פונקציונליות חדשה tesing. ניתן כבר לראות תיאור שהשתנו: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (ראה הערה אחרונה)

[Simon Lloyd]

מיכאל תודה, עשיתי הצבה מהירה ב taht שאלות נפוצות אשר ללא ספק יהיה עליך להסיר מכיוון לא המקום הנכון עבור אותו:) אם ברצונך לבדוק ב לוח חי קורא תרגומים רבים PM אותי ואני אתן לך גישה לספריית הבסיס admincp, פורום, גם שמתי הגבלת תרגום גוגל אני צריך להגדיר למעלה ולמטה לבקשתך כדי שתוכל לבחון:)

[vBET]

אישור זאת. תור ספקי מיושם, ייכלל במהדורות 3.5.1 ו 4.4.3. vBET 3.5.1 יפורסמו היום. vBET4.4.3 הוא עדיין בשלב הבדיקה. מהדורות דוכן יהיו ביתא כך כולם לבדוק אותו בפורום גדול יותר הבודקות את אחד. נא שים לב כי אנו כבר בודק 3.5.1 באחד הפורומים האמיתי שלנו. עדיין בשל שינויים חשובים היא בשלב בטא תחילה.

[Simon Lloyd]

האם זה צריך להיות משימה מתוזמנת, ספק מסוים אחד כבוי למשך שעה בכל פעם?, עשיתי הצעה עגול כאן בדיקת ומיתוג של ממשקי Api כדי לשמור על זרימה של תרגומים בו אולי היתה תמיד להתחיל בחלק העליון של רשימת הספקים שלנו ואנו לבצע בדיקת שיחה (כמו שאתה המסופק כדי לבדוק את תגובת גוגל ואת תגובת מיקרוסופט) אם מבחן קריאת התגובה היא 200 או טקסט מתורגם השתמש בספק זה, אם התגובה היא לא 200 או בדיקת טקסט מתורגם לא (באמצעות טקסט זהה עבור כל בדיקה, את regex של האימות כדי לבדוק את הטקסט המתורגם) אז לעבור ספק הבא, כל קריאה תרגום לאחר מכן להתחיל בחלק העליון של הרשימה ולאחר עבודה למטה

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

[vBET]

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

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

נא שים לב כי באפשרותך לשנות באיזו תדירות vBET עליך לבדוק ספקי זמינות. כעת היא אחת לשעה, אך באפשרותך להגדיר מחדש כי CP מנהל - > משימות מתוזמנות - > מנהל המשימות המתוזמנות ולהגדיר אותו לדוגמה עבור כל 10 דקות 0 בדיוק כמו פעילות RSS פוסטר רובוט לעשות זאת כעת.

[vBET]

שינוי קטן שבוצע - נבדוק זמינות ספק לא פעם לשעה אבל כל 10 דקות. אם כבר ביצעת שדרוג ל- vBET 3.5.1 לפני הודעה זו נא פשוט הורד את החבילה vBET שוב ולהעלות מוצר הקובץ שוב.

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

[Simon Lloyd]

החבר'ה עבודה רבה:), שדרגו לזה אבל אני יוריד את התיקון העדכני ביותר והשימוש, אני אצור רצף חדש לקבלת משוב זה.