Monday 28 March 2011 9:35:18 pm
I just run my tests against a DB with 250-300 content objects:
eZ Find is pretty constant at ~0.2 sec.
My guess is that the eZ Find wrapper takes most of the execution time (solr is probably very efficient to handle the request).
For content fetch functions, I use no attribute filter nor attribute sorting and limit the fetch to 10 objects (same as the ezfind result). The speed is not very consistent:
Most queries get executed between 0.05sec and 0.1sec. Sometimes I see some spikes up to 0.3sec 0.5sec.
In my test, I'm bypassing db query cache but it looks like there is some other cache making most of my sql queries a little faster than eZ Find. As soon as you have it in the query cache it's super fast (eZ Find doesn't have that type of cache).
I'm sure it's a different stories if you add an attribute filter or attribute sorting (joins ezcontentobject_attribute). I previous tests I saw execution times of a couple seconds for those types of fetches.
In Mysql you have a in memory query cache which you can size based on server RAM. So you can use lets say 1G. Query cache will cache results for queries so if all results of most used queries fit in 1G you will never have speed issues The problem is that with large sites you have lots of different queries with lots of joins so you will hit that barrier soon. Then you should think about solr & ezfind, as you can have millions of nodes, the query will always be fast. And solr is much easier to scale then Mysql. This is especially true if you need to do some text searching.
BTW do you have a ez db with at least 10000 nodes?