Pracuję na ArcGIS przy użyciu wirtualnego oprogramowania Citrix w pracy. Czasami jest strasznie powolny i bez żadnych zmian w MXD, nad którymi pracuję, jedna minuta ArcMap może działać w rozsądnym tempie, a następnie w następnej minucie może zwolnić do indeksowania. Dział IT uważa, że przyczyną problemu jest zbyt wiele warstw na mojej mapie. Mam przeczucie, że problemem mogą być konfiguracje sprzętowe lub programowe lub po prostu fakt, że korzystamy z Citrix.
W każdym razie mam w moim standardowym MXD, którego używam do edycji, 57 warstw SDE i 2 warstwy geobazy danych. Zdecydowana większość to warstwy, które muszę sprawdzić do edycji. Muszę sprawdzić, czy istnieją dane dla każdej z warstw, ponieważ należy je edytować i poddać kontroli jakości dla każdego projektu budowy rurociągu. Tylko kilka warstw to warstwy mapy bazowej, do których muszę regularnie odwoływać się.
Dział IT chce, żebym zmniejszył liczbę używanych warstw do 10. W idealnym świecie byłoby dobrze. Ale w prawdziwym świecie nie jest to praktyczne. Przy takiej sugestii będę musiał użyć około 5 różnych MXD tylko do wykonania zadania edycji dla danego projektu. Eksperymentowałem z użyciem tylko 10 warstw i jest to poważnie ograniczające. Brakuje mi kontekstu moich danych w stosunku do innych danych i muszę wielokrotnie odwiedzać ten sam obszar, aby upewnić się, że wszystkie dane zostały zaktualizowane. Wszystko to tylko dla niewielkiej poprawy wydajności i niewielkiego zmniejszenia liczby awarii podczas edycji.
Więc muszę zapytać, czy jest idealna liczba warstw? Ile to za dużo?
źródło
Odpowiedzi:
Pracowałem w tym samym środowisku (dokładnie takim samym!). Nie przeprowadziłem żadnych testów porównawczych, ale mam wrażenie, że liczba warstw w projekcie sama w sobie nie ma większego wpływu.
Z mojego doświadczenia wynika, że etykietowanie i liczba funkcji jest znacznie większym problemem niż liczba warstw (szczególnie jeśli wiele jest wyłączonych). Kiedyś miałem włączony pasek narzędzi do etykietowania i często wstrzymywałem etykietowanie. Wydaje się to niesamowicie poprawiać wydajność. Posiadanie warstw w projekcie, które nie zostały zaznaczone w spisie treści, wydaje się nie mieć negatywnego wpływu na wydajność. Mogę się mylić, ale liczba warstw IMO to coś w rodzaju czerwonego śledzia.
Moje zalecenie to wstrzymanie oznaczania (co jest najwygodniejszym rozwiązaniem) lub całkowite wyłączenie oznaczania funkcji.
źródło
Najpierw sprawdzę najlepsze praktyki korzystania z Citrix XenApp i ArcGIS , przewodnika opracowanego przez ESRI.
W przypadku poprzedniego klienta przeszedłem sporo rozwiązywania problemów z wydajnością w ESRI i naszym środowisku Citrix. Poniżej znajdują się najważniejsze informacje z tych rozmów:
Zakładam, że będziesz wprowadzać zmiany w ciasnym obszarze (powiększony dość blisko). Skonfigurowanie mapy w taki sposób, aby większość warstw była wyłączona, dopóki nie zbliżysz się do tego poziomu, pomoże poprawić wydajność.
MXD Doctor to coś, co możesz chcieć uruchomić, aby zobaczyć, które elementy mogą powodować problemy.
Upewnij się, że ArcGIS jest faktycznie zainstalowany na samym serwerze Citrix, a nie tylko dublowany lub przesyłany strumieniowo.
Wydaje się, że naszym największym spowolnieniem są drukarki - kiedy wyłączyliśmy możliwości drukarki (i automatyczne połączenie), połączyliśmy się znacznie szybciej i zauważyliśmy krótsze opóźnienie (więcej informacji w tym biuletynie ESRI) . Sprawiło to jednak, że musieliśmy najpierw wyeksportować nasze mapy do formatu pdf, a następnie wydrukować, ale przy 90% naszych prac związanych z edycją i analizą nikt nie miał nic przeciwko.
59 warstw to całkiem sporo, jeśli możesz go powalić, to by pomogło. Zgodnie z sugestią @jbchurchill, spójrz na swoje etykietowanie. Powinieneś także spojrzeć na dowolną niestandardową symbolikę.
źródło
Mam doświadczenie w rozwiązywaniu problemów w systemach GIS, w tym w Citrix. Twój problem może być wszędzie i prawdopodobnie kombinacją czynników. Porozmawiaj ze swoim przedstawicielem Esri o wskazówki.
Polecam przeczytanie tego: http://www.wiki.gis.com/wiki/index.php/Software_Performance#Use_MXDPerfStat_to_measure_display_complexity
Znakowanie, używanie pamięci podręcznej funkcji i buforowanych map bazowych to dobre praktyki.
Istnieje również nowsze narzędzie, które można wypróbować i które jest bardziej przyjazne dla użytkownika, o nazwie perfqanalyzer https://blogs.esri.com/esri/supportcenter/2014/02/03/calibrating-arcgis-performance-with-perfqanalyzer-new-build- dostępny do pobrania/
źródło
Pomyślałem, że wskoczę do tego, że pracuję w firmie, która ma złą praktykę z MXD używającymi ich jako prawie serwerów plików dla danych. Aby dać Ci wyobrażenie, mamy dyski MXD z ponad 1000 warstw. Współpracowaliśmy z niektórymi konsultantami, którzy zalecili 650 ms na warstwę, aby otwarcie mapy było rozsądne, co oznacza, że otwarcie niektórych może zająć 14 minut! To nie jest dobre i zdecydowanie nie jest optymalne, ale chciałem poinformować, że są też inni niż cierpieć!
Niedawno przeprowadziliśmy się do EGDB, co ogromnie uderzyło w występy. Odkryłem, że włączenie buforowania funkcji znacznie się zmieniło wraz z zapewnieniem odpowiedniej konserwacji EGDB (analiza, indeksy, kompresja itp.)
Drugiego doktora MXD, aby usunąć wszystkie stare ścieżki łączące się z danymi, spróbuj usunąć mapę szablonów. MXD perf stat jest potężnym narzędziem, które wydaje mi się, że nie wykorzystałem go w połowie ze względu na mój brak umiejętności cmd.
źródło