Имеется:
Social Engine 4.8.6. (небольшой набор плагинов).
VPS 2Ггц/2Гб ОЗУ.
Memcache | APC cache.
MariaDB
Первое, что предлагают для повышения производительности это включить кеширование, на деле кеширование(Memcache | APC cache) увеличило производительность раза в полтора и скрипт отрабатывает за 0.8 - 2 секунды, при 20-25 пользователей онлайн!!!(180 - 200 запросов к БД в секунду)
Что еще такого сотворить, чтоб хотя бы вдвое повысить производительность?
Да, спасибо. В дополнение скажу, что просто положить ключ в .ssh недостаточно. Нужно создать config в этой директории с параметрами, которые укажут какой ключ использовать для определенного хоста, пользователя(на сервере, из под которого подключаемся) и т.д.
Установлен GIT на сервере + gitosis, возможна авторизация по ключам. Но вот незадача не пойму к какому месту приложить private key в PHPStorm чтобы авторизоваться по ключу.
Работаю с API VK и столкнулся с проблемой, что по запросу групп пользователя (groups.get) группы возвращаются не все.
Даже если воспользоваться инструментом VK https://vk[dot]com/dev/groups[dot]get , то результат тот же, нет некоторых групп пользователя(ей), соответственно это исключает ошибки в моем коде.
Независимо, у пользователя 300 или 10 групп, будут недостающие.
Уже написал в поддержку VK по этому вопросу, но тикет уже очень долго висит в ожидании обработки.
Кто сталкивался? Может можно зайти "с тыла" воспользовавшись другими методами VK API, для получения нужных данных? Может знаете причины такого поведения, если это не банальная недоработка API? (Добавление)
Написал напрямую кодерам из команды VK, сказали, что проверят.
Чтоб и ничего не менять, не дублировать, и почти без запросов не выйдет. UPDATE всех потомков или на каждый запрос от пользователя делать N запросов на выборку.
Взять для примера nested sets, благодаря которому можно выдернуть одним запросом всех потомков, но в случае перемещения ветки или добавления могут быть обновлены абсолютно все записи.
Если хранить полные пути статей, составленные из алиасов категорий, то это огромное дублирование.
И что? Вы решитесь то ли идти более "нормализованным" путем и делать N запросов, или более "денормализованным" - получать избыточность и на N запросов меньше.
И вот я хочу переименовать "vasa" в "vasya". Итого мне нужно будет перебрать и обновить все 100 URI. Так нельзя.
Жесть) Волшебным образом задача не разрешится. Я полагаю, приоритет будет на чтение, чем на запись. Когда-никогда будет изменено название какого-то родителя - подумаешь обновить 100 записей...
Все прекрасно, если в таблице статей есть поле URI. Но такое поле иметь нельзя. В случае переименования категории, все данные в поле URI станут бесполезными.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 129
