David_Wimbley
Как я уже упоминал в ваших предыдущих репостах. Вы не дали нам достаточно информации, чтобы помочь вам.
Кажется, что вы вызываете 1 хранимую процедуру 3000 раз или вызываете 3000 хранимых процедур одновременно. В любом случае это безумие.
Ваша проблема связана не с инфраструктурой, а с дизайном. Вам нужно переосмыслить дизайн того, чего вы пытаетесь достичь, а не просто тратить больше денег на проблему с точки зрения оборудования/ресурсов.
Помните, что у нас нет доступа к вашему жесткому диску, вашему коду, мы не читаем мысли и ничего не знаем о вашем проекте. Вы изложили свою проблему так, как будто мы обладаем глубокими знаниями о вашей проблеме/проекте и ожидаем, что кто-то предложит содержательные предложения. Пока вы не сделаете шаг назад и не поймете, что вам, вероятно, нужно переосмыслить свою ИП, вы будете постоянно сталкиваться с этой проблемой
AbassiOmar
спасибо за ответ
Я объясняю свою проблему
У меня есть одна хранимая процедура, которая будет выполнять веб-api
но у меня есть 3000 клиентов, которые будут потреблять API web одновременно
время выполнения моей хранимой процедуры составляет примерно 1 секунду
Так что у меня была проблема масштабируемости
так что мой вопрос заключается в следующем-что это есть решение для 3000 миль, называемое в некотором роде quee
или если есть кто-то, кто работал над этой проблемой раньше
сердечно
спасибо
David_Wimbley
Таким образом, в настоящее время вы запускаете 3000 хранимых процедур по 1 секунде каждая последовательно. То есть один за другим. Это в общей сложности около 50 минут обработки. Неудивительно, что у вас тайм-аут.
Я действительно думаю, что вам нужно переосмыслить то, что вы делаете, но давайте попробуем решить проблему с 3000 SP.
Таким образом, у вас есть несколько вариантов, но позже вы столкнетесь с проблемами масштаба, игнорирование проблемы не заставит ее исчезнуть, поскольку вы просто даете ей больше пространства для роста, добавляя инфраструктуру.
1) Вы можете использовать архитектуру pub/sub (event driven), где в любое время, когда клиенту нужно выполнить SP, они публикуют, чтобы сказать ... redis...а затем подписчик redis затем действует на это опубликованное уведомление
2) балансировка нагрузки/переосмысление вашего SP в определенной степени - вместо того, чтобы быть номером 2898 в строке...попросите клиента выполнить СП по требованию. Таким образом, вместо выполнения 1 хранимой процедуры 3000 раз в одном запросе. Вы выполняете его, потенциально, 1 раз, но вашему серверу, возможно, придется обрабатывать 3000 запросов, что не должно быть таким уж большим делом.
3) Поставьте задания в очередь в планировщике и запустите через оконную службу или что-то в этом роде.
4) Если вы все еще настаиваете на запуске одной хранимой процедуры 3000 раз, то посмотрите на mulit-threading/Tasks. Существует множество документации по этому вопросу, так что простой поиск в google предоставит вам массу примеров.
Нет 100% правильного решения вашей проблемы, так как вам нужно решить, что лучше всего соответствует вашим потребностям.