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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Рекомендации по быстрому созданию веб-страниц от команды Yahoo!, работающей исключительно эффективно

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Как я уже сказал в еще один вопрос:

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

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

Answer 6

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

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

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