Существует ли основное увеличение производительности при помощи хранимых процедур?
Если вам нужен Push только в одном месте и по какой-то причине описаны осложнения, я рекомендую следующее.
Установите ручной режим нажатия, то есть @Push(PushMode.MANUAL)
, а затем измените код следующим образом, то есть выполните ручное нажатие вместо автоматического включения.
class Loader implements Runnable {
@Override
public void run() {
try {
getUI().access(() -> {
getUI().getNavigator().navigateTo("scandataview/" + name);
getUI().push();
});
} catch (Exception e) {
e.printStackTrace();
}
}
}
Вышеуказанное использование access() может быть улучшено в соответствии с информацией, представленной в этом вопросе: Метод доступа из текущего пользовательского интерфейса в Vaadin
10 ответов
Первое, что нужно сделать является проверкой, база данных имеет все необходимые настроенные индексы. Проанализируйте, где Ваш код является медленным, и исследуйте соответствующие SQL-операторы и индексы, касающиеся их. Посмотрите, можно ли переписать SQL-оператор, чтобы быть более эффективными. Проверьте, что Вы не перекомпилировали (подготовленный) оператор SQL для каждого повторения в цикле вместо снаружи однажды.
Перемещение SQL-оператора в хранимую процедуру не собирается помогать, если это чрезвычайно неэффективно в реализации. Однако база данных будет знать, как лучше всего оптимизировать SQL, и это не должно будет неоднократно делать этого. Это может также заставить сторону клиента кодировать инструмент для очистки путем превращения сложного SQL-оператора в простой вызов процедуры.
Я бросил бы беглый взгляд на Хранимые процедуры, являются ЗЛЫМИ.
Пока Ваши вызовы последовательны, база данных сохранит план выполнения (MS SQL так или иначе). Самая сильная остающаяся причина использования хранимых процедур для легкого и верного управления безопасностью.
На вашем месте я сначала искал бы добавляющие индексы при необходимости. Также выполните профильный инструмент для исследования то, что занимает много времени и если этому sql нужно к измененному, например, добавляющий больше операторов Where или ограничивающий набор результатов.
Необходимо рассмотреть кэширование, где Вы можете.
хранимые процедуры могут быть действительно справкой, если они стараются не отправлять огромные объемы данных и/или стараются не делать распространения в прямом и обратном направлениях к серверу, таким образом, они могут быть ценными, если Ваше приложение имеет одну из этих проблем.
Хранимые процедуры не сделают вещи быстрее.
Однако реконструкция Вашей логики окажет огромное влияние. Опрятные, сфокусированные транзакции, которые Вы разрабатываете при размышлении о хранимых процедурах, чрезвычайно выгодны.
Кроме того, хранимые процедуры имеют тенденцию использовать, связывают переменные, где другие языки программирования иногда полагаются на создание SQL-операторов на лету. Маленький, фиксированный набор SQL-операторов и связывает переменные, быстро. Динамические SQL-операторы являются медленными.
Для приложения, которое "отстает в последнее время", не нужны изменения кодирования.
Мера. Мера. Мера. "медленный" не означает много когда дело доходит до настройки производительности. Что является медленным? Какая точная транзакция является медленной? Какая таблица является медленной? Фокус.
Управляйте всем изменением. Все. Что изменилось? Патч операционной системы? Изменение RDBMS? Изменение приложений? Что-то измененное для замедления вещей.
Проверьте на ограничения по своим масштабам. Таблица замедляется, потому что 80% данных являются историей, которую Вы используете для создания отчетов один раз в год?
Хранимые процедуры никогда не являются решением проблем производительности, пока Вы не можете абсолютно указать на определенный блок кода, который доказуемо быстрее как хранимая процедура.
После окончания исследования, Вы поймете, что существует два экстремальных представления в противоположной стороне спектра. Исторически сообщество Java было против хранилища procs из-за доступности платформ тех, которые в спящем режиме, с другой стороны сообщество.NET использовало более сохраненный procs, и это наследие идет до vb5/6 дней. Поместите всю эту информацию в контекст и держитесь подальше от экстремальных мнений по обе стороны от монеты.
Скорость не должна быть первичным фактором для отклонения или в пользу сохраненного procs. Можно достигнуть производительности SP с помощью встроенного SQL с, в спящем режиме и другие платформы. Рассмотрите обслуживание и который другие программы, такие как отчеты, сценарии могли использовать сохраненный procs того же, используемый Вашим приложением. Если Ваш сценарий требует нескольких потребителей для того же кода SQL, хранимые процедуры являются хорошим кандидатом, обслуживание будет легче. Если дело обстоит не так, и Вы решаете использовать встроенный sql, полагайте, что воплощение его в файлах конфигурации упрощает обслуживание.
В конце дня, какие количества - то, что сделает Ваш конкретный сценарий успехом для Ваших заинтересованных сторон.
Если Ваш сервер становится заметно медленнее в Вашу горячую пору, это может быть из-за насыщенности, а не чего-либо inefficent в базе данных. Основная теория массового обслуживания говорит нам, что сервер становится гиперболически медленнее, поскольку это приближается к насыщенности.
Основные отношения 1/(1-X) где X пропорция загрузки. Это описывает среднюю длину очереди или время для ожидания прежде чем быть подаваемым. Поэтому сервер, который становится влажным, замедлится очень быстро, когда загрузка пронзит.
Сервер, который составляет загруженных 25%, будет иметь среднее время обслуживания 1.333K для некоторого постоянного K (свободно, K является временем для машины для выполнения одной транзакции). Сервер, который составляет загруженных 50%, будет иметь среднее время обслуживания 2K и сервера, который составляет загруженных 90%, будет иметь среднее время обслуживания 10K. Учитывая, что замедление является гиперболическим по своей природе, это часто не вносит большое изменение в полной нагрузке для создания значительной неисправности в ответ время.
Очевидно, это несколько упрощенно, поскольку сервер будет обрабатывать несколько запросов одновременно (существуют более тщательно продуманные модели с очередями для этой ситуации), но широкий принцип все еще применяется.
Так, если Ваш сервер испытает переходные загрузки, которые насыщают его, то Вы испытаете патчи значимого замедления. Обратите внимание, что это замедление должно только быть в одной bottlenecked области системы для замедления целого процесса. Если Вы только испытываете это теперь в горячую пору существует возможность, что Ваш сервер просто поразил ограничение на ресурс, вместо того, чтобы быть особенно медленным или неэффективным.
Обратите внимание, что эта возможность не является противоположной возможности неэффективности в коде. Можно найти, что способ упростить узкое место состоит в том, чтобы настроить некоторые запросы.
Чтобы сказать, является ли система bottlenecked, начните собирать профильную информацию. Если можно найти, что ресурсы с большим количеством ожидают, это должно дать Вам хорошую начальную точку.
Заключительная возможность состоит в том, что необходимо обновить сервер. Если нет никакой главной неэффективности в коде (это могло бы хорошо иметь место, если профилирование не указывает ни на какие непропорционально большие узкие места), Вам, возможно, просто понадобятся более крупные аппаратные средства. Я понятия не имею, каковы Ваши объемы, но не обесценивают возможность, что Вы, возможно, переросли свой сервер.
Да, сохраненный procs является шагом вперед к достижению хорошей производительности. Главная причина состоит в том, что хранимые процедуры могут быть предварительно скомпилированы и их кэшируемый план выполнения.
Однако необходимо сначала проанализировать, где узкие места производительности действительно - так, чтобы Вы приблизились к этому осуществлению структурированным способом.
Как это было предположено в одном из ответов, попытка анализируют использование инструмента профилировщика, где проблема - например, сделайте необходимо создать индексы...
Удачи
Вы никогда не можете говорить заранее. Необходимо сделать это и измерить различие, потому что в 9 из 10 случаев, узкое место не то, где Вы думаете.
При использовании хранимой процедуры Вы не должны передавать данные. DBS является обычно медленным в выполняющемся [РЕДАКТИРОВАНИЕ] комплекс [/РЕДАКТИРОВАНИЕ] хранимые процедуры [РЕДАКТИРОВАНИЕ] с циклами, более высокой математикой, и т.д. [/РЕДАКТИРОВАНИЕ]. Таким образом, это действительно зависит от того, сколько работы необходимо было бы сделать, насколько медленный сеть, как быстро DB выполняет этот конкретный код и т.д.
Как все вышеупомянутые сообщения предлагают, Вы сначала хотите очистить свои SQL-операторы, иметь соответствующие индексы. кэширование может быть хитрым, я не могу прокомментировать, если у меня нет большего количества детали о том, что Вы пытаетесь выполнить.
Но одна вещь о sprocs, удостоверьтесь, что Вы не позволяете ему генерировать динамические SQL-операторы
потому что для одного, это будет бессмысленно, и это может быть подвергнуто Атакам с использованием кода на SQL... это произошло в одном из проектов, которые я изучил.
Я рекомендовал бы sprocs для обновлений главным образом и затем выбрал бы операторы. удача :)