> 10-20 раз
Типа с 1мкс до 20мкс?
По идее, на маленьких запросах это будет не очень большая задержка, а на большихибудет вообще не заметно.
Как вы замеряли производительность?
> большую часть времени идёт подключение к БД.
Соединения нужно переиспользовать и как можно дольше не закрывать.
beem7, если вы в заказной разработке, то видимо проблема в менеджере, который наобещал какой-то срок на основе ваших же рассказов о том, сколько вам нужно времени
Северное Сияние, ну раз обновления гробят индустрию - почему тогда все не пишут на том же коболе, например? Вот уж язык не обременённый новыми версиями
beem7, ну это ж абстрактный пример, камон. Просто придумал абстрактную блокирующую задачу, без которой нельзя продолжать работу.
Ну и блокеры могут не только между команд возникать, но и между отдельными разработчиками.
beem7, а они не могут. Те задачи переложили на другой срок/другие команды. И они не могут делать ничего другого кроме как сидеть и чаи пить.
А документация не готова вообще ни в каком виде.
Ну и военный сектор - не армия и вообще пример абстрактный.
Во всех этих проектах не было надобности в жестких дедлайнах.
Это только так кажется. Я же уже третий раз повторяю - это нужно для планирования. Без планирования ты не можешь нормально распределить ресурсы.
Вот на примере того же танка - пусть есть разработчики какой-нибудь системы наведения башни (я не специалист в танках) и есть разработчики самой башни.
Разработчики башни заявили "мы разработаем спецификацию API управления башней в сроку X"
Менеджер проекта берёт этот срок и планирует "так. Значит до срока X пусть разработчики системы наведения делают что-то ещё, а потом они должны освободиться и сесть изучать спецификацию"
В итоге к сроку X разработчики башни ещё нифига не сделали. А у разработчиков системы наведения работы нет - в итоге команда простаивает, а простой = траты денег.
Если бы разработчики башни заранее предупредили МП о задержке - простой, возможно, удалось бы минимизировать.
https://instantview.telegram.org/