એન્જિનિયરિંગ

એન્જિનિયરિંગ

Mythex કેવી રીતે બને છે અને ચાલે છે, શું તૂટ્યું અને અમે તેને કેવી રીતે ઠીક કર્યું તે સહિત.

• નિષ્ફળ રીપબ્લિશ ક્યારેય કામ કરતા બેકએન્ડને ડિલીટ નથી કરતું — નિષ્ફળ રીપબ્લિશ એપનો લાઇવ API ડિલીટ કરી શકતું, અથવા તૂટેલું નવું વર્ઝન ચાલુ રાખી શકતું. Mythex પબ્લિશને યોગ્ય રીતે પાછું વાળે છે તેની ત્રણ રીત.
• એલર્ટ્સ જે દરેક સર્વર દીઠ નહીં, એક વાર ફાયર થાય — એક દૈનિક એલર્ટ એક બપોરે અમારા સુધી પાંચ વાર પહોંચ્યું. બે સર્વર અને ડિપ્લોય સાથે ઇન-મેમરી ડિડુપ કેમ તૂટે છે, અને શેર્ડ સ્ટેટે તેને કેવી રીતે ઠીક કર્યું.
• મોટા વર્કસ્પેસ પર જવું, કોઈને રાહ જોવડાવ્યા વિના — અમારા એક ચોથા ભાગના વર્કસ્પેસ 2 GB પર ગયા પછી પણ 1 GB પર અટકેલા હતા. અમારો પહેલો સુધારો એક વ્યક્તિને સાત મિનિટ રાહ જોવડાવતો હતો. અમે શું બદલ્યું, અને ફરી શું બદલ્યું.
• ડેટાબેઝનું બિલ તે જેટલો વપરાય છે તે પ્રમાણે — અમે દરેક એપના ડેટાબેઝ ખર્ચનો અંદાજ કાઢતા હતા, અને તે અંદાજ બંને તરફથી ખોટો હતો. હવે દરેક ડેટાબેઝનું બિલ માપેલા વપરાશ પ્રમાણે, કલાક-કલાક મુજબ બને છે.
• પબ્લિશ કર્યા પછી તરત ક્રેશ થતી એપ પકડવી — ત્રણ પબ્લિશ અમારા હેલ્થ ચેકમાં પાસ થયા, જ્યારે તેમનો API દરેક બૂટમાં સેકન્ડો પછી ક્રેશ થતો હતો. કારણ: ક્રેશ ગણવા માટે પાંચ એન્ટ્રી સુધી મર્યાદિત યાદી વાપરવી.
• Image-heavy agent turns ને memory માં રાખવા — catalogue scans જોતો એક agent turn 952 MB પર memory માંથી બહાર ગયો. ત્રણ અલગ કારણો, દરેક images ને વધુ સમય પકડી રાખતા, અને અમે તેમને કેવી રીતે ઠીક કર્યા.
• Context window ની અંદર લાંબા agent turns કેવી રીતે રાખવા — અમારા sub-agents વધીને મોડેલને નકારતા, રૂમ બચાવવા વહેલા અટકતા, અથવા રશિયન tokens ખોટા ગણતા. ત્રણ fixes જે લાંબા AI કામને પૂરું થવા દે છે.
• જ્યારે ફોન સૂઈ જાય ત્યારે ચેટ ચાલુ રાખવી — ફોન સૂઈ જાય, tabs બદલે, અથવા build વચ્ચે network ગુમાવે. બે bugs ને લીધે Mythex ની ચેટ અટકતી અથવા અડધો જવાબ બતાવતી. બંનેનો fix.
• એક ભારે ચેટ અમારા API ને કેવી રીતે બંધ પાડી શકે — 28 સપ્ટેમ્બરે અમારા બંને API સર્વર એકસાથે મેમરી ખૂટી જવાથી બંધ પડ્યા. પહેલો ઉકેલ વધુ મેમરી હતો; સાચો ઉકેલ ચેટ ઇતિહાસ ગણતરી પ્રમાણે નહીં, કદ પ્રમાણે લોડ કરવાનો હતો.
• Publish બે વાર દબાવવાથી હવે એક જ વાર પબ્લિશ થાય છે — એક જ એપ માટે ત્રણ પબ્લિશ રિક્વેસ્ટ 84ms ના અંતરે આવી, અને દરેકે આખું ડિપ્લોય ચલાવ્યું. અમે ડેટાબેઝ નક્કી કરે તેવું કેવી રીતે કર્યું, અને બાકીનાને સાચું કેવી રીતે કહ્યું.
• અમારી પોતાની સાઇટ સુધારવામાંથી મળેલા SEO પાઠ — ડુપ્લિકેટ FAQ માર્કઅપ, Google માં ખોટો થંબનેલ, ક્લિક ન થયેલાં ટેમ્પ્લેટ પેજ અને અમારી પોતાની એજે નકારેલો પાથ: mythex.ai પર અમને શું મળ્યું અને અમે શું ઠીક કર્યું.
• સ્ટેટિક સાઇટ્સ હવે ફરી પ્રકાશિત થતી વખતે પણ ચાલુ રહે છે — સ્ટેટિક સાઇટને ફરી પ્રકાશિત કરતી વખતે પહેલાં લાઇવ સાઇટ ખાલી થઈ જતી હતી. હવે નવી સાઇટ તૈયાર થાય ત્યાં સુધી જૂની બતાવાય છે, અને ફેરફારો સેકંડોમાં દેખાય છે.
• પ્રોગ્રેસ લેબલમાં છુપાયેલો આઉટ-ઑફ-મેમરી ક્રેશ — અમારો AI એજન્ટ એક મોટી ફાઇલ લખતી વખતે મેમરી ખતમ થઈ ગઈ. કારણ મોડેલ કે સમાંતર સબ-એજન્ટ્સ નહોતા — તે એક સ્ટેટસ લેબલ હતું, જે 41,000 વખત ફરી મોકલાયું.
• ગુમ થયેલી સ્વૅપ ફાઇલ જેણે અમારા સર્વર થંભાવી દીધા — એક પ્રોડક્શન સર્વર ક્રેશ થયા વિના જવાબ આપતું બંધ થઈ ગયું — કોઈ આઉટ-ઓફ-મેમરી કીલ નહીં, બસ સ્વૅપ વગરના બૉક્સ પર પેજ-કેશ થ્રેશિંગ. શું થયું અને અમે શું બદલ્યું.
• ડેડ કનેક્શન વિના ડેટાબેઝને ફરી જગાડવા — સ્લીપમાંથી જાગતી પબ્લિશ થયેલી એપની પહેલી વિનંતી 10–12 સેકન્ડ અટકતી હતી, કારણ કે સૂતી વખતે મરી ગયેલાં ડેટાબેઝ કનેક્શન વપરાતાં હતાં. અમે તેને 2.3 સેકન્ડ સુધી લાવ્યા.
• અમે અમારી પોતાની સેવાઓને રેટ-લિમિટ કરી રહ્યા હતા — અમારા API ની પ્રતિ-એડ્રેસ રેટ મર્યાદાએ અમારી પોતાની સેવાઓને એક વ્યસ્ત વ્યક્તિ ગણી લીધી, અને પ્રોડક્શનમાં તેમને 429 મળવા લાગ્યા. અમે તે કેવી રીતે શોધ્યું અને ઠીક કર્યું.
• Mythex ના સર્વર ARM પર કેમ ખસેડ્યા — જ્યારે ભારે કામ પ્રોજેક્ટ-દીઠ સેન્ડબોક્સમાં ગયું, ત્યારે અમારા સર્વર તેમની મેમરીનો ત્રીજો ભાગ વાપરતા હતા. નાનાં ARM ઇન્સ્ટન્સથી માસિક ખર્ચ લગભગ 30% ઘટ્યો. કેવી રીતે.
• ડિપ્લોય્સને શૂન્ય 502 એરર સુધી કેવી રીતે લાવ્યા — અમારા ડિપ્લોય સામે દોડતો વૉચડૉગ અને ખૂબ મોડેથી નોંધ લેતો લોડ બેલેન્સર: અમે બંનેને કેવી રીતે શોધ્યા, ઠીક કર્યા, અને ડિપ્લોય્સને 10 502 થી શૂન્ય સુધી માપ્યા.