Списки SharePoint по сравнению с производительностью Таблиц базы данных
Спецификация TCP говорит, что соединения идентифицируются кортежем:
{local addr, local port, remote addr, remote port}
Исходя из этого, теоретически не должно быть конфликта между локальным портом, используемым в существующем соединении, и попыткой связать это. тот же порт для прослушивания сервером, поскольку прослушивающий сокет не имеет удаленного адреса / порта (они представлены в спецификации подстановочными знаками).
Однако, большинство реализаций TCP, включая API сокетов Unix, являются более строгими, чем эта. Если локальный порт уже используется в каком-либо существующем сокете, вы не сможете связать его, вы получите ошибку EADDRINUSE. Специальное исключение делается, если все существующие сокеты находятся в состоянии TIME_WAIT, а новый сокет имеет опцию сокета SO_REUSEADDR; это используется для перезапуска сервера, пока сокеты, оставшиеся от предыдущего процесса, все еще ожидают истечения времени ожидания.
По этой причине диапазон портов обычно делится на диапазоны с различным использованием. Когда сокет не связывает локальный порт (либо потому, что он просто вызвал connect() без вызова bind(), либо путем указания IPPORT_ANY в качестве порта в bind()), порт выбирается из эфемерного диапазон, который обычно очень пронумерован портами. С другой стороны, ожидается, что серверы будут привязаны к портам с низким номером. Если сетевые приложения следуют этому соглашению, вы не должны сталкиваться с конфликтами.
8 ответов
Не делайте этого. SharePoint не хорош в обработке данных транзакций и будет работать плохо.
Любые способности Вам, возможно, придется улучшить производительность на уровне базы данных (как добавление индексов) могут иметь вредные эффекты на установку SharePoint (хотя столбцы в списках могут быть "индексированы" через SharePoint.
По существу SharePoint разработан для определенной цели (содержание/документы) и пытающийся заставить это делать, что-то необычное означает, что необходимо бороться с приложением изо всех сил.
К счастью, SharePoint имеет несколько средств интеграции данных транзакций в него.
Прежде всего (если у Вас есть более дорогая Корпоративная лицензия) у Вас есть Каталог Бизнес-данных, который позволяет Вам импортировать значения базы данных, которые будут казаться подобными элементам списка.
Если у Вас нет Корпоративной лицензии, я могу рекомендовать или пользовательскому controls/webparts или веб-Части Представления данных признать что данные быть "показанным" на соответствующих страницах в SharePoint.
Таким образом: Вы будете собираться для большой работы uneccesary, храня данные транзакций в SharePoint по сравнению с другой разработкой приложений, размещающей данные в традиционных приложениях базы данных и интегрирующейся к SharePoint.
Я соглашаюсь со всеми вышеупомянутыми комментариями. У меня был обширный опыт с клиентами, которые хотели использовать списки SharePoint для вещей, где они не соответствовали. Если Вы волнуетесь по поводу производительности вообще, то списки SharePoint не являются способом пойти. Если это просто в архивных целях, и Вы делаете нечастые поиски против данных, и функции поиска SharePoint достаточны для Вас, я мог бы рассмотреть это и не отклонить его без обсуждения (если Вы используете MOSS).
Но я рассмотрел бы все аспекты этого тщательно. Это не слишком трудно через Данные, Являются веб-Частями и BDC для получения данных SQL-сервера в среду SharePoint, но более трудно получить данные SharePoint в другие платформы или приложения.
И снова, если производительность является во всем требованием, то не делают этого.
Для большего количества масштабируемости SharePoint и информации о лучшей практике производительности см.: http://technet.microsoft.com/en-us/library/cc287790.aspx
Списки SharePoint будут медленнее.
Больше служебное = худшая производительность.
Эмпирическое правило состоит в том, чтобы ограничить списки SharePoint 2 000 объектов по причинам производительности.
В 100k производительность пошла бы "от, сосут для выдувания".
Единственный способ, которым это могло работать, состоит в том, если Вы могли бы сегментировать набор данных на несколько списков с меньше, чем 2000 в каждом.
Я также соглашаюсь с парнями выше Однако - много проблем производительности, обсужденных в блогах, - то, вследствие того, что Объектная модель SharePoint не используется правильно.
Вы можете контроль мой ряд блога о Производительности Списка SharePoint на Блоге dynaTrace. Этот ряд изучает Объектную модель SharePoint для выделения то, что на самом деле продолжается между Серверами SharePoint и Базой данных Содержания
+1 Нет
SharePoint, прежде всего, функционирует, сотрудничество. В Вашем случае Вы просто перечислите данные как только для чтения. В Вашей ситуации я рекомендовал бы хранить данные в SQL DB, если необходимо отобразить его на портале SharePoint, можно использовать BDC или что-то как Бамбуковая веб-часть Представления данных. http://store.bamboosolutions.com/p-71-data-viewer-web-part.aspx
Of course, the proposed approach is not recommended.
But, being in the subject, here is a good doc for large lists perf in WSS
Сделав это сам, я бы посоветовал по возможности избегать этого! Это минное поле, особенно после примерно 100 000 строк.
Что-то, что может в конечном итоге укусить вас, - это то, что поисковый сканер может начать тайм-аут, пытаясь сканировать действительно большие списки - вы можете увеличить тайм-аут, но это начало проигравшей битвы.