REST API - нонстоп заявки при интеграция на Woocommerce

Firefly

Firefly

Well-Known Member
Woocommerce сайт. Складова програма. Двете са вързани през api-то на Woocommerce ,за да може при промени в програмата да отразява същите в сайта. Тоест променяме цената в складовата - промяната се отразява в продукта в сайта. Понеже въпросната интеграция е дело на някаква фирма и те твърдят, че всичко е наред, питам дали има някой по-запознат с тези api-та.

Сайтът изяжда всички ресурси на хостинга (дори на отделен сървър) и постоянно увисва. Би следвало апи-то да се ползва само когато има промени в продуктите в програмата. Доколкото успях да видя обаче, въпросното апи се достъпва нон-стоп и вади заявки GET - на всеки 2-3 секунди. Ако от програмата се редактира 20-30 продукта, сървъра на практика забива почти веднага.

Прикачам скрийншот от лога на апи-то.
 

Прикачени файлове

  • Screenshot_3.jpg
    Screenshot_3.jpg
    151.8 KB · Преглеждания: 23
Под APi не знам какво разбираш, това може да е крон заявка, може само APi да прави стандартни проверки на много кратък интервал, това само при crud, да работи зависи от създателят, може да работи APi по-друг начин, трябва да се погледне от тези който са го направили това APi, другото което, че може хостинга да е някакъв мижъв, надявам се е на vps 8-10Gb ram с 6 ядра? Доста трудно да преценим дали е правилно или не е правилно така да работи някаква интеграция.

Поздрави.
 
Виж си респонса от 5сек (явно е доста смятане) и постоянно се извиква отново и отново. Незнам какво се случва, но ако наистина се налага да се викат толкова често продуктите има проблем по-скоро в реализацията на синхронизацията.
Би следвало да се кешира заявката, след това се следи за инвалидация на кеша и т.н. Това може да се случи и от страната на магазина - слага се един редис или нещо подобно и ако няма промени се връща готов респонс.
 
отделно WordPress работи мн зле с подобни ajax и restful заявки, не е подходящо избрана платформата
 
Никои не може да ме убеди че wp+woo без да намесваме теми/ плъгини и какво ли още не без да се пипне както си трябва тоест да се използва за основа но да се донапише, пренапише кавкото е нужно и тн може да бъде един сериозен проект който да се справя с много големи бази данни и трафик няма как да стане. Има хиляди големи уеб сайтове на който Wappalyzer или други ще ви кажат това е wp и ще си кажете баси бързи/големия/посещавания сайт! Ама не е баш така. Инсталирай ти един wp+woo набии 5-10к и повече продукта като си инвестирал в една тема за 60 долара и хостинг за 20лв. /месец или дори vpn и набии стабилно 2-3+к реклама на месец да видиш как ще се чудиш що това не зарежда и що няма поръчки? Ами щото така си и работи и толкова са му възможностите!
 
Последно редактирано:
contra каза:
Дано поне някой ги трие тия лог ентрита отвреме-навреме.
Увеличете...
Последно видях 78GB такъв лог за 5 дни направен в Български магазин на WP...

Към автора:
Най-добре намери експерт да оправи проблема, ако има такъв или изцяло да се направи ново решение за случая.
 
Станимир И каза:
Последно видях 78GB такъв лог за 5 дни направен в Български магазин на WP...

Към автора:
Най-добре намери експерт да оправи проблема, ако има такъв или изцяло да се направи ново решение за случая.
Увеличете...
Лога го сложих временно докато се опитам да открия проблема. И се трие автоматично.
 
123456aaa каза:
Виж си респонса от 5сек (явно е доста смятане) и постоянно се извиква отново и отново. Незнам какво се случва, но ако наистина се налага да се викат толкова често продуктите има проблем по-скоро в реализацията на синхронизацията.
Би следвало да се кешира заявката, след това се следи за инвалидация на кеша и т.н. Това може да се случи и от страната на магазина - слага се един редис или нещо подобно и ако няма промени се връща готов респонс.
Увеличете...
Въпроса беше дали това е нормално поведение на такъв тип синхронизация, защото аз си мисля, че проблема е в другия край, а не в онлайн магазина. Той в случая не би трябвало да играе роля, освен да поема заявка за редакция в случаите, когато продукт се промени в самата програма. В останалото време не би трябвало да прави нищо.

Когато вкара редакция, вади PUT заявка. Всички останали са GET, които спамят нонстоп.

Та по-скоро исках да видя дали логиката ми е правилна и да ги натискам да си правят бакиите или може да има някой фактор от самия сайт.
 
Firefly това ще е някаква простотия ако искаш пиши на лс да разгледам. Не искам да ти пиша кодове/променям кодове/или да ти оправям апи та. По-скоро ще ми е инт да видя какво имаш като цялло на споделения хостинг или vps или тн... Тоест да проследя от къде идва това нещо което описваш и ако е нещо дребно да го поправим и да си работиш. Пари няма да ти искам ако е нещо за 5-10м работа. Въпроса е да свършим работа. Първо да се види дали има някакви кронове които се задействат през минути и после да се види това апи аджаба какво прави.
 
