10

I have multiple questions for experienced magento developers:

  1. Is it possible to improve the speed of the magento v1 soap api? When requesting data it quickly costs 1.5 seconds for magento to compile simple information like customer adress etc...

    To request multiple possible relevant data nodes can quickly costs about 5-7 seconds.

    Now am I already doing those requests via AJAX requests so the page interface loads quickly, but a speed improvement would be nice.

  2. Or would it be better to write my own application to give me the relevant information directly from the magento db? It's not that complicated of a db and if I do a direct query it loads within a 100th of a second with the results...

    The only consideration I have with that option is:

    1. What if magento updates and changes it's database scheme?
    2. Or is the database setup of magento relatively upgrade safe/downwards compatible?

Does anyone have any experience with this and their success or faillure stories? I need to make an informed descision to be able to know how to proceed.

Improve this question
2
  • 1
    Its likely PHP bound, not MySQL, Nginx or anything else. The same as the rest of your store. Make your store fast and the API will follow. However, its never going to be lightening fast - dataflow/API methods are slow regardless, so custom implementations will always outperform at the cost of manageability/implementation time/upgradability.
    – Ben Lessani
    Mar 4, 2013 at 18:30
  • 3
    nah, it's not php bound... it's the entire setup of magento that's slowing things down incredibly. It takes longer for a soap api request to complete than to request a big storeview page with multiple items and shopping cart. Something is askew in the magento design.
    – Tschallacka
    Mar 5, 2013 at 8:09

2 Answers 2

Reset to default
8

I've encountered exactly this issue extensively, and I've worked around it by just working with Magento objects directly. I think there is the concern of code changes and whatnot that you describe, but much of my code is in single-use scripts to load old data, things like that, so it was a minor concern. Working with the Magento objects directly also did have the side benefit of making me learn the internals a little more than I would with just the SOAP API, too - steeper learning curve for sure, but I do feel a little more knowledgeable about what's going on in there than if I had stuck to only ever using the SOAP API.

Another option we tried was caching the data using Memcached (Or something like Redis would work, too), though you now have to worry about how often to update the cache, from where, and things like that. But, it does achieve the goal of retrieving data much, much faster. I think whether or not this is a good option will depend on exactly what you're trying to do.

Improve this answer
5
  • Well, if I were to make something from magento itself I wouldn't gain much speed benefit since magento still has to be "booted up" to handle the request. I like the soap api because it "doesn't change" but I hate the fact that it's so unbeleavable slow to respond to the simplest of queries. even the main site which has to handle much more requests is much faster.
    – Tschallacka
    Mar 4, 2013 at 15:43
  • What I'm trying to do is to link magento to our ERP software, so I need access to the most recent data at any given time.
    – Tschallacka
    Mar 4, 2013 at 15:44
  • 1
    Maybe - in my case, I was writing things that would load an order by increment id, then perform some action based on its data. Loading a full order was about 1.5 seconds in the SOAP API, or a tiny fraction of a second in "raw object" form. The choice for me was clear when I would be loading hundreds of them in a single run. Another restriction, too, is that by doing it "magento app" style is it has to be on the same server. In my case, I didn't mind that at all, but it's worth remembering.
    – Mike
    Mar 4, 2013 at 15:44
  • 1
    How did you load everything in raw object form?
    – Tschallacka
    Mar 5, 2013 at 8:07
  • $order = Mage::getModel('sales/order')->load($order_id);, bascically. There's a snippet or two in this forum thread that might illustrate more: magentocommerce.com/boards/viewthread/18629
    – Mike
    Mar 5, 2013 at 14:34
6

Speeding up the SOAP api is going to be difficult. You could always throw in some extra hardware (faster MySQL server) or run the store on NginX which will when you some milliseconds, NginX is better in handling large amounts of http requests. Caching would not really help that much as the response of most calls will differ each time.

Building your own API from scratch using Magento Core models might be the fastest solution because you can tweak the code to improve performance by only loading exactly what you need. From my experience using the core classes not that much has changed between let's say version 1.5 and 1.7

Edit: I forgot, A small quick win could come from turning on gzip output compression in the htaccess or php.ini file or if you feel up to it move the SOAP api to another server using the same database if the MySQL database isn't the bottleneck

Improve this answer
2
  • 1
    the mysql database isn't the bottle neck, the bottle neck is magento booting up all it's configuration files, loading every piece of crap, compiling a soap api and then finally remember that I made a request, fetch that data, evaluate it, compile it into requested format, validate format and then output it via the soap connection.... Check check check double check is nice... but it's too slow. It will do fine in the beginning, but will need to speed up at some time.
    – Tschallacka
    Mar 5, 2013 at 8:06
  • Magento's native cache should help you there with combining config files, and you can use the compiler to speed up the code. Also a PHP accelerator (en.wikipedia.org/wiki/PHP_accelerator) would boost your performance here. But in your case it might be worth it to look at building your own API that uses the Magento core api.
    – Sander Mangel
    Mar 5, 2013 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.