GoldenLine
Zaloguj się

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Witam, chciałbym usłyszeć wasze zdanie na temat poniższych zarzutów, ograniczeń SharePoint jako rozwiązania klasy ECM:

1. Wydajność podczas magazynowania dużej ilości danych.
2. Stabilność systemu przy obsłudze dużej ilości danych.
3. Ograniczenia złożonych procesów workflow.
4. Brak narzędzi graficznych do procesów workflow, modyfikacji, testów.
5. Ograniczenia modyfikacji platformy przez biznes.
6. Ograniczone i mało przejrzyste mechanizmy wyszukiwania.
7. Związanie się z pojedynczym dostawcą oferującym produkty SharePoint w przypadku innego kodu (narzędzi) poprawiających wady 3-6.

Szukam obiektywnej oceny i chciałbym się dowiedzieć co o tym myślicie. Mam podzielone zdanie ale potrzebuje więcej argumentów za lub przeciw, oraz opinie bardziej doświadczonych ludzi siedzących w temacie Shareponita.

Pozdrawiam RobertRobert Krzysztof W. edytował(a) ten post dnia 17.01.11 o godzinie 10:49
Link do wypowiedziLink
Łukasz B.

Łukasz B. Starszy Specjalista
ds. Architektury
Procesów,
Telekomuni...

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Z moje doświadczenia:

1. Do 50 GB działa sprawnie, powyżej widać spadek wydajności
2. Nie widziałem problemu
3. Złożone procesy trzeba developować w Sharepoint Designer
4. Jest możliwość dokupienia zew. modułu do SP w celu graficznego modelowania. (niestety nie pamietam teraz nazwy)
5. zależy na cyzm Ci zależy
6. mało przejrzyste owszem, jednak jeżeli chodzi o wyszukiwanie to przeszukuje też wew. plików.
7. Chyba o tym samym dostawcy mówimy :)
Link do wypowiedziLink

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Łukasz B.:
Z moje doświadczenia:

1. Do 50 GB działa sprawnie, powyżej widać spadek wydajności

Jak mocno spada?, jak sobie radzi z indeksowaniem SQL, ponoć daje rade z bazami danych powyżej 100 GB a widzę że w praktyce nie jest tak różowo. Zawsze można utworzyć bazę danych dla poszczególnych aplikacji / zbioru witryn, tylko czy to ma sens. Czy problem występuje też w 2010 ?.

Pozdrawiam RobertRobert Krzysztof W. edytował(a) ten post dnia 17.01.11 o godzinie 11:58
Link do wypowiedziLink
Maciej Raczyński

Maciej Raczyński .NET Senior
Developer
(Consultant)

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Odnośnie 1. i 2.: Co rozumiesz jako duży zbiór danych? Nie ma uniwersalnego środowiska i konfiguracji sprzętowej. Wszystko opiera się na prawidłowej fazie planowania możliwości farmy (w tym przyrostu danych i obciążenia). Dopiero później dobiera się topologię i sprzęt. Przy takim podejściu, są małe szanse, by system działał źle przy ilościach danych rzędu ~700 GB (z takimi największymi pracowałem). I przy 10 GB może wszystko działać źle. Wielką zaletą SP jest jego skalowalność na wydajność i redundancję, lecz trzeba o tym myśleć zanim się zainstaluje i zacznie używać.

3. Zależy co rozumiesz jako proces złożony, ale w uogólnieniu. Zależnie od poziomu komplikacji wspomniany już SPD, potem rozwiązania firm trzecich (Workbox, Nintex, K2,a nawet Visio 2010 - też zależnie od potrzeb), kończąc na w pełni autorskich rozwiązaniach opartych o WorkFlow Foundation i pisanych z użyciem Visual Studio.

4. Tu jest jak wyżej - są narzędzia różnego poziomu funkcjonalności i kosztu. Rozwiązania firm trzecich oferują wiele mechanizmów śledzenia wykonania. W przypadku WF autorskiego, to już zależy od twórcy :)

5. Każde narzędzie ma swoje ograniczenia. Coś konkretnego, czego się obawiasz?

