muhasa

Python asyncio & aiohttp, также проверьте, не передаёт ли сайт данные по websocket (можно в браузере увидеть).

Подписался на вопрос, но точно скажу что:

1. null'и ненужные поля, они не занимают много места. Будет хлам в таблице, но если в коде разбить одну таблицу на несколько моделек - будет уже лучше и спокойней.
2. json - не очень вариант, только если как-то это абстрагируешь и будешь все из json'а пихать назад в аттрибуты, что бы с этим было удобно работать в коде. Но это тоже так себе вариант.
3. если использовать uuid и морф связи без foreign ключей - да, как вариант
4. не создавать профили кому не нужно и все)
5. нет, хрень. Даже хуже чем второй вариант.

В этом конкретном случае я бы выбирал между вариантами 1 и 3, ибо привязывать примитивку "специализация" к какому-то отдельному энтити - такое себе удовольствие. 1-ый не такой плохой как кажется, а с третим теоретически сложнее работать, хотя это неплохая идея.

4 вариант из предложенных больше всех напрашивается.
Но есть ещё 6 вариант более интересный, но более сложный, создать 2 таблицы
Таблица attributes
id
name
role_id

Таблица attribute_values
attribute_id
user_id
value

емнип в ларавеле уже есть готовый RBAC. Или можно открутить от симфони/зенда.
По теме - естественно никаких дополнительных сущностей корме юзера не нужно, они отличаются только связанным свойством роли.

Роли - это множества (точнее - "деревья" множеств), содержащие пользователей.

Расписываю подробно на примере:
Есть пользователь User1, у него роль Admin и роль Curator.
Т.е. он имеет в своём личном кабинете 2 пункта меню: Администрирование и Курирование.
Всё что в базе - привязывается только через ID-шник этого пользователя (роли и поля ролей, и т.п.).

По идее пользователи - отдельно, роли - отдельно.
И один пользователь может иметь несколько ролей, т.е. между пользователями и ролями д.б. таблица связи.
И связи один ко многим.

Итого имеем три таблицы: пользователи, роли, связи.

Как вариант - не пускать их на сервер вовсе.
Настроить выгрузку проектов через GitLab, например, и уже его средствами разруливать доступ.

Что вы называете "танцами с бубном"?
Я бы сделал по группе на каждый проект и указал их группами владельцев каталогов соответствующих проектов. Потом, по необходимости, добавлял пользователей в эти группы

Apache Bench, например.

https://ruhighload.com/%D0%A2%D0%B5%D1%81%D1%82%D0...

Боюсь что даже при наличии подобных инструментов тесты будут очень относительными. Совершенно не факт, что на сервере N1 во время ваших не будет испытывать пиковую нагрузку, а сервер N2 в это время будет размещен на вновь введёной в эксплуатацию машине и по тому будет просто "летать".

но еще и панель управления в придачу.

Панель обычно неплохо так потребляет ресурсы, особенно если это задохный VPS с 1-м виртуальным процессором и 0.5-1Гб памяти.

который оказался слабее, еще установили OPCache, xDebug (не запускается при каждом запросе)

OPCache если мне памяти не изменяет давно уже ставиться вместе с PHP по умолчанию. А вот установленный XDebug на боевоем сервере... боюсь даже представить, что употребляет автор подобных решений.

Я Вам из личного опыта скажу, был один такой хороший хостер X, среди прочего они позволяли устанавливать на сервер ОС из собственного образа, что лично меня безумно радовало. Но, в один прекрасный день, поднимая очередную ноду для нужд проекта, я вдруг заметил, что система ставится неприлично долго. Начал "ковырять" и заметил, что скорость записи на диск, на всех моих VPS'ках в среднем составляла 5КБайт/сек.!! 5 килобайт! А потом она вообще упала до 1Кб в среднем, а потом весь ДЦ видимо рухнул... Благо я вовремя успел заметить проблему и быстренько перевёз прокты в другое место.

Я всё это к тому, что Ваш разовый замер ничего не даст, кроме как показателей чего-то на уровне "сейчас".

А вот теперь самое интересное: Как считается скорость?) Может просто один из серверов дальше и дело просто в доставке трафика?

А про VDS: клиенту он действительно нужен? то есть у него требования к железу по безопасности? если нет то VPS и вперед (разницы ощутимой не будет, но дешевле)

у нас куртки преимущественно

вы сами себе голову морочите.

Представим, что в заказе 3 товара размерами - 10*10*10, 20*20*20 и 30*30*30

Не надо ничего представлять, верхняя одежда вообще в одном типоразмере упаковки уходит, вбивайте один размер коробки и вся недолга. Я 25 лет одежду торгую...

Или подсмотрите как в деловых линиях идет подсчет, когда добавляешь второй груз- как сказали выше тупо коэффициент и все!

А задачка по оптимальному размещению разных коробок на самом деле пздц как сложная, ваш сервер будет 24 часа в сутки только и заниматься оптимальной расстановкой этих ваших коробок...
Чем меньше свободы покупателю, тем быстрее от него бабло прилетает...