I totally agree with your experience, to squeeze performance you eventually need to resort to programming which somehow defeats the concept of framework (which ideally aims at letting you build something without programming). In my case with Drupal, the code base was so large that I didn&#39;t know where to start (not to mention there is a lot of useless code for my needs but apparently needed for the sake of generality). However Drupal (and other frameworks too I suppose) do well for what they were initially intended for (fancy article/story blogging for Drupal), it&#39;s when one tries to customize to its needs (custom permissions, objects, views) that the limitations become most noticeable.<br>
<br>In my case, I ended up writing my own performance oriented framework (PyMP) in Python. I may open source it in the future when I manage to clean/organize the code a bit more for other people to find reuse value in it.<br>
<br>This allowed an average request to drop from 10 seconds down to 0.250 seconds (moving from Drupal to PyMP) on a moderately popular website: <a href="http://codercharts.com">http://codercharts.com</a><br><br><div class="gmail_quote">
On Mon, Jul 18, 2011 at 6:53 PM, Venkatraman S <span dir="ltr">&lt;<a href="mailto:venkat83@gmail.com">venkat83@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Tue, Jul 19, 2011 at 5:53 AM, David Berthelot <span dir="ltr">&lt;<a href="mailto:david.berthelot@gmail.com" target="_blank">david.berthelot@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div>So I generally wouldn&#39;t consider the database speed independent of the framework as long as the framework does some automatic database request generation and type handling. This became particularly obvious as the database grew bigger and the framework became slower.<br>

</div></div></blockquote></div><div><br>I am a speed maniac, and i like apps to be fast, i am ready to sacrifice feature set for good speed; or rather, present the feature set with a few more clicks - i.e, if you are showing an item on a page, then i would generally like to show everything related to that item in a single page; but showing all the related items(which can cause more SQLs and HTTP requests) can cause a probable slowdown, i would rather show links which would link to the related items (sometimes this approach also leads to a lesser cluttered UI - but again, the number of clicks that the user has to do is more [some UI experts rate an app based on the number of clicks that a user has to to achieve an end result]).<br>

<br>Having said that, its very important to profile an app - in a django app that i was developing in my fun time, i happened to see that  there were 40+ queries on a single page, using DDT i was able to diagnose the SQLs being fired, and was able reduce this to just 6 - and out of these 6, 1 sql is for hitting the msgs tbl and the other 1 is for checking if the user is logged in(unavoidable).<br>

<br>I truly believe in the fact that  &quot;performance is a feature&quot; [ <a href="http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html" target="_blank">1</a> ]. Also, IMHO, if you can move bulk of the business logic to SQLs (in most apps you have to use SQLs), then you can make your code less cluttered and also easy to maintain. For eg. in this case [ <a href="http://groups.google.com/group/django-users/browse_thread/thread/b2b3aea021c9b7d0/52d1aa80ea7a2dd5" target="_blank">2</a> ], i moved the filtering to the SQLs; and also even in here, i was firing 3 queries earlier and was doing some iterations (pain!).<br>

<br>To explain [2], i have 2 types of users: employees and general-users(non-emps). I needed to get all items for a given employee or customer(non-emp); if the user happened to be employee then get all items from his org - so you need to iterate over all emps and get respective items for each emp and concatenate the list. If the user was a general-user(non-emp), then simply get his items alone.<br>

<br>items = []<br>if self.is_superorg_user(): #check user type<br>    emps = self.get_all_employees() #get all employees<br>    if emps:<br>      for e in emps: #iterate over the emps<br>        p = Items.objects.filter(created_by=e).filter(deleted=False)  #get items by THIS emp<br>

        if len(p)&gt;0:<br>          items.extend(p) #keep concatenating to the orig list<br>else: #non-emp user<br>  items = Items.objects.filter(created_by=self)<br><br>Now, all those SQLs for emp users, can be removed and replaced with:<br>

<br>items = []<br>
if self.is_superorg_user(): #check user type<br>  items = Items.objects.filter(created_by__employees__org__in=self.employees_set.all().values_list(&#39;org&#39;))<br>else:<br>  items = Items.objects.filter(created_by=self)<br>


<br>[1] <a href="http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html" target="_blank">http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html</a><br>[2] <a href="http://groups.google.com/group/django-users/browse_thread/thread/b2b3aea021c9b7d0/52d1aa80ea7a2dd5" target="_blank">http://groups.google.com/group/django-users/browse_thread/thread/b2b3aea021c9b7d0/52d1aa80ea7a2dd5</a><div class="im">
<br>
<br>-V<br><a href="http://blizzardzblogs.blogspot.com/" target="_blank">http://blizzardzblogs.blogspot.com/</a><br></div></div></div>
</blockquote></div><br>