Подбор решения для сервера мобильного приложения

Каждый коннект к серверу от мобильного приложения означает один селект к базе по типу:

SELECT * FROM tbl WHERE par1=1 AND par2 IN ('1','2') ORDER BY par3 DESC LIMIT 10

построение на основе ответа json и отдачу обратно

верно но время выполнения запроса в веб части , его обработка и пересылка мобильному клиенту и в части приложение -> BD несоизмеримы.

для веба это десятые доли секунды для приложения->BD это единицы миллисекунд.

БД выполнила запрос отдала данные и занимается следующим а веб всё это время отдает мобильному приложению данные, именно медленная скорость передачи данных мобильному приложению и вызывает 10к коннектов одновременно.

team-voice, у ТС, на сколько я понял не "веб часть", а мобильное приложение. Исходя из этой информации, логично предположить, что запрос в бекенд будет не суммировать два числа, а работать с бд.

Но это не суть, суть в том, что с такими нагрузками которые предполагает ТС, технологии выбраны в корне не верно и сначала лучше разобраться с ними.

судя по описанию (php и Mysql) у ТС обыкновенные get/post запросы на веб сервер -> PHP -> MySQL

дай бог чтоб вебсервером был не apache с phpmod (да я совсем в крайности но не удивлюсь)

но в любом случае BD отработает задачу быстрее чем эти данные будут доставлены мобильному приложению.

но в целом php и именно MySQL это не лучшее что можно было выбрать,согласен.

Ответ каждому разный при этом или одинаковые?

Если второе, то что мешает использовать сокеты или memcache?

Если первое то зависит от скорости изменения и тоже можно кэш юзать снизив нагрузку на БД.

Сервер с 2xXeon E5-2623v3 тянул 30000 запросов к базе в секунду (15000 юзеров онлайн на сайте)

80% - SELECT

10% - Insert

10% - Update

OS: CentOS 7, php-fpm 7.1 + nginx, MariaDB 10.2.3

Добавив отдельный сервер под БД удалось достичь 30000-35000 юзеров онлайн на сайте. (Онлайн определялся по запросам за последние 15 секунд с постоянным обновлением), в среднем каждый юзер генерировал 1-2 запроса в секунду к скриптам сайта.

У нас был опыт подобных проектов с инсталом и сопровождением.

у нас это жило на двухпроцессорных Е5-2680V2 (суммарно 40 потоков с 2.8 гигагерц ) и база данных жила на nvme SSD

переваривало почти 60к запросов к БД (больше просто не было, железо могло и больше)

при этом после оптимизации самого продукта нагрузка резко упала.

Да, продукт был оптимизирован с учетом мемкеш и кеша БД + php был заменен на Python а БД с Mysql на MariaBD

nginx + php-fpm сейчас стоит + mariaDB. Интерфейс для работы с БД - PDO

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

накопители под BD - SSD ? серверные ? (это важно ибо бытовые ССД проседают под большим IOPS)

PHP 7+ ? (разница в скорости действительно большая)

(закрыв рукой лицо) php 5 ))))) и накопители вообще даже не SSD )

Вот поэтому я и создал эту тему - для поиска решения)

Если ваш текущий сервер справляется, то нагрузка не такая уж рваная, чтоб говорить о хайлоаде. В любом случае тут нужно проводить нагрузочное тестирование. Но у вас банально что-то с сервером произошло и "все пропало", он никак не дублирован. В облаке таки группа серверов, нагрузка между ними балансирует, а ввод вывод в каждый сервер от 10 до 20Gbit. Текущий ваш сервер вы не сможете отмасштабировать за минуту в два-три раза, а в облаке легко.

Ну, добавлю по накопителям, должны быть не просто SSD, а датацентровые, которые могут держать долго профиль нагрузки, отдавая стабильные iops с массива, а не пиковые, никому не нужные 500 или более мегабайт в сек.