mysql

Forcing a Mysql slave to delay seconds or minutes behind a master can be useful for many reasons:

- test your application to see how it reacts in case of a lagged replication
- release financial data after a period of validation
- build some sort of wayback machine
- protect against oops
etc.

So you’re running dedicated MySQL Linux box with plenty of memory, now the good question arises: should you have swap file enabled or disabled ? I’ve seen production successfully running on boxes both with and without swap file so it is not the question of you must do it this or that way but rather understanding advantages of both approaches in your environment.

There are many things you can do to speed up your website. This article focuses on practical things that I used, without any spending money on additional hardware or commercial software.

http://tr.im/xs6y

  • Cache PHP output
  • Create turbo charged storage
  • Leave heavy processing to cronjobs
  • Optimize your database
  • Save some bandwidth
  • Store PHP sessions in your database

About PHP sessions and DB usage I would like to add something: do not use them unless you really need them! Start php sessions and open db connections when needed. Do not put them in the boostrap/frontend file.
HTTP is stateless, try to keep your site/application the same, it makes caching and load balancing a lot easier.
In some context, site content related to user sessions can be loaded using ajax. And DB data can be cached into memcache.

You may also consider stracing your web processes to optimize disk usage. E.g. your Apache could be configured to look for index.html and index.htm everytime the homepage is called. See DirectoryIndex.

The Google Perftools, especially tcmalloc (Thread Caching Malloc), can be very useful to speed up your applications, depending on your environment :

TCMalloc is faster than the glibc 2.3 malloc (available as a separate library called ptmalloc2) and other mallocs that I have tested. ptmalloc2 takes approximately 300 nanoseconds to execute a malloc/free pair on a 2.8 GHz P4 (for small objects). The TCMalloc implementation takes approximately 50 nanoseconds for the same operation pair.

A vulnerability estimated to affect more than 1 in 10 websites could go lethal with the finding that it can be used to reliably take complete control of the site's underlying server.

This article is going to take a look at a rather nasty low-level hardware bug which could bite people writing applications which are multi-threaded. The bug manifests itself in MySQL as we’ll see a bit later.

Syndicate content
© 2012 Devis Lucato @itbus.