I found that most the time it’s the overall system logic of the system that gives the biggest improvements.
Even if this system is pretty huge, I had to change literally those two functions and gained about 3x speed improvement, but in reality this runs on N servers and it’s in N levels (api calls api that calls api, etc…)
If I find something better, I’ll post here.
But for now, the next bottleneck is XML parsing, it can now take up to 30% of the page run time (and I get that from another system, so can’t change it).
Using simplexml_load_string / xpath to load only the data I need (xpath), but it’s still slow and the code is messy…
Well that is encouraging, dropping one bottleneck down to another of a different type is good progress. I’m working with an XML bottleneck myself, but the primary issue has been the retrieval of the XML file (comes from a third party site), not the processing (but I digress, my XML file is likely far smaller than yours at this point in time ~ roughly 1000-1500 elements in it).
Some of mine are not that big either, but I have allot of them.
Remember, each search gets 900 of these XML requests, and since they are a wrapper around an old school terminal, they come with a “next page” token… (so, 1 search = ~900*[page count])
I get a small page (10-500KB), then sometimes I have to do a few next page requests, to get rest of the data… (so keep alive and reuse the connection to avoid 1000 handshakes speeds it up)
Yeah, I keep forgetting you have 900 responses If you ever want us to help optimize your XML parsing, just let us know. More than willing to give it a look, but I find, using xpath or simplexml_load_string typically do a fine job in this area.
If you ever want us to help optimize your XML parsing, just let us know. More than willing to give it a look, but I find, using xpath or simplexml_load_string typically do a fine job in this area.