Дмитрий Масленников

Появилась документация по Streaming API:

https://vk.com/dev/streaming_api_docs

Но там реально жесть, в базовой версии максимальное количество запросов (правил), по которым поступают данные = 10 штук, в ответе выдается 1% от всей доступной информации (говоря русским языком не выдается практически ничего)).

Да, тут поможет AJAX. На клиенте делаем:

$.post('/call.php', { data: data }, function(result) {
   // json
   result = JSON.parse(result);
   // actions
});

И в серверной части (например, на PHP)

if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
   // vars
   $data = isset($_POST['data']) ? flt_input($_POST['data']) : NULL;
   // actions
   $result = some_function($data);
   // output
   echo json_encode($result, true);
   exit();
}

Конечно, есть более сложные и интересные способы на основе COMET-технологии (те же WebSockets), но для начала стоит освоить AJAX.

Выяснилось, что проблема была в отсутствии папки, в которой запускался PID-файл с Munin. Проблему решил создав папку /run/munin и назначив ей пользователя/права Munin.

Проблема с запуском Munin оказалась в кроне (а не в статусе masked как я подумал ранее), через crontab отредактировал задачу для Munin:

*/5 * * * * /usr/bin/munin-cron > /dev/null 2>&1

Как оказалось, в этой проблеме было целых 2 нюанса:

- первый заключался в адресе обращения к wss (спасибо Дмитрий Беляев)
- второй в том, что необходимо было убрать из настроек подключения "requestCert: true" (спасибо @andreyma со stackoverflow).

Итоговый код. На вход идет дата в формате '0000-00-00 00:00:00', на выходе количество полных лет с текущей даты:

function age_count(date) {
    // now
    var now = new Date();
    now.setMinutes(now.getMinutes() - now.getTimezoneOffset());
    now = now.toISOString().substr(0, 19).replace('T',' ');
    // calculate
    var age = now.substr(0, 4) - date.substr(0, 4);
    if(now.substr(5) < date.substr(5)) --age;
    // output
    return age;
}

P.S. Если кто знает, как более кратко привести текущую дату к формату '0000-00-00 00:00:00' - просьба написать в комментариях.

Официальный ответ от службы техподдержки Яндекса:

Цвет активной вкладки определяется автоматически его виджетом. Если у сайта есть свой логотип для виджета на странице Табло, то оформление вкладки будет ему соответствовать.

Как сделать виджет, Вы можете прочитать здесь: https://tech.yandex.ru/browser/tableau/doc/dg/conc...

Если виджета у сайта нет, в этом случае цвет вкладки будет взят из фавиконки сайта.

P.S. От себя добавлю, что в ходе экспериментов выяснилось, что цвет фона в большинстве случаев берется из первого заполненного верхнего правого пикселя иконки и делается на несколько тонов темнее. В ряде случаев цвет формируется по другим алгоритмам (в частности, для очень светлых или очень темных иконок, а также для изображений с сочетанием разных цветов).

К сожалению, на практике Яндекс.Браузер работает с виджетом не совсем корректно, новые открываемые страницы красятся по цвету иконки сайта, а при манипуляциях с history браузера (ajax и т.д.) цвет берется из параметра "color" (цвет логотипа виджета не влияет на окрашивание). Будем надеяться, что в новых версиях браузера все будет работать правильно.

Добиться более плавной анимации помог комплекс следующих действий:

1. Точное указание property у transition (т.е. вместо "transition: all" указываем конкретное свойство с которым производится анимация).
2. Использование при JS манипуляции с классами не classList, а className. Переход на это решение позволил добиться реального прогресса в плавности анимации. В частности, это решение подсказал VK, там используется такая же схема. Метод className входит в DOM Core (level 2), имеет практически полную совместимость со всеми браузерами, а также более эффективно обрабатывается браузерными движками с минимальными задержками.

В итоге пришел к решению на уровне логики приложения. В основной базе постоянно содержится 0.5-1 млн наиболее свежих записей, а остальные выносятся в архивную. Скрипт-архиватор раз в сутки переносит старые записи в архив. Первоначально пользователям выдаются только наиболее свежие данные из основной базы (99% запросов), а если их недостаточно, то производится поиск в архивной.

P.S. В дополнение, если пользователь начал листать ленту - сделал вывод не 10, а 50 записей. При скроллинге клиент 1 раз выдает данные из запроса, а остальные 4 пакета помещает в массив и выдает по мере необходимости. Когда данные клиента заканчиваются, делается новый запрос. Сразу 50 не вывожу, чтобы не тормозить браузер (там много графики). Что-то подобное встречается в vk и ряде других крупных сайтов.

P.P.S. Итоговое решение на уровне MySQL получилось следующим. Провел вручную тестирование с выборками на основе жестко прописанного (use index) простого или составного индекса. Наилучшим по производительности оказалось использование составного индекса (например, (type, update)), использование которого жестко прописано в коде приложения в зависимости от конкретного типа выборки (по-умолчанию, в ряде случает MySQL выбирает не самый производительный индекс). Удивило расхождение данных, выдаваемых EXPLAIN с реальными показателями производительности. Так, простой индекс (EXPLAIN показывает rows 10) работал в сотни раз медленнее составного с rows в несколько млн. записей.

P.P.P.S. В общем, проблема была в неправильном выборе движком MySQL индекса по которому проводился поиск (в некоторых случаях использовался только простой индекс, когда лучше было использовать составной, а в некоторых поиск проводился сразу по 2-м индексам с объединением результатов). При прописывании USE INDEX вручную (на каждый конкретный случай) производительность многократно возросла.