Yeah, I think anything's fine at the beginning. But as sites grow and
projects mature, you have to look at performance eventually :)
Just this month, I came across two sites with similar problems. Both the
sites would come to a halt, and mysql would sit on 390% cpu for hours. It
was fixed using 'mytop' to find the queries that were killing it, then a lot
of 'explain' (and trying to understand it's syntax) and eventually
re-writing of the queries and some indexing too.
The sites ran fine for years before this, but just the symptoms only hit
once the sites had gathered enough users (or usually when one's site appears
in slashdot or hackernews or something like that).
.....
Seeing as I'm in a reminiscing mind .. this old perl site I inherited was
super slow when showing lists of holidays you could book. It turned out
that:
1. There was no pagination, so it was trying to return 700+ rows on each
page
2. Whoever wrote the perl, thought it'd be fun to do 3 (yes three!) extra
separate SQL queries for EACH ROW returned by the main query
It became about 30x faster after changing it to a single query, using
explain and adding indexes where appropriate.
ok </reminiscing><back_to_work> ..
On Thu, Oct 20, 2011 at 7:17 PM, Pau Garcia i Quiles
<pgqui...@elpauer.org>wrote:
>
>
> On Thu, Oct 20, 2011 at 11:13 AM, Matthew Sherborne
> <msherbo...@gmail.com>wrote:
>
>>
>> In regards to the MySQL vs Postgres Holy war that some guy in this thread
>> started...
>>
>> Back in the 90's we had a project that was receiving around 1,000,000
>> insertions a week, and generating a lot of reports. Originally mysql, mysql
>> died (as in completely crashed) when trying to run reports (around the 8
>> million row time). We switched to MSSQL, which managed to crash the entire
>> machine it was hosted on when running reports. We tried Oracle, but cost
>> became prohibitive. System runs nicely with Postgresql, and last I checked
>> had like 160 million rows in the horriblest table (with cron jobs to do
>> hourly propogation of the records into summary tables).
>>
>>
> Oh well, if we are going to talk about performance, then I'd rather go for
> InterSystems Caché (which provides SQL and objects already, btw). The
> learning curve is very steep and it's proprietary, though.
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> witty-interest mailing list
> witty-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/witty-interest
>
>
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
witty-interest mailing list
witty-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/witty-interest
