Centos5.5 Nginx 0.8.33 + PHP5.3.1(fpm) + MySQL5.5.0(phpmyadmin)

Недавно мой знакомый купил ВПС, и конечно же ему захотелось развернуть полноценный сервер, плюс учитывая начальные ресурсы: 768Мб памяти и 2 ядра выделеных на его контейнер, сервер должен быть не прожорливым и быстрым, на нем будет крутиться blog. Решил поставить nginx, и php+php-fpm. Думаю nginx описывать не буду, как и php+php-fpm обзоры можно найти на хабре. Вот только вся соль проблемы в том, что он хотел поставить все правильно, как в учебнике. Заглянул по форумам, перегуглил весь интернет, но так и не нашел правильного пацанского мануала. Везде только основные моменты настроек и установки сервера. Так не пойдет, сказал он и пришел ко мне. Одна голова хорошо, но пиво в двоем пить лучше!
Стали составлять план, что нам нужно для работы.

! Данный пост предназначен только для начинающих, для тех кто не имеет опыта в установке и настройке сервера. Вам будет понятно на примере что и где и как установить, и потом углубившись в мануалы и вооружившись напильником, сделать все конкретно под ваши задачи.
Как минимум для начала работы нужно:
Putty — the.earth.li/~sgtatham/putty/latest/x86/putty.exe — SSH client

Centos 5.5 — последяя будет уже стоять на серваке.
Nginx 0.8.33 — можно выбрать и старший релиз или стабильный.
PHP 5.3.1 — думаю проблем с ней не будет.
MySQL 5.5.0 — база!
php-fpm патч
suhosin-patch
libevent-1.4.13-stable

и далее все остальные пакеты которые понадобятся для компиляции и работы сервера:
gcc gcc-c++ libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel curl curl-devel e2fsprogs e2fsprogs-devel krb5 krb5-devel libidn libidn-devel openssl openssl-devel openldap openldap-devel nss_ldap openldap-clients openldap-servers libmcrypt libmcrypt-devel pcre-devel

Продолжению быть!
Часть 1

---

Задачи поставлены, и вроде бы самое время перейти к чтению различных обзоров и тестов, но…
С чего начать? В какую сторону вообще смотреть?

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

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

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

Фреймворк Twitter Bootstrap уже давно стал одним из самых любимых средств ленивых сторонников быстрого прототипирования и разработки интерфейсов, а где популярность там много разных сторонних интересных штук.
На этот раз я случайно попал на пополняющуюся коллекцию сниппетов.
Думаю многим пригодится, сейчас там набор небольшой (23 штуки), но уже достаточно полезный чтобы поделиться.
Кликабельные картинки:

Интерфейс аля gmail

В процессе создания своей радиостанции поток идей дошел до ведения эфиров через веб-интерфейс. Сначала пытался найти готовые решения, но в рунете почти ничего не нашел. Начал продумывать способ реализации и чудом наткнулся на статью в английской версии Википедии про Airtime (до 18 января 2011 г. – Campcaster) от Sourcefabric.

Возможности Airtime:

• Создание эфирной сетки и плейлистов через веб-интерфейс ;
• Загрузка музыки через браузер (поддержка drag and drop);
• Регистрация ведущих, которые имеют доступ к админке и могут управлять эфирами;
• Создание виджетов с расписанием эфиров и треков для сторонних сайтов;
• Возможность записывать эфиры для повторной трансляции;
• Несколько вариантов трансляции аудиопотока.

Минимальные системные требования, описанные в официальной инструкции: 1Ghz процессор и 512Mb оперативной памяти.

Привет, Хабр!
Вчера, во время обсуждения www.i-gorod.com, возникла мысль собрать команду с целью создания социально-значимого и эффективного ресурса.
Так вот, идея получила развитие, и нашлись люди, серьезно настроенные её реализовать.
Мы не только воплотим что-то хорошее (нужное), но и продемонстрируем, что в России можно создавать полезные веб-инструменты с разумными затратами.

Текущие участники:
estronas, zaisl, humbug, maxyc, artamonovg, mikenerevarin, putnik, andryx, barmaley13, lukaville, wo1fer, logan, kuzemchik, teplenew, bestfriend;

