Ускорьте мыло magento v1


10

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

  1. Можно ли улучшить скорость мыльного API magento v1? При запросе данных magento быстро компилирует простую информацию, такую ​​как адрес клиента и т. Д., За 1,5 секунды.

    Для запроса нескольких возможных соответствующих узлов данных может быстро потребоваться около 5-7 секунд.

    Сейчас я уже выполняю эти запросы через запросы AJAX, поэтому интерфейс страницы загружается быстро, но было бы неплохо улучшить скорость.

  2. Или было бы лучше написать свое собственное заявление, чтобы дать мне соответствующую информацию непосредственно из базы данных magento? Это не так сложно для БД, и если я делаю прямой запрос, он загружается в течение одной сотой секунды с результатами ...

    Единственное соображение, которое у меня есть с этим вариантом:

    1. Что если magento обновит и изменит схему базы данных?
    2. Или настройка базы данных magento относительно обновлений безопасна / совместима?

У кого-нибудь есть опыт с этим и их истории успеха или неудачи? Мне нужно принять информированное решение, чтобы знать, как действовать.


1
Вероятно, это связано с PHP, а не с MySQL, Nginx или чем-то еще . Так же, как и остальная часть вашего магазина. Сделайте ваш магазин быстрым, и API будет следовать. Тем не менее, он никогда не станет быстрым - методы потока данных / API медленны независимо, поэтому пользовательские реализации всегда будут превосходить за счет управляемости / времени внедрения / возможности обновления.
Бен Лессани - Сонасси

3
нет, это не связано с php ... это все настройки magento, которые невероятно замедляют процесс. Для выполнения запроса мыла API требуется больше времени, чем для запроса большой страницы магазина с несколькими товарами и корзиной. Что-то не так в дизайне magento.
Чаллака

Ответы:


8

Я столкнулся именно с этой проблемой, и я обошел ее, просто работая непосредственно с объектами Magento. Я думаю, что есть проблема изменений кода и всего, что вы описываете, но большая часть моего кода написана в одноразовых скриптах для загрузки старых данных, и тому подобное, так что это была небольшая проблема. Непосредственная работа с объектами Magento также имела побочное преимущество, заключающееся в том, что я выучил внутреннее немного больше, чем я мог бы с помощью только SOAP API - конечно, более крутая кривая обучения, но я чувствую себя немного более осведомленным о том, что происходит. там, чем если бы я придерживался только когда-либо используя SOAP API.

Другой вариант, который мы пробовали, - кэширование данных с использованием Memcached (или что-то вроде Redis тоже будет работать), хотя теперь вам нужно беспокоиться о том, как часто обновлять кэш, откуда и тому подобное. Но он действительно позволяет получить данные намного быстрее. Я думаю, будет ли это хороший вариант, будет зависеть от того, что вы пытаетесь сделать.


Ну, если бы я сделал что-то из самого magento, я бы не получил большого выигрыша в скорости, так как magento все еще нужно «загрузить» для обработки запроса. Мне нравится мыльный api, потому что он «не меняется», но я ненавижу тот факт, что это невероятно медленно реагировать на самые простые запросы. даже основной сайт, который должен обрабатывать гораздо больше запросов, работает намного быстрее.
Чаллака

Я пытаюсь связать magento с нашим программным обеспечением ERP, поэтому мне нужен доступ к самым последним данным в любой момент времени.
Чаллака

1
Возможно - в моем случае я писал вещи, которые загружали бы заказ по инкременту, а затем выполняли какое-то действие на основе его данных. Загрузка полного заказа составляла около 1,5 секунд в SOAP API, или незначительную долю секунды в виде «необработанного объекта». Выбор для меня был ясен, когда я буду загружать сотни из них за один прогон. Другое ограничение также заключается в том, что при использовании стиля «magento app» он должен быть на том же сервере. В моем случае я не возражал против этого, но это стоит помнить.
Майк

1
Как вы загрузили все в виде необработанных объектов?
Чаллака

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

6

Ускорение SOAP API будет трудно. Вы всегда можете добавить какое-то дополнительное оборудование (более быстрый сервер MySQL) или запустить хранилище на NginX, которое, когда вам потребуются несколько миллисекунд, NginX лучше обрабатывает большое количество запросов http. Кэширование не очень поможет, так как ответ на большинство вызовов будет отличаться каждый раз.

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

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


1
база данных mysql не является «бутылочным горлышком», «бутылочный горлышко» загружает все свои файлы конфигурации, загружает каждый кусок дерьма, компилирует мыльный API, а затем, наконец, вспоминает, что я сделал запрос, получил эти данные, оценил их, скомпилировал это в запрошенный формат, проверьте формат и затем выведите его через мыльное соединение .... Проверьте, проверьте, проверьте, что двойная проверка хороша ... но это слишком медленно. В начале все будет хорошо, но через некоторое время потребуется ускорить работу.
Чаллака

Собственный кеш Magento должен помочь вам с объединением конфигурационных файлов, и вы можете использовать компилятор для ускорения кода. Также ускоритель PHP ( en.wikipedia.org/wiki/PHP_accelerator ) повысит вашу производительность здесь. Но в вашем случае, возможно, стоит взглянуть на создание собственного API, который использует API ядра Magento.
Сандер Мангель
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.