[Expert] Embeed Speed for PHP&MySQL
Pseudonyme
Paris,
Le 20 Feb 2008,
Dear all,
Receiving too much non-qualified traffic : we must apply some advises
from PHP & MySQL experts.
Did you have the chance to embeed your server and apps to ensure the
good treatment of incoming connections ?
From your knowhow and scientific knowledge would you accept to give
some remarks or advises ?
[1] Use a profiler like XDebug to find bottlenecks in the code.
BOB To-do
[2] Check the DB to make sure your tables are properly indexed (you
can use EXPLAIN SELECT ... to get a query analysis).
BOB To-do
*[3] Don't use SELECT *, only fetch the data you really need.
BOB : What better ? to restrict on one column or by multiple columns
if applicable.
e.g : select email from T1 |or| select email with TLD column = COM
[4] Use prepared statements and re-use them if possible.
OK
*[5] Make your content cacheable by sending appropriate HTTP headers.
BOB : I did not understand "sending appropriate HTTP headers". Seems
to be quite smart, but I apologize I did not understand.
[6] Cache content on the server to avoid re-creation over and over
again, for example if you should create images on-the-fly.
OK
[7] Reduce the number of HTTP requests and roundtrips to the server.
OK + BOB To-do
*[8] Use HTTP compression for your text content (HTML, CSS, JS).
BOB : Is it compression as Mr Lemos (CPU impact) : (http://
www.phpclasses.org/blog/post/58-Responsive-AJAX-applications-with-COMET.html)
Or is it compression from the H.P. of that website http://www.gogole.com
that is 5 lines long !
*[9] Question : How Google gets a 5 line H.P.
If I view http://www.gogole.com home page, there are 5 lines. Is that
possible to make that ?
*[10] don't use images that are downloaded at a greater size than yu
need for display purposes, and i possible dont get thenm out of the
database at greater size than they need be.
BOB : OK, but our images are a big-big pb for the brandwidth
*[11] If on a Unix Linux platform examine page swapouts to see if you
are using more memory than you have allocated.
*[12] consider using a server like Zeus if you are seeing a huge
amount of httpd processes.Zeus - if its still around - was
multithreaded and used far less processor time/RAM to serve multiple
connections.
BOB : One of our server is not multi-thread. Hosting provider has
increased prices by 60% since last the 2 mergers.
http://www.valueweb.com/dedicated/dsLinux.htm
BOB to finance J.P. Morgan M&A consulting fees.
*[13] Use queue table (from phpclasses)
BOB : Ok but Is that possible to use web-compression for images ?
CPU ?
[14] Use different partition for Web, mail and database servers
[15] set query-cache-type = 1
OK
*[16] If you have queries which are repeated many times, you can cache
the query results in $_SESSION.
BOB : To do but have no idea how to develop this highly interesting
advice.
Please, I thank you very much for your advices.
Bob Cougloff
Ref : Group Experts Micha, Philosophe, + Sir Lemos + ....
(http://www.phpclasses.org/blog/post/66-More-defensive-programming-
practices-to-survive-Web-site-traffic-peaks.html)
C. (http://symcbean.blogspot.com/)
> Paris,
> Le 20 Feb 2008,
>
> Dear all,
>
> Receiving too much non-qualified traffic : we must apply some advises
> from PHP & MySQL experts.
>
> Did you have the chance to embeed your server and apps to ensure the
> good treatment of incoming connections ?
>
> From your knowhow and scientific knowledge would you accept to give
> some remarks or advises ?
Loks like this list has been pasted from other conversations outside
this thread (which is a little confusing)
I'd go with addressing these in this order (first one to be done
first) I'll assume you're currently running on Apache:
[15] set query-cache-type = 1
- its a no brainer
[8] Use HTTP compression for your text content
- again, its a no brainer and really does improve things
[5] Make your content cacheable by sending appropriate HTTP headers.
- but disable any condition parts of a request (if-modified-since /
if-none-match) - do-able via mod_headers in apache 2.0 or later (if
you're still on 1.3, upgrade now).
[no mentioned above] install a PHP cache
[11] If on a Unix Linux platform examine page swapouts to see if you
are using more memory than you have allocated.
- description is a load of %^&* but you should ensure you're not
running out of physical memory
[not mentioned above] check minservers, spare servers are sensible.
make sure keep-alives are enabled where possible (i.e. not for MSIE
over SSL) set the keep-alive time to something sensible (5 seconds at
most)
[14] Use different partition for Web, mail and database servers
- I have no idea what this means - are you taking about virtual server
partitions? Disk partitions? If the latter, the web root and database
files should be in their own partitions seperate from everything else
and mounted with noatime. You might want to consider what filesystem
you use for these too - any of the heavyweight FS for the DB (I'd go
with ext3) and reiser for the web.
[2] Check the DB to make sure your tables are properly indexed
- since you're using MySQL, setup the slow query log and use this to
prioritise what you need to fix.
These should give the most performance benefit. But it's difficult to
say when you haven't said where your bottlencks are (network/cpu/disk
I/O). Maybe you just need to add more servers - but again, without
knowing what you've got just now, its hard to give advice.
You seem to be a bit confused about what you are trying to achieve in
12. 16 is a bad idea - do the query caching on the DB.
C.
Rik Wasmus
<colin.m...@gmail.com> wrote:
> On 20 Feb, 18:13, Pseudonyme <norman_cougl...@2cuk.co.uk> wrote:
>> Paris,
>> Le 20 Feb 2008,
>>
>> Dear all,
>>
>> Receiving too much non-qualified traffic : we must apply some advises
>> from PHP & MySQL experts.
>>
>> Did you have the chance to embeed your server and apps to ensure the
>> good treatment of incoming connections ?
>>
>> From your knowhow and scientific knowledge would you accept to give
>> some remarks or advises ?
>
> Loks like this list has been pasted from other conversations outside
> this thread (which is a little confusing)
Actually, I assumed posting to usenet was a flaw (which is quite common to
see mostly in september on campuses all around, hell, I've done it once
way back :)), and the message was really meant only for the emailadress.
Maybe that was an incorrect assumption...
--
Rik Wasmus