Прискорити magento мило v1

У мене є кілька запитань для досвідчених розробників magento:

Чи можна підвищити швидкість мильного апарату magento v1? Коли потрібно запитувати дані, Magento швидко збирає 1,5 секунди для збирання такої простої інформації, як адреса клієнта тощо ...

Запросити кілька можливих відповідних вузлів даних може швидко коштувати приблизно 5-7 секунд.

Зараз я вже роблю ці запити через запити AJAX, тому інтерфейс сторінки швидко завантажується, але покращення швидкості було б непоганим.
Або краще було б написати власну заявку, щоб дати мені відповідну інформацію безпосередньо з magento db? Це не так складно db, і якщо я роблю прямий запит, він завантажується протягом 100-ї секунди з результатами ...

Єдине враження, яке я маю з цим варіантом:
1. Що робити, якщо magento оновлює та змінює схему баз даних?
2. Або налаштування бази даних magento щодо відновлення безпечно / вниз сумісно?

Хтось має досвід з цим та їхніми успіхами чи невдачами? Мені потрібно зробити зважене рішення, щоб мати можливість знати, як діяти.

performance api

— Цхаллацька
джерело

Ймовірно, пов'язаний PHP, а не MySQL, Nginx чи що-небудь ще . Те саме, що і решта вашого магазину. Зробіть свій магазин швидко, і API буде слідувати. Однак його швидше не буде легким - методи потоку даних / API повільні незалежно, тому користувацькі реалізації завжди переважають за рахунок керованості / часу впровадження / оновлення.

— Бен Лессані - Сонассі

Ні, це не пов'язане з php ... Це все налаштування магенто неймовірно уповільнює справи. Щоб виконати запит на мильну аппі, потрібно більше, ніж на велику сторінку перегляду магазину з кількома предметами та кошик для покупок. Щось прокинуто в дизайні магенто.

— Цхаллачка

Відповіді:

Я дуже часто стикався з цією проблемою, і я працював над нею, працюючи безпосередньо з об'єктами Magento. Я думаю, що існує стурбованість змін коду і того, що ви описуєте, але більша частина мого коду є в сценаріях для одноразового використання для завантаження старих даних, подібних речей, тому це було незначною проблемою. Робота з об'єктами Magento також мала побічну перевагу змусити мене навчитися інтернату трохи більше, ніж я б тільки за допомогою SOAP API - теж крутіша крива навчання напевно, але я відчуваю трохи більше знань про те, що відбувається там, ніж якщо б я дотримувався тільки коли-небудь використання SOAP API.

Іншим варіантом, який ми намагалися, було кешування даних за допомогою Memcached (Або щось на зразок Redis теж буде працювати), хоча вам зараз доведеться турбуватися про те, як часто оновлювати кеш, звідки і подібні речі. Але це досягає мети отримання даних набагато, набагато швидше. Я думаю, чи це хороший варіант, залежатиме від того, що саме ти намагаєшся зробити.

— Майк
джерело

Що ж, якби я сам заробляв щось із магенто, я не отримав би великої користі від швидкості, оскільки магенто все-таки повинен бути "завантажений" для обробки запиту. Мені подобається мильна апліка, оскільки вона "не змінюється", але я ненавиджу те, що настільки неперевершено повільно реагувати на найпростіші запити. навіть головний сайт, який має обробляти набагато більше запитів, набагато швидше.

— Цхаллачка

Те, що я намагаюся зробити, - це зв’язати magento з нашим програмним забезпеченням ERP, тому мені потрібен доступ до останніх даних у будь-який момент.

— Цхаллачка

Можливо - в моєму випадку я писав речі, які завантажували б замовлення за допомогою ідентифікаційного кроку, а потім виконували якусь дію на основі його даних. Завантаження повного замовлення становило близько 1,5 секунд в SOAP API, або невелика частка секунди у вигляді "необробленого об'єкта". Вибір для мене був зрозумілим, коли я завантажуватиму їх сотні за один пробіг. Ще одне обмеження - це те, що, виконуючи його в стилі "magento app", він повинен бути на одному сервері. У моєму випадку я зовсім не проти цього, але це варто пам’ятати.

— Майк

Як ви завантажили все в необробленому вигляді об’єкта?

— Цхаллачка

$order = Mage::getModel('sales/order')->load($order_id);, в основному. У цьому форумі є фрагмент або два фрагменти, які можуть ілюструвати більше: magentocommerce.com/boards/viewthread/18629

— Майк

Збільшити швидкість використання api SOAP буде непросто. Ви завжди можете запустити додаткове обладнання (швидший сервер MySQL) або запустити магазин на NginX, який, коли ви пройдете кілька мілісекунд, краще буде обробляти велику кількість запитів http. Кешування насправді не допоможе настільки, що відповідь на більшість дзвінків буде відрізнятися щоразу.

Створення власного API з нуля за допомогою моделей Magento Core може бути найшвидшим рішенням, оскільки ви можете налаштувати код для підвищення продуктивності, завантаживши саме те, що вам потрібно. З мого досвіду використання основних класів не так багато змінилося між скажімо, версіями 1.5 та 1.7

Редагувати: я забув, невеликий швидкий виграш може виникнути від включення компресії виводу gzip у файлі htaccess або php.ini або якщо ви відчуваєте, що це перенести api SOAP на інший сервер, використовуючи ту саму базу даних, якщо база даних MySQL не буде вузьке місце

— Сандер Манґел
джерело

база даних mysql - це не шийка пляшки, шийка пляшки - магенто, завантажуючи всі файли конфігурації, завантажуючи кожен шматок дерьма, збираючи мильний api, а потім, нарешті, пам'ятаю, що я зробив запит, отримав ці дані, оцінив його, скласти його в потрібний формат, підтвердіть формат, а потім виведіть його через підключення мила .... Перевірте перевірити перевірити подвійну перевірку ... але це занадто повільно. На початку це буде добре, але потрібно буде прискорити деякий час.

— Чаллачка

Рідний кеш Magento повинен допомогти вам у поєднанні конфігураційних файлів, і ви можете використовувати компілятор для прискорення коду. Також прискорювач PHP ( en.wikipedia.org/wiki/PHP_accelerator ) підвищить вашу ефективність тут. Але у вашому випадку, можливо, варто поглянути на створення власного API, який використовує ядро api Magento.

— Сандер Мангел