• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 733
  • Last Modified:

Does views heavly affect performance on Drupal?

I am inmersed in a discussion to decide whether to use Views on a Drupal site or not, since Views is one of the most used modules I am biased to use it, however I have inherited a Drupal site where the former developers avoid using views and craft their "own optimized queries" arguing that Views hits performance a lot. While I might agree with the statement that a optimized query is better than a View I feel that there are other ways to scale a site using without loosing Views functionality.
What I would like to know from you guys is your opinion about how hard is performance affected by Views and the possible solutions, techniques, tutorials.
Please tell me if you consider to avoid Views as a reasonable option?
0
pksplus
Asked:
pksplus
3 Solutions
 
Thomas4019Commented:
I totally agree with you. Views is fast enough for the vast majority of listing style pages. There's a few though that I end up having to write by hand, but not many.
0
 
Kent OlsenData Warehouse Architect / DBACommented:
Hi Pks,

Views are generally "atomic operations".  That is, a view returns a result set (via a derived table) that is then passed through the filter clause of your Select statement.  If the view returns a large result set you'll likely get better performance by writing your query to access the database tables directly.

Consider these two views:

1.  CREATE VIEW v1 AS select * from mytable
2.  CREATE VIEW v2 AS select * from mytable WHERE {condition-1}


Now let's use them.


  SELECT * from v1
  SELECT * from v2

Either of the queries above will give you the same performance as if the query were against the table (mytable).


  SELECT * from v1 where {condition-2}
  SELECT * from v2 where {condition-3}

These are a little trickier.  The first of these will also perform as if the query were against the base table.  

However, the last one will not.  The RDBMS will apply the filter in the view and generate a result set.  The filter in the SELECT statement will be applied to the result set.  It is handled separately from the filter in the view.  If the view returns a lot of rows you may see a performance issue.  This especially frustrating if the filter in the query COULD have used an index if the condition were checked in the view.

Views are great things.  But they aren't always the correct solution.


Kent
0
 
RobertPopeCommented:
Don't forget it's a good idea to cache your views where practical - if you have numerous views this can really help!
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
pksplusAuthor Commented:
Ok I'm assuming that your answer apply to both cases Views as from a Database perspective and the Drupal Views Module, which is the topic of this question. Part of my confusion always happen when talking about big or small queries, and big and small sites, would you please tell me what do you define as a big site and a big query (how many elements), of course I understand that this answer has to do with the hardware, but  lets consider a threshold of one single server. In other words:
 
How many load do you consider a Drupal site will handle before you have to use more complex  or distributed techniques to scale? and
How much would the same will increase its performance its performance using custom  outputs instead of using the Views Module?
0
 
Kent OlsenData Warehouse Architect / DBACommented:
Hi pks,

Generally, the size of the row doesn't have a significant impact on the query performance.  Yes, there can be noticeable differences when the lengths are extremely different (say 20 bytes vs 4,000 bytes), but if you use an "average" of about 200 bytes per row, you can probably disregard the row length.

Row count is the critical item.  If the view returns 10,000 rows or less, and can do that in under a second, I'd code to the view.  It makes the coding that much simpler, and multiple tasks code to the exact same standard.

If the view return 50,000 rows, or it can't generate the result set in under a second, then it may be time to consider bypassing the view and coding directly to the table(s).


Kent
0
 
RobertPopeCommented:
Basic views queries (drupal views), and by basic I mean accessing 1 or two tables, are generally very efficient.  Typically I track the slow query log.  When I find a query that sticks out (takes several seconds or more to complete) I will take a look at that query to see if I can get the information out in a more efficient manner.  Right now we target all queries that take longer than 500ms to complete for analysis.

If our queries are efficient at this rate and page loads are exceeding 1 second for authenticated users we then check for php coding inefficiencies.  at that point we do a cost/benefit analysis to see if it's going to be more worthwhile to optimize, or just throw more hardware at it.
All queries are different, but hand rolling some queries can realize gains of 10-500% speed boost or more in special situations.  

That being said though you need to weigh the gains where you lose integration.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now