Как улучшить мою скорость проекта программного обеспечения?

Разница в загрузке всего с удаленного сервера БД и загрузки всего с локального сервера БД заключается в задержке сети / размере канала. Сеть - это труба гораздо меньшего размера, чем что-либо еще. Два вопроса: во-первых, о каком объеме данных мы на самом деле говорим? Во-вторых, какова скорость вашей сети? 10/100/1000? Показатель от 10 до 20% размера вашего канала будет накладным из-за всего, от сетевых протоколов до самих запросов.

Как утверждали другие, способ, которым вы спроектировали, обычно занимает первое место в списке «не делать». При запуске извлекайте данные, достаточные только для инициализации приложения. По мере того, как пользователь работает над этим, извлекайте то, что вам нужно для этой задачи.

ЕДИНСТВЕННЫЙ раз, когда вы все тянете, - это когда они работают в отключенном состоянии. В этом случае вы по-прежнему не загружаете все как объекты в приложение, вы просто работаете из локального хранилища данных, которое время от времени синхронизируется с удаленным сервером.

Почему у вас нет двух отдельных потоков?

Поток 1 будет загружать ваши объекты один за другим. Поток 2 будет обрабатывать объекты по мере их загрузки.

Ваше приложение будет казаться более интерактивным при запуске.

Вы хотите сказать, что загружаете всю базу данных в память и затем манипулируете ею? Если это так, то почему бы вам вместо этого не использовать базу данных в качестве устройства хранения и выполнять поиск и манипуляции по мере необходимости (используя Hibernate, если хотите, или что-то другое, если не хотите)? Главное здесь - убедиться, что вы используете пул соединений, так как это уменьшит время соединения.

Если вы делаете именно это, то у вас могут возникнуть проблемы с памятью - во-первых, не кэшируя всю базу данных в памяти, вы уменьшите объем памяти и распределите нагрузку на сеть от начала/конца до времени, когда это необходимо.

1. Попробуйте минимизировать количество SQL-запросов, поскольку каждый запрос имеет свои собственные накладные расходы.
2. Вы можете включить сжатие базы данных, что должно ускорить работу при большом количестве данных.
3. Может быть, вы много раз подключаетесь к базе данных?
4. Проверьте время отклика на удаленный сервер базы данных - это может быть проблемой.

Проект практически завершен. Сейчас мы не можем делать большой рефакторинг. Я пытался использовать кэш второго уровня для Hibernate при сохранении. EhCacheProvider.

в hibernate.xml: net.sf.ehcache.hibernate.EhCacheProvider

я сделал конфиг для кэша, ehcache.xml:

я поместил cache.jar в путь сборки проекта и я установил свойство hibernate для каждого класса и установил в отображении. Но этот кэш, похоже, не имеет эффекта. Я не знаю, работает ли он (если он используется).

Некоторые другие вещи, которые вы можете изучить:

• Вы можете выделить больше памяти для JVM
• Используйте инструмент jconsole , чтобы исследовать узкие места.

Спасибо за ответы. Их было более чем полезно. Мы полностью решили эту проблему следующим образом:

Выполнен рефакторинг кода LOAD. Теперь он использует Hibernate с Lazy Fetching. Произведен рефакторинг кода SAVE. Теперь он сохраняет только те данные, которые были изменены, и сразу после того, как они были изменены. Таким образом, у нас не будет ОГРОМНОГО спасения до конца.

Я поражен тем, как все прошло хорошо. Количество нового кода, которое нам пришлось написать, было очень маленьким.

Эти два предложения являются для меня красными флажками:

Когда мы запускаем приложение, мы извлекаем вся информация из базы и превратить его в объекты для использования в нашем приложении (используя java sql государственники). В приложении редактируем некоторые из этих объектов, а затем, когда мы выйти из приложения, которое мы сохраняем или обновляем информация в базе данных с использованием Спящий режим.

Есть ли причина, по которой вы загружаете всю информацию из базы данных в память при запуске, или почему вы ждете завершения работы, чтобы сохранить изменения обратно в базу данных?

Если нет, я бы предложил изменить дизайн. Если у вас уже есть сопоставления Hibernate для таблиц в БД, я бы использовал Hibernate для всех ваших операций CRUD (создание, чтение, обновление, удаление). И я бы загружал только те данные, которые нужны каждой странице вашего приложения, по мере необходимости.

Если вы не можете внести такого рода изменения в проект на данном этапе, я думаю, вам следует внимательно присмотреться к тому, как вы управляете соединениями с базой данных. Вы используете пулы соединений? Вы открываете несколько подключений? Забываете их выпустить?

Есть еще кое-что, на что стоит взглянуть. Как вы используете Hibernate для сохранения объектов в БД? Вы выполняете getHibernateTemplate (). Get для каждого из них, а затем выполняете entity.save или entity.update для каждого из них? Если это так, это означает, что вы также заставляете Hibernate запускать запрос выбора для каждого объекта базы данных, прежде чем он выполнит сохранение или обновление. Таким образом, вы должны загружать каждый объект базы данных дважды (один раз в начале программы, один раз перед сохранением). Чтобы увидеть, что происходит, вы можете включить свойство show_sql или использовать P6Spy , чтобы точно узнать, какие запросы выполняет Hibernate.

Для того, что вы делаете, вам вполне может быть лучше сериализовать ваши объекты и записать их в плоский файл.

Но, что гораздо более вероятно, вам следует просто читать / обновлять объекты непосредственно из вашей базы данных по мере необходимости, а не все сразу, по всем причинам, указанным Аперкинсом.

Также подумайте, что произойдет, если ваше приложение выйдет из строя? Если все ваши обновления сохраняются только в памяти до закрытия приложения, все будет потеряно, если приложение неожиданно закроется.

Поскольку ваше приложение просто медленно работает на удаленном сервере базы данных, я предполагаю, что потеря производительности происходит из-за:

• Подключение к серверу: попробуйте повторно использовать соединения (передать экземпляр) или использовать соединение pooling
• Время приема-передачи запроса: используйте как можно меньше запросов, см. здесь в случае написанного от руки DAL: Предпочтительный способ получения строки с несколькими связанными строками

Для спящего режима вы можете использовать его пакетную функциональность и настроить hibernate.batch_size .

Во всех случаях, особенно когда вы не можете реорганизовать большие части кодовой базы, используйте профилировщик (время метода или запросы sql), чтобы найти узкое место. Бьюсь об заклад, вы найдете тысячи запросов, каждый из которых занимает 10 мс RTT), которые можно объединить в один.

Никогда не помешает пересмотреть основы:

Повышение скорости означает сокращение времени (очевидно), и для этого вы обнаружите, что действия, требующие значительного времени, но могут быть устранены или заменено чем-то, что требует меньше времени . Под действием я подразумеваю почти всегда вызов функции, вызов метода или вызов свойства, выполняемый в конкретной строке кода для определенной цели. If может вызывать ввод-вывод или вычисления, или и то, и другое. Если его назначение не является существенным, то его можно оптимизировать.

Многие люди используют профилировщики, чтобы попытаться найти эти отнимающие время строки кода, но большинство профилировщиков пропускают цель, потому что они смотрят на функции, а не на строки, они засыпают во время ввода-вывода и беспокоятся о «собственном времени». ".

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

Есть очень простой способ узнать наверняка, не догадываясь, что можно было бы оптимизировать, и вот один из способов сделать это на Java .