Какие стратегии вы использовали для повышения производительности веб-приложений? [закрыто]

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

Моя команда разработчиков работает над веб-приложением (отчеты JSP, HTML, JavaScript), которое использует базу данных Oracle (PL / SQL). Основные функциональные возможности, которые предоставляет приложение, - это создание отчетов, где пользователь может получать PDF-отчеты с высоким уровнем детализации и переходить к более низким уровням вспомогательных деталей.

По мере того, как количество вспомогательных подробных записей выросло до миллионов, производительность системы значительно снизилась. Основываясь на нашем текущем анализе метрик, узкое место, похоже, заключается в логике поражения БД и производительности БД. Изменение модели БД и повторное выполнение некоторой логики на стороне сервера в настоящее время изучается.

Разделение, индексация, объяснение планов и запуск статистики - это то, что было сделано на стороне БД, чтобы попытаться улучшить производительность. Хотя они помогли, они не решили проблему удовлетворительно. Самым сложным в анализе данных о производительности является то, что база данных и веб-серверы управляются удаленно другой частью ИТ-организации, поэтому разработчики не имеют регулярного полного доступа для просмотра происходящего (особенно в производственной среде, которая точно не отражается ни в какой другой среде разработки / тестирования).

22.08.2008 15:48:44
6 ОТВЕТОВ
РЕШЕНИЕ

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

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

6
22.08.2008 15:58:41

Рассматривали ли вы создание ваших данных раньше времени? Другими словами, есть ли группы данных, которые запрашиваются снова и снова? Если это так, подготовьте их, прежде чем пользователь спросит. Я не совсем говорю о кешировании, но думаю, что это часть уравнения.

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

2
20.12.2016 07:26:53

Как говорит Вебджеди, метрики - это ваш друг.

Также посмотрите на свой стек и посмотрите, где есть возможности для кеширования, а затем применяйте беспощадно везде, где это возможно!

1
22.08.2008 16:04:00

Как я сказал в другом вопросе :

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

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

1
23.05.2017 12:13:54

Не все профилировщики стоят (лишних) денег. Для .Net я успешно использую старую сборку NProf (в настоящее время заброшенную, но она все еще работает для меня) для профилирования моих приложений ASP.Net. Для SQL Server профилировщик запросов является частью пакета. Есть также CLF Profiler от MS, но я так и не смог заставить его работать успешно.

Это, как говорится, профилировщики, безусловно, путь. Таким образом, вы сможете увидеть, где ваша программа проводит большую часть своего времени, и не сосредоточиться на вещах, которые, по вашему мнению, медленны. Кроме того, это означает, что вам не нужно ничего писать в своем коде, чтобы фактически записать метрики.

Как я уже говорил в начале, существуют разные типы профилировщиков. Три из них, которые я считаю наиболее полезными, - это профилировщики приложений, которые позволяют увидеть, какие функции вы на самом деле проводите большую часть своего времени. Второй - это профилировщики SQL, которые позволяют увидеть, сколько времени занимает выполнение ваших запросов. Третий - профилировщики памяти, которые помогают показать, какими объектами используется ваша память. Все три из них действительно полезны, и хотя вы не будете использовать их каждый день, время их использования избавит вас от головной боли.

1
22.08.2008 16:24:59

Вы проверили это?

Лучшие практики для быстрого создания веб-страниц от команды исключительной производительности Yahoo !.

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

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

2
22.08.2008 16:41:31