Firefly каза:
Въпроса беше дали това е нормално поведение на такъв тип синхронизация, защото аз си мисля, че проблема е в другия край, а не в онлайн магазина. Той в случая не би трябвало да играе роля, освен да поема заявка за редакция в случаите, когато продукт се промени в самата програма. В останалото време не би трябвало да прави нищо.

Когато вкара редакция, вади PUT заявка. Всички останали са GET, които спамят нонстоп.

Та по-скоро исках да видя дали логиката ми е правилна и да ги натискам да си правят бакиите или може да има някой фактор от самия сайт.
Увеличете...
Ако онлайн магазина ти е настроен да чете през определено време някакъв feed/json/api и тн натоварването си дива изцяло от теб а не от другия край. И по-скоро пролбема е при твоя сайт а не че някои те товари/изпраща заявки.
 
deepdoff каза:
Firefly това ще е някаква простотия ако искаш пиши на лс да разгледам. Не искам да ти пиша кодове/променям кодове/или да ти оправям апи та. По-скоро ще ми е инт да видя какво имаш като цялло на споделения хостинг или vps или тн... Тоест да проследя от къде идва това нещо което описваш и ако е нещо дребно да го поправим и да си работиш. Пари няма да ти искам ако е нещо за 5-10м работа. Въпроса е да свършим работа. Първо да се види дали има някакви кронове които се задействат през минути и после да се види това апи аджаба какво прави.
Увеличете...
Заради тази простотия местихме сайта 2 пъти, за да видим нещо по сървърите ли е. В процес е да го върнем където си беше. Мога да пиша да го водиш като сме готови. Но не знам какво може да се види. Минават през webhooks на woo-то нещата и реално от програмата не са правили нищо друго, освен да се активира рест апито и да се пусне достъпа за четене и писане през него. Достъп до техните неща от страна на програмата нямам.
 
deepdoff каза:
Ако онлайн магазина ти е настроен да чете през определено време някакъв feed/json/api и тн натоварването си дива изцяло от теб а не от другия край. И по-скоро пролбема е при твоя сайт а не че някои те товари/изпраща заявки.
Увеличете...
Заявките идват от айпито на програмата. Сайтът не е настройван за каквото и да било такова, даден е само достъп от рест апи настройките на woo. В случая ако спра интеграцията, нещата се нормализират.
 
Firefly каза:
Заявките идват от айпито на програмата. Сайтът не е настройван за каквото и да било такова, даден е само достъп от рест апи настройките на woo. В случая ако спра интеграцията, нещата се нормализират.
Увеличете...
В случая пак всичко се върши на твоя сървър и обработва. Това коя скалодвва система ще е? Микроинвест или др? Защото при тях явно е направено да изпраща и за незначителни неща или просто така им работи системата заявки към апи на клиентите. Просто на сляпо го мисля и ти говоря защото имам контрола над онлайн магазини с стотици хиляди продукти апита, скалдове и заявки нон стоп и няма ядове. Трябва да се проследи нишката ама щом минаваш от хостинг на хостинг или от сървър на сървър за да решиш проблема явно не е там проблема. Тоест или те спамят със заявки и ти товарят базата данни нон стоп което сигурно е това през рест апито или ще е друго..
 
deepdoff каза:
В случая пак всичко се върши на твоя сървър и обработва. Това коя скалодвва система ще е? Микроинвест или др? Защото при тях явно е направено да изпраща и за незначителни неща или просто така им работи системата заявки към апи на клиентите. Просто на сляпо го мисля и ти говоря защото имам контрола над онлайн магазини с стотици хиляди продукти апита, скалдове и заявки нон стоп и няма ядове. Трябва да се проследи нишката ама щом минаваш от хостинг на хостинг или от сървър на сървър за да решиш проблема явно не е там проблема. Тоест или те спамят със заявки и ти товарят базата данни нон стоп което сигурно е това през рест апито или ще е друго..
Увеличете...
Магазинът е на гръцкия пазар и програмата е пак гръцка. Преди това бяха на Erply и нямаше проблеми с него. Аз не разбирам много от тея апита и исках да се ориентирам просто дали нещо некадърно е написан модула при програмата за да знам какво да им кажа и да ги натисна да си го оправят. За мен няма логика да праща каквито и да е заявки когато няма активност. Тя цялата идея е просто да праща промени на продукти при сейв в програмата и да обновява съответните в сайта.
 
Щом не може да се пипа другата програма, единственото възможно временно решение е да се сложи някакъв rate limit на уукомерс сайта/сървъра - примерно макс 1 заявка на минута или на 5 минути, каквото там изглежда удачно. Има поне няколко начина да се направи.
 
Не знам защо обаче това ми изгледжа като API request вкаран в foreach...
 
Или с по-прости думи човека трябва да се запали. Живеем в други времена, но трябва поне да си признае , че е УНИКАЛЕН некадърник.
 
Трябва да си влезнал или регистриран, за да отговориш тук.

Горе