Вчера я опубликовал статью о том, как максимизировать производительность .NET. Было много комментариев. Некоторые из них указали на некоторые ошибки в статье. Я хотел бы поблагодарить тех, кто терпеливо писал комментарии. принесло много пользы.
Вчерашняя статья в основном была посвящена повышению скорости за счет некоторых деталей написания кода. Возможно, на самом деле ощутить улучшение производительности будет сложно, но как программист, постоянное улучшение качества вашего собственного кода — это цель, которую вы постоянно преследуете.
Фактически, с развитием аппаратного обеспечения скорость аппаратного обеспечения теперь далеко удовлетворяет потребности большинства людей. Некоторые даже предполагают, что алгоритмы становятся все менее и менее эффективными в современной разработке программного обеспечения. Я помню, как раньше смотрел видео о структуре данных из Массачусетского технологического института, и профессор, читавший лекцию, задал вопрос (точно не помню, но именно это он имел в виду): Раз алгоритмы больше не важны, почему мы все еще здесь? А как насчет исследований? Он ответил: «СКОРОСТЬ». Мы гонимся за скоростью, как гонщики гонятся за скоростью!
В настоящее время при разработке многих систем скорость не является главным приоритетом. Другие, такие как стабильность, безопасность, возможность повторного использования и т. д., часто имеют высший приоритет. В настоящее время шаблоны проектирования, архитектура разработки и т. д. в основном не предназначены для решения проблем производительности. Вышеупомянутое учитывается аналитиками и архитекторами. Мелкие программисты, такие как мы, могут оптимизировать программу только в некоторых небольших местах кода, классе, методе и строке кода. Я думаю, что полезно уделять больше внимания деталям.
Ладно, хватит чепухи, давайте поговорим о сегодняшней теме. Затраты на производительность многих сетевых систем, разрабатываемых сейчас, в основном связаны с чтением и передачей данных. Более высокая скорость чтения и меньшее использование полосы пропускания сети — вот цели, которые мы преследуем. Я расскажу о том, как улучшить производительность .net с этого аспекта.
1. Пейджинг данных на уровне данных. Его можно реализовать через ExcuteReader или хранимые процедуры. Способов много, поэтому не буду вдаваться в подробности (можете прочитать, что я написал)
2. Попробуйте использовать ExcuteReader для чтения данных у Microsoft. PetShop 4.0, все данные доступны. Все они реализованы с помощью ExcuteReader, если у вас нет особых требований к отключению (например, SmartClient и т. д.).
3. В ситуациях без подключения использование DataTable обеспечивает более высокую производительность, чем использование DataSet, если только вы не хотите сохранить несколько реляционных таблиц.
4. Используйте метод ImportRow DataTable.
В некоторых случаях необходимо скопировать большой объем данных из одного DataTable в другой. Использование метода ImportRow DataTable может значительно повысить производительность. При небольшом объеме данных разница невелика. достигает более 10 000 строк, его можно значительно улучшить и достичь в несколько раз.
5. Сериализируйте данные в двоичные файлы для облегчения передачи.
Когда мы обрабатываем объекты DataSet и DataTable, мы можем сериализовать их в файлы XML. Если они должны передаваться по сети, файлы XML вызовут проблемы с ресурсами, такими как память и пропускная способность сети. На данный момент мы можем сериализовать его в двоичный файл, чтобы генерируемые файлы были значительно уменьшены. Код выглядит следующим образом:
FileStream fs = новый fileStream(@"XMLData.bin", FileMode.Create);
BinaryFormatter bf = новый BinaryFormatter();
bf.Serialize(fs,XMLData);
фс.colse();
Созданный таким образом двоичный файл называется XMLBinary. Если вы откроете его напрямую с помощью WINHEX, вы увидите в нем некоторые теги XML. Если объем данных большой, добавьте строку кода:
XMLData.RemortingFormat = SerializationFormat.Binary;
Файл, созданный в это время, называется файлом TrueBinary. При обработке большого количества (более 10 000 строк) размер создаваемого файла составляет долю XMLBinary. Схема автоматически сохраняется во время сериализации, что упрощает процесс деупорядочения. Я пока не знаю, насколько сильно снизится производительность десериализации по сравнению с прямым чтением XML.
6. Разумно используйте пулы соединений.
Пул соединений играет важную роль в повышении производительности и включен по умолчанию. Минимальный размер пула по умолчанию равен 0, которому обычно присваивается относительно небольшое значение, например 5. Максимальный размер пула по умолчанию равен 100, что достаточно для большинства веб-сайтов. Для больших сайтов увеличьте его соответствующим образом.
7. Разработка с использованием SQLCLR
Если вы сосредоточены на изучении серии SQL Server, вам следует изучить SQLCLR. Он очень мощный и может повысить производительность во многих ситуациях (особенно в крупных приложениях корпоративного уровня).
8. Доступ к APP.Config/Web.Config через статические классы.
У нас есть много информации о конфигурации в APP.Config/Web.Config, к которой обращаются очень часто. На данный момент мы создаем статический класс. Доступ ко всем атрибутам осуществляется через статический класс, что может в определенной степени повысить производительность. Статический класс создает экземпляр Config только один раз, а APP.Config/Web.Config будет генерировать множество операций ввода-вывода.
общедоступный статический класс MyWebConfig
{
статический MyWebConfig()
{
КоннСтрока =
ConfigurationManager.ConnectionStrings["Соединение"].
Строка подключения;
}
общедоступная статическая строка DbConnectionString
{
получать
{
вернуть ConnString;
}
}
}
Хорошо, на сегодня это все. Я хотел бы указать на любые ошибки и недостатки. Вы можете высказать лучшее мнение и вместе добиться прогресса.