We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Performance Tips: Starting with Models in controllers...

Hi,

Would anyone be willing to share any tips on leverageing performance in phalcon particularly in the way models are called in view and controller?

So for example what would be the most performant code when displaying multiply related models which includes getting firsts and lasts of related models in the view.

(edit: It's working!)

??? ??? ???

get it working first. then worry about making it faster if you have to.



9.7k

As mentioned above, make it work first. Then use the database's tools for showing you the SQL plus the database's interpretation of the SQL. You are far more likely to improve speed by working with the database to add indexes or increase a buffer allocation.

When you find the worst performing queries, bring them back to here to discuss how you might change the query through Phalcon.



47.7k
edited Aug '17

I ended up installing webgrind to display the xdebug profiler cache.

This has helped me pinpoint problem area's.

git clone https://github.com/jokkedk/webgrind.git



9.7k

What were the worst problems?



47.7k

A bad function to generate a url in a model the needed to get GrandParent details.

The rest I can't pin down because they are all model related and webgrinder can only tell me:

php::Phalcon\Mvc\Model\Query->_executeSelect
php::Phalcon\Db\Adapter\Pdo\Mysql->query

Slow query logs in sql reveal nothing.

Does anyone know the most performant way to make calls on the Model?



9.7k

Does Webgrind tell you if the delay is Phalcon CPU or if it is MySQL?

For MySQL, you can get the SQL and test the SQL outside of Phalcon. It is a database issue.

If it is Phalcon, it is more likely to be the handling of the request or results. For example, it might bring back a list one row at a time instead of all rows in one database call. The generated SQL might indicate that type of problem. After you know the problem, you can look for model overrides to fix the problem.



47.7k
edited Aug '17

I'm generally not using phql or mysql. I'd like to keep to the model.

No it doesn't tell you.

I'm not trying to view this through the lense of phalcon vs mysql.

I'm trying to look at this as the best practise way to leverage phalcon so the best way to call on the model.

Should i generate a model object and find all relations to it? Or is it more performant to write a phql query that does the same job? Or something else?

So more like tips phalcon coding tips on getting related models maybe? The most performant way to leverage phalcon....



9.7k

For a Phalcon oriented approach, a developer would need to know the code structure, the request, and the way the data is stored.

You can reduce model overheads when you bypass the model and work closer to PDO. It only makes a significant difference for some types of access. Think of a list where you want the first 20 rows. The model might read them one row at a time. A direct SQL request could ask for 20 rows at a time, reducing the internal processing.

When you change the model usage, you can see some of the effect through request logs. If your request translates to SQL, some databases log the SQL request and you can use the log to pick up some perfornace problems. You could then as a specific question here. You could post the generated SQL and ask how to change the model to produce bettwer SQL requests or how to change the model to produce better indexes on the tables.

I contributed performance enhancements to Drupal in the form of SQL and table structure changes. That was achieved by looking at the SQL log.



47.7k
edited Aug '17

That tallies with what i am seeing.

This appears to be quite expensive and I don't think I need to use it so much:

php::Phalcon\Mvc\Model\Manager->getRelationRecords().

That's my angle of attack sorted. I'll give it a shot and report back after a refactor.

Thanks!

For a Phalcon oriented approach, a developer would need to know the code structure, the request, and the way the data is stored.

You can reduce model overheads when you bypass the model and work closer to PDO. It only makes a significant difference for some types of access. Think of a list where you want the first 20 rows. The model might read them one row at a time. A direct SQL request could ask for 20 rows at a time, reducing the internal processing.

When you change the model usage, you can see some of the effect through request logs. If your request translates to SQL, some databases log the SQL request and you can use the log to pick up some perfornace problems. You could then as a specific question here. You could post the generated SQL and ask how to change the model to produce bettwer SQL requests or how to change the model to produce better indexes on the tables.

I contributed performance enhancements to Drupal in the form of SQL and table structure changes. That was achieved by looking at the SQL log.



47.7k

I wrote a sql query that couldn't be written in phql and called it against the database connection.

My sql query had a join on select statement with joins and a group by. Maybe it can be done in phql.

In any case I shaved off 1sec. Thanks!