Performance?

[andreassolberg]

Hi, I hope you're ok with questions through github issues.

How is the performance of this library compared to the alternatives? I notice that this is native php, without any C-bindings, somewhat worried that this convencience comes at the cost of poor performance.

I really like the design of the library though, the support for composer, etc.

Thanks!

[bborisovs]

Hi @andreassolberg ,

I can only speak as a user, but so far we have no complaints.
Of course we should consider workload; we don't have massive loads just now - 80-100k rows insert statement spread over ~18h period(with peaks twice a day we hit ~20k an hour); and additional 12-15k rows inserted over 15 min period daily [easily achieved in less than 15 min, but limited by 3rd party API]; During actual peak periods (during December) we expect to have around 160-200k rows over 18h.

I don't have actual stress test data, but you got me interested, so will aim to get some data and post back.

Still to attempt to answer your question - I personally don't find it slow; what I would say is - give it a go, do some tests with data close to your sets and see how it's going to perform.

Thanks

[andreassolberg]

Thanks for your response.

[evseevnn-zz]

I think possible improve performance use in the right places the APC. Unfortunately, at the moment I do not have enough time for that would do in the matter seriously.

[LarsFronius]

Theoretically it would be possible to have a query interface that decouples querying from fetching responses. It's not super trivial though.

From real world use-cases I can tell you, that we definitely just yesterday had a workload of pushing out 10.000.000 rows in less than 24 hours. It was mainly tracking of events, that we did not track before. Adding the library and calls into the codebase, did not significantly increase load on the PHP side nor latency. We are still not fully done on the analysis, but from this perspective the system seems pretty stable and performing well.