Да. Процессора уже давно хватает. Сейчас основной упор наблюдается в память и ввод-вывод на диск. Добавление памяти и SSD всегда неплохо ускоряет систему.
Если у вас fpm вылетает очень быстро с opcache это говорит что вы выделили php слишком много ресурсов одних ресурсов при недостаче других. У вас много процессора и мало памяти. Отключением opcache вы снижаете быстродействие ПО и раз при этом работает, то это говорит, что ваши лимиты сильно больше того что может прожевать сервер и вы упираетесь в память. Нельзя бездумно увеличивать количество процессов. Использование fpm как раз позволяет избегать такой ситуации и контролировать ее. Так что вам бы я посоветовал уменьшить количество процессов в двое и при помощи бинарного поиска найти оптимальное их число. Насчет же fcgi разница есть. Фишка в том что в случае php-fpm у вас запуск процесса происходит ОДИН раз. При запуске php-fpm. В случае mod_fcgi и аналогах если нет запросов происходит прибивание процесса php и при новом обращениии идет запуск. Никогда не забывайте что современные процессоры имеют большую пропускную способность чем память и сильно большую пропускную способность чем система ввода-вывода. Я помнится один раз уже правил систему после такого бездумного увеличения. В итоге после того как был найден баланс между количеством процессов и возможностью системы она начала работать заметно быстрее.
Dmitry: проще тюнить и смотреть что произошло. Если у вас при высокой нагрузке падает php-fpm то нужно оптимизировать скрипты плюс включить кеширование. Хотя думаю кеширование на php включено. Проблема в том что fcgi модуль который вы используете, сам запускает php-fpm и это происходит довольно бесконтрольно. Так-как запуском и установкой управляет apache.
mukeb: включите дебаг в браузере плюс посмотрите tcpdump на наличие rtp и корректности выбора портов. Дополнительно проверьте браузер на демо freeswitch.
Армянское Радио: да обычным клиентом на тот же вызов звук есть. С точки зрения asterisk все с соединением в порядке ulaw идет. Замена asterisk на webrtc2sip дает ровно тот же результат. Пока у меня складывается ощущение что есть какие-то проблемы с srtp, но проблема в том что ни та ни другая сторона про это ничего не говорят.
Отдельные таблички под свойства / одна таблица, отображение списка продуктов: количество джойнов = количеству свойств
Эм вы точно все верно читали? Там три таблицы. Товар, атрибут и его значение. Таблица атрибутов и таблица значений одна. Далее просто есть связка где указан товар, какой атрибут и тип значения. Так что если вы не будете разворачивать товар как плоскую таблицу вида
название товара, значение свойства а, значение свойства б
то будет два join
Поиск в этом случае лучше делать через spinnx или тому подобное ориентированное на поиск документов и представлять каждый товар с его свойствами как документ.