Люди, от которых мы ждем ответа в личку:
xni, ur001, nshopik, devart, darbin, lomalkin;

Наши ближайшие планы:
— формирование команды;
— выбор лучшей идеи будущего сервиса;
— разработка коммуникационной составляющей проекта;

Будем рады ваших комментариям и идеям по развитию.

Кто хочет присоединиться к проекту — пишите!

Вслед за Ораклом со своим ‘connet by prior ‘ все остальные СУБД вводят свои реализации иерархических запросов (ИЗ). Хотелось бы рассказать широкой аудитории как это сделано в PostgreSQL.

На работе в новом проекте используется СУБД PostgreSQL. Так как до сих пор я работал с MySQL, сейчас приходится изучать и открывать для себя Постгри. Первая проблема, которая меня заинтересовала — замена мускулевского SQL_CALC_FOUND_ROWS. При использовании этой константы в MySQL можно получить количество всех найденных по запросу записей, даже если запрос с limit'ом — это незаменимо при постраничном выводе поисковых результатов, когда используются «тяжелые» запросы.
Сходу готового решения найти не удалось. На форумах просто констатировали, что SQL_CALC_FOUND_ROWS в Постгри нет. Некоторые писали, что надо юзать count(*). И больше никакой информации. Но еще из MySQL мне было известно, что поиск с count()-запросом работает почти в 2 раза медленнее, чем с SQL_CALC_FOUND_ROWS. Я консультировался у тех, кто пользуется PostgreSQL, день мучал google и в результате получил 4 варианта замены SQL_CALC_FOUND_ROWS в PostgreSQL, один из которых вполне приемлимый по скорости.

Недавно у меня возникла интересная задача по хранению некоторых данных в рамках сессии работы с БД PostgreSQL (TTL = время жизни единичного коннекта к базе). Изначальный вопрос был таков…
А можно ли вместо вот такой конструкции:

some_procedure1(user_id, param1, ... , paramN);
...
some_procedureX(user_id, param1, ... , paramN);

использовать такую:

set_user(id);
some_procedure1(param1, ... , paramN);
....
some_procedureX(param1, ... , paramN);

т.е. использовать некую глобальную переменную в рамках сессии для хранения значение идентификатора пользователя, которое будет доступно всем процедурам внутри базы.
Порывшись в гугле, поспрашивав на форуме, я нашел даже не одно решение, а целых 3! Чем с вами и делюсь…

Предмет описываемой проблемы

При работе с базой данных в PostgreSQL необходимо не забывать, в какой локали (locale) был инициализирован кластер БД — так в постгре называется директория (обычно /var/lib/pgsql/data), в которой хранятся данные всех баз этой установки PostgreSQL.

В MySQL можно делать INSERT… ON DUPLICATE KEY UDPATE. В постгресе пока что такого нет (насколько мне известно, MERGE не вошел в версию 8.4).

Я натыкался в сети на рекомендацию использовать правила для того чтобы добиться аналогичного поведения. Мне показалось, что использовать правила в данном случае даже лучше, нежели MERGE, я сделал правило… и наткнулся на подводный камень. Я реализовывал счетчик: есть уникальный ключ и, если такой ключ в таблице уже существует при вставке новой записи — следует вместо этого увеличить значение счетчика.

Простая ситуация, простое правило. Но: при первой вставке это правило, как оказалось, тоже отрабатывает! В результате, при первой вставке вставляется не 1, а 2!

Пока писал, Fred84 подкинул ссылку, где об этой ситуации подробнее рассказано: archives.postgresql.org/pgsql-bugs/2007-03/msg00080.php

Каким бы супер-пупер спецом вы не были — в процессе разработки эпизодически попадаются интересные и удобные вещи о которых, казалось бы, давно бы пора знать, но все никак не складывалось. Этакий ништячок, найдя который хочется воскликнуть: «Эврика!». Вот таким ништячком для меня стал элемент синтаксиса INSERT в PostgreSQL, которым я и хочу поделиться с вами.

Ситуация: После добавления записи в базу нужно получить id этой самой свеже-вставленной записи.
Решение на PostgreSQL: INSERT… RETURNING id где id — это PRIMARY_KEY в таблице.

Просто и элегантно, не правда ли?