6. Tu generalnie wiele zależy od potrzeb - SharePoint nie będzie googlem. Bardzo dużo można uzyskać OOTB, ale trzeba mieć dokładnie sprecyzowane wymagania. Tu wszystko rozbija się o poprawną wstępną klasyfikację i zastosowaną taksonomię. Bardzo wiele pozornych ograniczeń systemu wyszukiwania jest do obejścia jeśli dobrze zna się system. Wracając do pkt 1 i 2 to 300 tyś. elementów może być indeksowane 200h, lub 10, lub 5 minut. Wyniki wyszukiwania moga być zwrócone w 1 sekundę i w 20 sekund.

7. To dotyczy każdego systemu informatycznego. Funkcjonowanie w sytuacji posiadania wielu dostawców sprzętu i oprogramowania nie powinno być w dzisiejszym przedsiębiorstwem problemem. Z mojego punktu widzenia winę ponoszą raczej odbiorcy, którzy nie egzekwują i spychają na drugi plan tematykę utrzymania standardów prawidłowej dokumentacji wdrożeniowej i projektowej. Utrzymanie rozwiązania autorskiego przez wielu dostawców jest możliwe.

Znam technologię od wielu lat i widzę to tak. Wokół tej platformy funkcjonują dziesiątki mitów pozytywnych i negatywnych. Te drugie powstają w przypadku, gdy SP jest używany nieprawidłowo, lub nie do tego, do czego go stworzono. SP jest systemem informatycznym i ma zakres zastosowań, ma mechanizmy rozszerzalności i ograniczenia.

Pozdrawiam
MR
Link do wypowiedziLink
Łukasz B.

Łukasz B. Starszy Specjalista
ds. Architektury
Procesów,
Telekomuni...

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Robert, tutaj chyba dokładniej odpowiedział Maciek. Wszystko zależy od odpowiedniego startu, czyli jak wszystko ustawisz na samym początku i jeżeli źle to zostanie przemyślane to później są problemy z wydajnością o których pisałem.
Link do wypowiedziLink

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Dzięki za info ja chciałem się upewnić jak to jest, mam do czynienia z działającym Sharepointem, a ostatnio są jakieś plany na temat wdrożenia nowych rzeczy, tylko nie chcę być jak chorągiewka na wietrze, i chciałem znać innych zdanie. Właśnie to mi się podoba że Sharepoint może pracować w farmie, można rozwiązania-funkcjonalności skalować. Są wady i zalety jak w każdym oprogramowaniu.

Sharepointa 2007 mamy wdrożonego, więc tutaj by się człowiek skupił nad rozszerzeniem istniejącej farmy - zmiany też na poziomie sprzętowym, oraz wykorzystaniu oprogramowania - funkcjonalności firm trzecich. Co do 7 pytania chodziło o kod który jest wdrożony jako funkcjonalność w Sharepoincie a nie jest kodem Microsoftu, tylko napisany przez inna firmę. Chodzi przedewszystkim o system obiegu dokumentów, zostało jeszcze zaproponowane rozwiązanie droższe - system IBM FileNet, tylko czy to ma sens.Robert Krzysztof W. edytował(a) ten post dnia 18.01.11 o godzinie 09:33
Link do wypowiedziLink
Maciej Raczyński

Maciej Raczyński .NET Senior
Developer
(Consultant)

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Nie jestem zwolennikiem mierzenia podobnych aplikacji syntetycznie, porównując jedną z drugą, gdyż wtedy gubi się cały kontekst konkretnych potrzeb i środowiska w jakim ma rozwiązanie działać. Nie wydaje mi się, by dało się arbitralnie stwierdzić, która jest lepsza. W każdym razie ja tego nie umiem.

Lepiej opierać się na konkretnych przesłankach. Np. wymogach wydajnościowych, funkcjonalnych, kosztowych, czasowych, utrzymania itp.

Mówiąc o technologii SharePoint mówimy o serii produktów rozwijanych już ponad 10 lat z głównym przeznaczeniem dla kolaboracji o obsługi dokumentów, więc myślę, że się nadaje ;)

Jeśli masz jakieś pytania jeszcze, to bardzo chętnie odpowiem, jeśli będę wiedział.
Link do wypowiedziLink

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Witam

Właściwie na wszystkie pytania autora wątku najlepiej odpowiedział Maciej, ja dodam parę zalet SP:

