Сегодня я разговаривал с друзьями из группы MSN об оптимизации производительности программ ASP.net.
Теперь подведем итоги методов оптимизации:
1. Оптимизация базы данных, включая оптимизацию структуры таблиц, оптимизацию индексов, оптимизацию операторов SQL и оптимизацию хранимых процедур.
2. Оптимизируйте ViewState
3. Используйте кеширование
4. Создание статических страниц (в основном для внешнего интерфейса систем публикации информации, которые не очень интерактивны)
5. Используйте интерфейсный IIS/Apache для обработки запросов статических страниц, изображений и файлов js.
6. Алгоритм оптимизации
7. Каждый может добавить
. Что касается настройки производительности, практически все эксперты советуют: если нет точных измерений производительности, не выполняйте настройку производительности. Настройка без эталонного тестирования производительности, по сути, не принесет никаких других преимуществ, кроме запутывания системного кода. Эффект, который вы получите, усердно работая над улучшением алгоритма с 0,1 секунды до 0,01 секунды, часто будет потерян из-за неправильного оператора выбора.
Поэтому предыдущие способы не панацея. Для настройки нужно сначала понять, где система тормозит. Никогда не обращайтесь за медицинской помощью в спешке. Следующий контент взят из моего личного опыта работы, не все системы можно применять, помните! ! ! !
Давайте проанализируем эти четыре метода настройки:
Для приложений типа OA/системы управления бизнесом оптимизация базы данных часто является ключевым моментом по нескольким причинам:
1.CRUD в базе данных — наиболее распространенная операция в этих системах.
2. Операции в системе базы данных часто вызывают дисковый ввод-вывод (поскольку файлы базы данных и журналы сохраняются на диске).
3. Операции приложения в системе базы данных часто выполняются между процессами или даже между компьютерами. (Дисковый ввод-вывод + сетевой ввод-вывод, независимо от того, насколько быстр процессор или сколько памяти, это вне нашей досягаемости)
Таким образом, эти операции с базой данных часто являются узким местом производительности всей системы.
Итак, зная это общее направление, как узнать, какие SQL или хранимые процедуры работают медленно? Для этого необходимо объединить профилировщик базы данных.
Для SQL Server вы можете прочитать эту статью.
http://www.microsoft.com/china/msdn/library/data/sqlserver/Profiler.mspx?mfr=true
Для Oracle вы можете прочитать эту статью
http://www.javaeye.com/post/117389
2. ViewState, этот Dongdong относительно велик по размеру и окажет определенное влияние на интернет-приложения. По поводу его оптимизации в саду уже говорили, так что можете поискать сами.
3. Моё мнение по поводу использования кэша не очень совпадает с мнением нескольких друзей из группы MSN. Друг из группы MSN считает, что кэш может представлять собой набор статических переменных или некоторых переменных, управляемых контроллером кэша. Лично я считаю, что такой кеш может иметь хорошую производительность в среде с одним сервером. В среде с несколькими серверами такой кеш станет узким местом производительности, поскольку приложению или контроллеру кеша необходимо тщательно обеспечивать содержимое кеша нескольких процессов. . последовательный. Этот процесс значительно снижает масштабируемость программы. Рассмотрим веб-ферму со 100 серверами. Изменение кэша в одном процессе требует уведомления и подтверждения того, что остальные 99 серверов были изменены правильно. Это ужасная вещь.
Для этого относительно хорошим решением является memcache. Знаменитый вики-продукт mediawiki использует его в качестве кэш-сервера. Memcache также имеет клиентский API .net.
4. Не очень в этом разбираюсь, дайте пожалуйста совет знатоков
. 5. В интернете много вступлений, особенно по Java. Есть много вступлений по apache с tomcat. Погуглите сами.
6. Эта оптимизация самая сложная, и эффект может быть наименее очевидным. Если вам необходимо это сделать, позвольте восьми бессмертным пересечь море и показать свои магические силы.
http://www.cnblogs.com/ncindy/archive/2006/11/07/553533.html