У меня небольшая база данных (<1G), но у нас много сложной логики на сайте, и клиент жалуется на время рендеринга, которое составляет 3-5 секунд. Мы не Google, и тысячи пользователей в день — наша мечта, поэтому размер не проблема, а вот скорость важна. Может кто-нибудь поделиться опытом работы с SSD-дисками для приложений на базе ASP.NET (MVC)/LINQ/MS SQL? Как увеличилась производительность?
ОБНОВЛЕНИЕ: в этом документе указано, что скорость будет в 20 раз выше. http://www.texmemsys.com/files/f000174.pdf
решение1
Я бы добавил свой комментарий к предыдущему ответу, но у меня недостаточно репутации... так что вот...
Купите больше оперативной памяти. Намного больше оперативной памяти. Если у вас 4 ГБ, перейдите на 16 ГБ или 32 ГБ. Даже 32 ГБ или ОЗУ, скорее всего, будут дешевле, чем ХОРОШИЙ SSD. Большинство SSD-накопителей не лучше жестких дисков, за исключением дорогих дисков Intel (есть и другие SSD, которые еще быстрее, но они намного дороже).
Если ваша база данных всего 1 ГБ, SQL Server будет кэшировать почти все в памяти, если вы добавите достаточно памяти. Единственное исключение — если ваш процесс записывает много данных. Если у вас есть 1000 транзакций INSERT, которые должны произойти для каждого действия пользователя, много памяти не поможет, и тогда SSD-диск МОЖЕТ быть полезен... но я подозреваю, что это не так. В любой операции чтения память всегда улучшит производительность гораздо больше, чем жесткие диски.
решение2
Вы действительно отследили, в чем заключается ваша проблема? В запросе к базе данных? В обработке запроса на стороне сервера? В рендеринге контента? В передаче рендерингового контента? Есть много областей, которые могут стать узким местом производительности многоуровневого веб-приложения, и чтобы добиться какого-либо значимого улучшения производительности, вам нужно проанализировать, что именно замедляет работу.
решение3
Не очень хорошо могу ответить на свой вопрос, но...
У меня есть два крупных проекта, над которыми я работаю. Оба используют MS SQL / LINQ / ASP.NET. Один из них старый и имеет очень нормализованную структуру таблиц. Это означает, что для отображения информации об одной бизнес-сущности я считываю, вероятно, из 5-6 связанных таблиц.
Другой — более новый и имеет более высокие требования к производительности. Он также использует LINQ. В рамках текущей архитектуры мне пришлось искать 1 дополнительную запись на каждый результат поиска.
С SSD: 1-й проект. Улучшение общей загрузки страницы на 30-50%. Так что, действительно, это как-то полезно. 2-й проект. Улучшение общей загрузки страницы на 10-20%. Разница почти минимальна. Однако у меня возникло ощущение, что в этом случае система более готова справляться со стрессом и случайными чтениями.
Подводя итог, если для вашего размера SSD стоит около 2-3 человеко-дней, я бы рекомендовал его использовать, но не ожидайте больших улучшений.
решение4
Оценили ли вы ваши фактические запросы по вашей базе данных? Ваша производительность должна быть лучше, чем вы видите.