1. SP jest bardzo popularny, co się przekłada na łatwość znalezienia inżynierów i firm do współpracy w zakresie rozwoju systemu. W przeciwieństwie do wielu innych dostawców nie wiążemy się z jedną firmą na dobre i na złe. Kupujemy licencje od Microsoftu (a właściwie to bardzo dużo można osiągnąć na bezpłatnym WSS lub SPF) i potem możemy zlecać poszczególne prace podwykonawcom. Znam firmy w których wewnętrzny zespół robi to co umie a dodatkowo zamawia usługi w kilku firmach współpracujących. Jeśli jest obawa przed uzależnieniem się od jednego podwykonawcy to jest to problem handlowo-prawny a nie techniczny. Ja swoim klientom przedstawiam możliwość korzystania z wielu podwykonawców jako jedną z ważniejszych zalet tej platformy.

2. SP jest elastyczny w rozbudowie. Bardzo dużo można osiągnąć bez programowania. Dodatkowo można dopisać w .Net to czego nie da się wyklikać w SP Designer. Łatwo go rozwijać reagując na potrzeby biznesowe i (zaleta) userzy raczej sami nie będą w tym systemie nic rozwijać więc nie trzeba po nich sprzątać. Człowiek z IT bez problemy stworzy odpowiedni workflow lub witrynę jak mu biznesiaki dokładnie powiedzą co ma zrobić. Można łatwo sięgać do innych systemów i pobierać lub zapisywać w nich dane.

3. SP jest względnie tani w zakupie. Można wykorzystać bezpłatny WSS lub SPF żeby dotrzeć z dokumentami i procesami do każdego pracownika a na płatnym SPS 2007/2010 zrobić wypasiony portal dla managementu. Dodatkowo warto wspomnieć o możliwości tańszego zakupu licencji w modelu licencyjnym ISV.

4. SP świetnie integruje się z aplikacjami pakietu Office. Upraszcza to i przyśpiesza pracę jeśli możemy:
a) zapisać dokument z Worda, Excela bezpośrednio do witryny w SP
b) otworzyć dokument z witryny SP bez kopiowania go na dysk
c) mieć lokalną kopię dokumentów w Outlooku z bieżącą aktualizacją
d) mieć zadania i kalendarze z SP w Outlloku
e) wrzucić dane z excela do SP przy pomocy kopiuj-wklej
f) i wiele innych fajnych rzeczy. Ostatnio testuję integrację OneNote z SharePointem - notatki robione w OneNote można udostępniać w SP.

5. SP świetnie się nadaje do obniżenia kosztów wdrożeń systemów ERP. Ja proponuję klientom, żeby nie kupowali licencji drogiego ERP dla usera, który ma trzy razy w miesiącu np. dodać dokument. Zamiast tego oferuję wykonanie stosownego modułu w SP kosztującego taniej niż licencja ERP i dostępnego bezpłatnie (WSS, SPF) dla całej firmy.

6. SP można wykorzystać jako podkład pod dedykowane aplikacje. Mamy w SP gotowe funkcjonalności do zarządzania dokumentacją, zadaniami, kalendarze itp. Dodając trochę programowania można stworzyć najróżniejsze aplikacje. Ja ma za sobą wdrożenia aplikacji:
a) do zarządzania flotą samochodową
b) zarządzania projektami
c) zarządzania serwisem
d) CRM
e) przenoszenia numerów telefonicznych z TP S.A. do operatora alternatywnego
f) i parę innych ...

Tyle z grubsza. Nie jestem inżynierem więc nie piszę o szczegółach. Używam codziennie SP i sprzedaję rozwiązania oparte o SP, więc wiem do czego go wykorzystać ale gorzej z informacjami technicznymi.

SK
Link do wypowiedziLink

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Dlatego ta platforma podoba mi się, pół roku poznaje ją dogłębnie i wciąga mnie jej funkcjonalność ;), więc podjąłem się opieki tego systemu (brak administratora, więc jako helpdesk a co tam ;). Ostatnio podsunięto mi zapytanie czy warto integrować tą funkcjonalność w SP, tylko ciężko się wypowiedzieć kiedy ma się do czynienia z bazą ~5GB(webcontent) oraz jednym serwerem z front-endem (+ silnik SP) oraz drugi z bazą MSSQL. Stąd bardzo dziękuje za wasze odpowiedzi, nie mogłem na początku przetrawić myśli o bazie powyżej 20GB.Robert Krzysztof W. edytował(a) ten post dnia 20.01.11 o godzinie 09:35
Link do wypowiedziLink
Tomasz Zięba

