Описание вашего блога

Начну с лирического вступления: раньше я был супер-перфекционистом, и пытался все сделать по максимуму круто и правильно, насколько на каждый конкретный момент хватало знаний и умений. Но через какое-то наконец пришло осознание того, что все сделать идеально нельзя, да и все равно потом оно перестанет казаться идеальным, ведь всегда можно что-то улучшить. Поэтому теперь я стараюсь фокусироваться на главном, а обо всякой хрени не думать вообще.

Приведу простой пример - нубы очень любят пофлеймить на тему того, как лучше делать конкатенацию строк - “маша $otshila васю” или “васе все равно “.$poh.” на Машу” и начинаются безумные холивары на тему производительности и так далее. А по большому счету - да какая хрен разница сгенерится страница на 5 миллисекунд быстрее или нет ? В общем надеюсь моя позиция по этому поводу ясна
Теперь перейдем к конкретике - волшебный проект gickr.com

Говорю сразу, код был написан не мной, а моим рыжим сотоварищем, и после просмотра кода этого самого товарища мне хотелось придушить Но код работал, гифки генерились, и это было самое главное! Жило все это добро на VPS от паршивой компании Dreamhost и в какой-то момент нам просто вырубили imagemagick с формулировкой “ребята, вы ЧО ! охренели создавать 100 процессов imagemagick и нагружать наш суперпупермегамногоядерный Xeon на 99%”. И вот тут-то и началась оптимизация.

Шаг номер 1 - Найди bottle neck (то бишь узкое место)

Главное выяснить что отжирает больше всего процессорного времени, это делается простыми засечками типа:

function CurTime() {
list($usec, $sec) = explode(' ', microtime());
$time2 = (double) $usec + (double) $sec;
if(!defined("__TIME__"))define("__TIME__", $time2);
$l = round($time2 - __TIME__, 6);
return $l;
}
CurTime();
тут куча кода ...
echo CurTime();


Шаг номер 2 - заоптимизируй это самое узкое место нахрен

В моем случае выяснилось две вещи:

1) Если ставить ватермарк на каждый кадр гифа, а потом уже собирать сам гиф, то это получается в 3 раза быстрее чем ставить ватермарк на уже готовый гиф! В общем если подумать почему так, то все становится ясно, ведь чтобы поставить ватермарк на готовый гиф, надо его опять разобрать на кадры, шлепнуть лого и собрать опять.

2) Если 500 человек захотят одновременно сделать большие гифы, то они все равно положат почти любой сервак.

Первая проблема решилась понятно как, а от второго была придумана совершенно тупая защита: я стал хранить текущие процессы по обработке в базе, и теперь разрешаю обрабатывать одновременно не больше 4 гифоф, а остальные идут в очередь, вот и вся история.

Шаг номер 3 - заоптимизируй все остальное если не в лом и делать нечего

Ну а тут открывается простор для полета фантазии и действий, можно бесконечно оптимизировать БД и запросы к ней, можно например поставить APC и кэшировать популярные запросы, можно вообще присобачить HTML кэш Помнится когда я сделал одну системку, на которой сейчас работает 49 мемберок одной известной в узких кругах партнерки, меня только HTML кэш и спас (и это все на кластере из 8 машин)

В общем тема оптимизации неисчерпаема, поэтому более конкретные вопросы жду в комментах, постараюсь на все ответить как могу.

P.S. Вообще, все ведь уже поняли что все самое интересное на этом блоге происходит именно в комментах ?