Performance tips?

dalecosp

Everyone wants a fast site.

Have you ever discovered something that greatly improved the performance of your site/code/application that was fairly easy and you'd like to share?

For example, I was so happy when I discovered that I could serve scripts and pages from shared memory on Linux....

NogDog

We use Solr a lot to optimize response time on common queries across large data sets.

Bonesnap

I'm actually right in the middle of auditing a site for a client to make sure it's really speedy (even though it's a static site of mostly text). These are some easy things you can do:

Minify any JavaScript files (and consider combining files if it's reasonable)
Minify CSS
Use image sprites and CSS to reduce HTTP requests
For images that cannot be included in a sprite make sure they are optimized for the web
Move non-essential <script></script> tags to the footer
Use a decent host

You could even minify your HTML if you wanted to.

That covers most things for sort of the "client-side" of things. Behind the scenes it really depends on the site.

kredpl

I had such a feeling when on one of my Joomla sites I migrated from PHP 5.2.x to 5.3.x.

NogDog

Found out today how to do a PostgreSQL query with a limit (and offset) while still getting the total number of rows that would have matched without the limit.

SELECT col1, col2, COUNT(*) [COLOR="#B22222"]OVER()[/COLOR] FROM table1 LIMIT 10 OFFSET 0;

The OVER() (which can have a bunch of parameters I didn't need) causes the COUNT() aggregate function to apply to all matching results before the LIMIT is applied. This kept me from having to do a separate query to get the total matches to be used for the pagination function.

dalecosp

Pretty cool, Nog. I don't think MySQL supports OVER() yet . . . if they're not careful, MS Windows will be releasing new features more often than they do ;-)

Derokorian

Mysql does support SQL_CALC_FOUND_ROWS, it does require a separate query to pull the count.

SELECT SQL_CALC_FOUND_ROWS username, role FROM users WHERE created_date < '2014-07-01' LIMIT 10;
SELECT FOUND_ROWS()

I have seen many blog posts claiming SQL_CALC_FOUND_ROWS is slower than a separate count() and I've seen many that are the reverse. It seems to depend on the situation.