Tomasz Zięba astozi | astozi lab

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Robert Krzysztof W.:
Łukasz B.:
Z moje doświadczenia:

1. Do 50 GB działa sprawnie, powyżej widać spadek wydajności

Jak mocno spada?, jak sobie radzi z indeksowaniem SQL, ponoć daje rade z bazami danych powyżej 100 GB a widzę że w praktyce nie jest tak różowo. Zawsze można utworzyć bazę danych dla poszczególnych aplikacji / zbioru witryn, tylko czy to ma sens. Czy problem występuje też w 2010 ?.

Pozdrawiam RobertRobert Krzysztof W. edytował(a) ten post dnia 17.01.11 o godzinie 11:58

http://technet.microsoft.com/en-us/magazine/gg475844.aspx
Link do wypowiedziLink
Maciej Raczyński

Maciej Raczyński .NET Senior
Developer
(Consultant)

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Sławek ładnie opisał zalety SP.

Dodałbym tylko punkt, który dotyczy end-usera. Jest to bardziej moje wrażenie, niż oficjalna cecha produktu, ale zauważyłem, że nawet oporni użytkownicy uczą się SP dosyć szybko i bez zgrzytów. To przekłada się na to, ze gdy napiszemy sobie w SP jakąś własną funkcjonalność i ona wygląda jak SP, to użytkownicy podchodzą do niej z dużo mniejszą rezerwą, bo w końcu są w znajomym i przyjaznym otoczeniu :)

Przyszła mi do głowy jeszcze jedna pułapka wdrożeń i rozwijania SP. Dostosowanie wizualne, czyli branding. Czasami przybiera tak horrendalne rozmiary, że ze standardowego SP zostaje niewiele, a potem jeszcze trzeba poprawiać i poprawiać. Pewne rzeczy można i powinno się dostosowywać pod siebie, ale inne są takie, a nie inne, bo są wynikiem pewnej koncepcji i dłubanie przy nich może zaburzyć całość funkcjonowania. Nie przebudowuje się wnętrza samochodu dla każdego klienta, a robi je raz i optymalnie :)

Z obu powodów ważne jest by "pilnować" dostawców, by tworzyli rozwiązania w SP, a nie siedzące sobie obok i udające, że są SP. Są różne wymagania i sytuacje, ale gdy coś wpisuje się w SP, to powinno być robione i umieszczane jako część SP. Przykładowo aplikacja, która ma własną bazę SQL (mniejsza o przyczyny), już nie będzie objęta mechanizmem kopii zapasowych wbudowanych w SP, więc wymaga oddzielnych procedur Disaster Recovery.

Miałem też chwilę by poszukać i znalazłem listę artykułów obrazujących filozofię estymacji potrzeb sprzętowych jakie będzie miało docelowe środowisko:
http://technet.microsoft.com/en-us/library/cc261716(of...
Link do wypowiedziLink

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Jeśli chodzi o pytanie dotyczące wydajności i wielkości bazy: jeśli wiemy, że w bazie będzie dużo plików i dzięki temu osiągnie ona duży rozmiar to warto poczytać o przechowywaniu plików sharepointowych na zewnętrznym serwerze plików: http://www.microsoft.com/poland/technet/bazawiedzy/cen...

SK
Link do wypowiedziLink

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Sławomir Kłódka:
Jeśli chodzi o pytanie dotyczące wydajności i wielkości bazy: jeśli wiemy, że w bazie będzie dużo plików i dzięki temu osiągnie ona duży rozmiar to warto poczytać o przechowywaniu plików sharepointowych na zewnętrznym serwerze plików: http://www.microsoft.com/poland/technet/bazawiedzy/cen...

SK

Dzięki za info, ktoś testował jak to faktycznie działa ? (gra warta świeczki?), to rozwiązanie też ma i wady, tak samo jak bloby w SQLu ;]Robert Krzysztof W. edytował(a) ten post dnia 20.01.11 o godzinie 00:03
Link do wypowiedziLink
Łukasz Skłodowski

