synapse_people: объем памяти регулируется через файловый кеш системы
Его можно и нужно увеличить чтобы файловая система кешировала обращения сфинкса.
Что касается агентов, то вы их настраиваете в
index index_main
{
type = distributed
Проблема в том что у вас их очень много и производительности они не увеличивают. Более того начинают конкурировать за ресурс и снижают ее.
Раз сервер локальный, то можете поменять диски на несколько SSD (2-4 - сколько получится) и свести их в рейд-массив типа 0
Или же просто хранить индексы каждый на своем диске задавая пути в конфиге
Родион Юрченко: Сменить тип базы.
Т.е. показания между поездками пишите в редис, потом агрегируйте уже в MySQL. Скажем раз в сутки/двое
В итоге в БД у вас будет только одна запись на поездку.
Причем БД с историей можно хранить на другой машине вовсе.
Или вам нужна история координат машины недельной и месячной давности?
Т.е. техдира нет. Целесообразность затрат у вас получается никто не считал.
В таком случае рекомендую PHP с любым из микрофреймворков (Zend Expressive как пример).
Можно было бы взять Symfony, но ее лучше дождаться 4й версии и после этого подождать еще полгодика. Т.е. не раньше мая следующего года.
Реализацию проводить как API приложение. В этом случае вам достаточно легко можно будет навесить различные фронтенды будь-то html+js традиционный, модные нынче SPA на Angular, React, Vue, или же вообще мобильные приложения.
Кроме всего прочего в команду вам обязателен специалист, который работал с интернет-магазинами. В качестве ли product owner, или же просто business-analyst
Где-то месяца через полтора-два разработки (в зависимости от количества разработчиков) можете начинать писать фронт к своему магазину.
Остальные технологии:
MySQL (можно PostgreSQL, но специалистов искать будет сложнее).
Nginx
php-fpm
memcache
redis
rabbit-mq
Полнотекст можете сделать или на ElasticSearch или на SphinxSearch
Что касатеся мобильного приложения, то лучше его начать разрабатывать по факту наличия работающего магазина.
У вас к этому моменту будет какая-никакая статистика устройств с которых посещают магазин и совершают покупки
Соответственно вы сможете определиться, что делать в первую очередь Android или iOS приложение.
Ну и для облегчения разработки самих приложений ваш магазин изначально может проектироваться как система API.
Если у вас только джависты, то писать на пхп будет крайне глупо.
Если вы планируете долговременную поддержку, то нужно ориентироваться на TCO в тех или иных технологиях.
Что включает в себя сроки разработки, цену разработчиков, цену обслуживания за время жизни, цену оборудования.
Для разных технологий цифры будут различаться.
Но в целом сейчас PHP выигрывает по этим параметрам у большинства языков. Т.е. достаточно много достаточно дешевых и при этом терпимо квалифицированных разработчиков. Главное тут не пытаться нанять совсем дешевый персонал.
Стоимость железа для средней руки магазина будет в разы дешевле затрат на команду разработчиков.
Тут опять же стоит учитывать объем функционала, требуемые интеграции и т.п.
P.S. Я вам так корректно намекну, что все вышесказанное это экспертиза тех.дира или директора по ай-ти.
И, да, основной принцип почему рекомендуется опираться на интерфейсы - это то, что они не зависят от конкретной реализации. Т.е. производить подмену достаточно легко.
В вашем случае особых проблем не будет, если базовый классы не содержат слишком уж экзотическое поведение и сайд-эффекты не описанные в их сигнатурах методов
Нет.
Поясню. У вас сейчас уже задействованы все ядра ибо 120 шард
Но это многовато для 8 ядер.
synapse_people: ставьте 4 штуки SSD и будет вам 900