Arman

1. Запросы или соединения?
2. Какие именно запросы на чтение или запись?
Запись - может много индексов?
Чтение - может данных много без индексов?
3. Смотрели скорость записи/чтения на диск?
4. Тормозят все запросы или в какую-то одну таблицу/таблицы? Может данных уже много?

1. Проверить бы кол-во соединений. Тип соединения (постоянный или нет)
2. Какие действия с базой? Записи в основном или чтение?
3. Проверить бы жесткий диск утилитами, когда идет долгий ответ. Может mysql уперся в скорость работы с диском

Я не дизайнер, но по-моему очень аккуратно и красиво.
Единственно некоторые фоновые картинки мешают читать контент (слишком яркие), все равно что у красиво одетой студентки принимать экзамен, ну или слушать лекцию от очень привлекательной дамы, кому как удобно. Сайты обычно источник информации, а потому уже красиво, веб 2.0 и юзабилити. Когда пользователь первый раз заходит, то весь дизайн плюс, когда следующий раз заходит, то его будет раздражать весь дизайн, если он не может найти что ищет или прочитать.

Регулярка просто описывает какую-то строку. Как для маленьких детей есть разные фигурки, их можно описать кол-во углов, цвета, размеры и т.д. Тут тоже самое, берем любую строку и описываем:
"123" - просто целое число в виде строки, можем описать как:
\d+ или [0-9] — целое число
[^a-zа-я] - строка которая не содержит букв (латиницы и кириллицы), тоже найдет эту строку
^\d+$ - начало строки/целое число/конец строки - если будет "123fbc" - то уже найдет
(?:1|5)23 - первый символ может быть 1 или 5
\d{3} - целое число от 100 до 999 (и 0nn),

лучше всего на примерах пробовать. Кучу таблиц есть с правилами. Нужно просто описать разные строки с помощью этой таблицы.

$('select').val().join(', '); // но надо проверить чтоб был массив

jsfiddle.net/c67m496e

Если закрепляете записи, то лучше использовать отдельное поле и желательно типа timestamp/datetime, тогда можно сортировать хоть как

ORDER BY `fixedAt` DESC, id DESC
ORDER BY `fixedAt` DESC, id ASC

Последняя закрепленная запись всегда вверху, остальные записи по вкусу.

1. На каждую категорию вы полностью прогоняете все сервисы, возможно их можно подготовить до категорий в виде ассоц массив. Или хотя бы unset() уже обработанных сервисов, если они не повторяются.
2. Используете свойства объекта, они существуют или доступ идет через магические методы? Может лучше явно создать методы ->get**() и получать данные через них? Магические методы хорошо тратят время/ресурсы.
3. Может результат просто положить в кэш?

SELECT
    a.*,
    c.*
FROM
    `images` AS a

JOIN
    `assoc` AS b
ON
    b.`imageId` = a.`id`

JOIN
    `objects` AS c
ON
    c.`id` = b.`objectId`

Примерно так должно быть, но не тестировал, нет таблиц живых

SELECT
    a.`user_id`,
    b.`user_name`,
    a.`date`,
    a.`value`
FROM
    `values` AS a
JOIN
    `users` AS b
ON
    b.`user_id` = a.`user_id`
WHERE
    a.`date` = "26.12.2014" 
    AND
    a.`value` >
        (
        SELECT
            c.`value`
        FROM
            `values` AS c
        WHERE
            c.`user_id` = a.`user_id`
            AND
            c.`date` = "25.12.2014"
        LIMIT 1
        )

Надо получить такой запрос:

INSERT INTO tbl_name (col1,col2) VALUES ($val1_1, $val1_2), ($val2_1, $val2_2), ...,($valN_1, $valN_2);

А цикл хотя бы так делать, если через foreach не получается/не нравится

// Сохранение данных в БД
for($a = 0, $b = count($metrika->data); $a < $b; $a++){
// ....
}

Қазақ тілі? =)
На первый вид не хватает LEFT JOIN и GROUP BY.
Оставьте почту или как с вами связаться, вместе может придумаем что нибудь

Если данных мало, то можно прям в разметке или подключаемом JS-скрипте, в котором массив с данными. Если данных много то лучше конечно БД, так как надо использовать поиск LIKE '%?%' или LIKE '?%'. Если нет возможности использовать БД, то надо самому читать файл и регуляркой находить совпадения, тоже реализуемо, но зачем мучать жесткий диск и свое время. Тем более если нужно будет использовать в других местах, а скорее всего большая часть данных у вас в БД, то уже у вас все будет готово, только таблицу поменять и поле, по которому идет поиск

Помню на старых телефонах была проблема с регистре

<form method="post" id="feedback-form">

Для трейтов пока рано, тем более yii 1 писали под 5.2 и неизвестно какой у вас стоит php.

Не очень yii знаю, но:
Можно сделать небольшой класс-помощник и вынести туда кишки ваших методов. Либо несколько таких помощников, если код можно разделить/сгруппировать по разным классам. Тогда класс User будет лишь переходником (так сказать роутером).

private $_helper;

    private function _getHelper()
        {
        if( !($this->_helper instanceof Helper_User) )
            {
            $this->_helper = new Helper_User();
            }

        return $this->_helper;
        }

    public function getData()
        {
        return $this->_getHelper()->getData();
        }

    public function setData($data)
        {
        return $this->_getHelper()->setData($data);
        }

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

А править демона можно?
Как вариант он может что-то писать в файл, допустим timestamp( 2014-01-01 00:00:01) по крону проверяете эту дату
Второй вариант демон блокирует какой-то файл на запись, если не ошибаюсь после любого завершения работы скрипта, php очищает память, рвет все соединения и разблокирует файлы. Получается когда файл будет доступен на запись значит демон больше мертв, чем жив.

По спецификации там могут быть только латинские буквы, цифры и пару символов

К сожалению не знаком с текущими плагинами, но может можно полям задать форму явно?
htmlbook.ru/html/input/form

Тогда все данные пойдут с нужной формой.