Łukasz Skłodowski SharePoint
Architect, PM,
Właściciel -
Mavsystem

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Jeżeli nie macie jeszcze developowanych aplikacji/procesów to warto się w tej chwili zastanowić nad migracją tego środowiska do wersji 2010 - potem będzie trudniej.
Link do wypowiedziLink

konto usunięte

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Łukasz Skłodowski:
Jeżeli nie macie jeszcze developowanych aplikacji/procesów to warto się w tej chwili zastanowić nad migracją tego środowiska do wersji 2010 - potem będzie trudniej.

Pewnie że będzie trudniej, ale o wiele trudniej będzie wytłumaczyć managerom dlaczego ta platforma działa niestabilnie, wole poczekać aż nowy produkt będzie dłużej na rynku i najlepiej już z pierwszym Service Packiem, a potem migrować tym bardziej że mamy już środowisko 2007, druga sprawa po co mi 2010 jak nie mam z czym tego integrować, póki co mamy Office 2007 u użytkowników. Sharepoint 2010 ma wsteczna kompatybilność z 2007 i nie wygląda żeby były problemy z migracją. MS chwali się prostą migracją oraz kompatybilnością z własnymi webpartami.Robert Krzysztof W. edytował(a) ten post dnia 23.01.11 o godzinie 16:41
Link do wypowiedziLink
Tadeusz Szczygielski

Tadeusz Szczygielski Konsultant IT w
dziedzinie
Zarządzania
Projektami

Temat: Zapytanie dotyczace wydajnosci / funkcjonalnosci Sharepoint

Robert Krzysztof W.:
Sławomir Kłódka:
Jeśli chodzi o pytanie dotyczące wydajności i wielkości bazy: jeśli wiemy, że w bazie będzie dużo plików i dzięki temu osiągnie ona duży rozmiar to warto poczytać o przechowywaniu plików sharepointowych na zewnętrznym serwerze plików: http://www.microsoft.com/poland/technet/bazawiedzy/cen...

SK

Dzięki za info, ktoś testował jak to faktycznie działa ? (gra warta świeczki?), to rozwiązanie też ma i wady, tak samo jak bloby w SQLu ;]Robert Krzysztof W. edytował(a) ten post dnia 20.01.11 o godzinie 00:03
Witam
Wielkość bazy wprost zależy od ilości/wielkości ładowanych dokumentów. W moim przypadku użytkownicy dość łatwo szybko zapełnili bazę wielo-megowymi plikami CAD, jak jest włączone wersjonowanie to przyrost może być lawinowy.
Zatem jeśli baza przyrasta z powodu plików to jedynym sensownym rozwiązaniem jest zastosowanie tzw EBS lub RBS filestream provider.
Jest on pomyślany do obsługi tzw BLOBów. Jeśli taka aplikacja (EBS/RBS FSP) jest poprawnie napisana to bedzię mieć konfiguracje wielkości pliku, wtedy każdy plik powyżej np 500 kB będzie traktowany jako BLOB i ładowany poza SQLa
W bazie sharepointa trzymana jest tylko referencja. Z punktu widzenia użytkownika jest to przezroczyste, co więcej duże pliki ładują się (zapis/odczyt) wielokrotnie szybciej.
Odrzuciłem wersję pisania własnego EBS/RBS prowajdera i spośród trzech wybrałem produkt DocAve Extender który z powodzeniem zastosowałem.
Wbrew deklaracjom nie jest on jednak full-cost-free. Tylko licencja jest bezpłatna, a faktyczny koszt to ok 600 Euro / rok za tzw. maintenance;
Drugą opcją jest ładowania plików na klasyczny file system oraz synchronizacja (1:1) udziału sieciowy i wybranej biblioteki . To też testowałem i działa, tylko że kosztuje to znacznie drożej.
Temat jest dość obszerny , mam trochę linków i pdf w temacie w razie czego mogę wysłać mailem

więcej
EBS/RBS file stream provider http://www.avepoint.com/sharepoint-storage-extender-do...
File Connector http://www.avepoint.com/sharepoint-management-of-file-...
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Pytanie dotyczace wersji Sh...




Wyślij zaproszenie do
Anuluj