Jak "rozgrzać" strukturę podmiotu? Kiedy robi się"zimno"?

Nie, odpowiedzią na moje drugie pytanie nie jest zima.

Przedmowa:

Ostatnio przeprowadziłem wiele badań na temat struktury jednostek i coś, co ciągle mnie niepokoi, to jego wydajność, gdy zapytania nie są rozgrzane, tak zwane zimne zapytania.

Przejrzałem artykuł performance considerations dla Entity Framework 5.0. Autorzy wprowadzili pojęcie zapytań Warm i Cold i jak się różnią, które I odnotowałem też siebie nie wiedząc o ich istnieniu. W tym miejscu warto chyba wspomnieć, że mam za plecami tylko pół roku doświadczenia.

Teraz wiem, jakie tematy mogę badać dodatkowo, jeśli chcę lepiej zrozumieć ramy pod względem wydajności. Niestety większość informacji w Internecie jest nieaktualna lub nadęta subiektywnością, stąd moja niezdolność do znalezienia dodatkowych informacji na Warm vs Cold queries temat.

Zasadniczo to, co zauważyłem do tej pory, to to, że ilekroć muszę przekompilować lub Recycling hits, moje początkowe zapytania stają się bardzo powolne. Wszelkie kolejne odczyty danych są szybkie (subiektywne), zgodnie z oczekiwaniami.

Będziemy migrować do Windows Server 2012, IIS8 i SQL Server 2012 i jako Junior wygrałem sobie możliwość przetestowania ich przed resztą. Bardzo się cieszę, że wprowadzili moduł rozgrzewający, który najpierw przygotuje moją aplikację Prośba. Jednak nie jestem pewien, jak postępować z ociepleniem mojej struktury podmiotu.

To co już wiem warto zrobić:

  • Wygeneruj moje opinie z góry zgodnie z sugestią.
  • ostatecznie przenieść moje modele do osobnego zespołu.

To co rozważam, idąc zdrowym rozsądkiem, prawdopodobnie złe podejście :

  • wykonywanie fałszywych odczytów danych przy starcie aplikacji w celu ogrzania rzeczy up, generate and validate the modelki.

Pytania:

  • jakie byłoby najlepsze podejście, aby mieć wysoką dostępność w ramach mojej jednostki w dowolnym momencie?
  • W jakich przypadkach struktura podmiotu staje się" zimna " ponownie? (Rekompilacja, Recykling, restart IIS itp.)
Author: Peter, 2012-11-06
Source

5 answers

  • Jakie byłoby najlepsze podejście, aby mieć wysoką dostępność w ramach mojej jednostki w dowolnym momencie?

Możesz wybrać mieszankę wstępnie wygenerowanych widoków i statycznych skompilowanych zapytań.

Static compiled są dobre, ponieważ są szybkie i łatwe w pisaniu i pomagają zwiększyć wydajność. Jednak w przypadku EF5 nie jest konieczne kompilowanie wszystkich zapytań, ponieważ EF sam będzie automatycznie kompilował zapytania. Jedynym problemem jest to, że te zapytania mogą zostać utracone, gdy pamięć podręczna jest / align = "left" / Więc nadal chcesz trzymać odniesienia do własnych skompilowanych zapytań dla tych, które występują bardzo rzadko, ale są drogie. Jeśli umieścisz te zapytania w klasach statycznych, zostaną one skompilowane, gdy będą wymagane po raz pierwszy. Może to być za późno na niektóre zapytania, więc możesz wymusić kompilację tych zapytań podczas uruchamiania aplikacji.

Pregeneracja poglądów to inna możliwość, o której wspominasz. Zwłaszcza dla tych zapytań, które zajmują bardzo dużo czasu i to się nie zmienia. W ten sposób można przenieść narzut wydajności z runtime do czasu kompilacji. Również to nie wprowadzi żadnych opóźnień. Ale oczywiście ta zmiana przechodzi do bazy danych, więc nie jest tak łatwo sobie z tym poradzić. Kod jest bardziej elastyczny.

Nie używaj dużej ilości dziedziczenia TPT(jest to ogólny problem z wydajnością w EF). Nie buduj hierarchii dziedziczenia zbyt głęboko ani zbyt szeroko. Tylko 2-3 właściwości specyficzne dla danej klasy mogą nie wystarczyć, aby wymagać własnego typu, ale mogą być obsługiwane jako opcjonalne (nullable) właściwości dla istniejącego typu.

Nie trzymaj się jednego kontekstu przez długi czas. Każda instancja kontekstowa ma własną pamięć podręczną pierwszego poziomu, która spowalnia wydajność w miarę jej powiększania. Tworzenie kontekstu jest tanie, ale zarządzanie państwem wewnątrz buforowanych jednostek kontekstu może stać się kosztowne. Pozostałe pamięci podręczne (Plan zapytań i metadane) są współdzielone między kontekstami i zginą razem z AppDomain.

W sumie powinieneś zrobić pamiętaj, aby często przydzielać konteksty i używać ich tylko przez krótki czas, aby można było szybko uruchomić aplikację, aby kompilować zapytania, które są rzadko używane i dostarczać wstępnie wygenerowane widoki dla zapytań, które są krytyczne dla wydajności i często używane.

  • w jakich przypadkach struktura podmiotu staje się" zimna " ponownie? (Rekompilacja, Recykling, restart IIS itp.)

Zasadniczo za każdym razem, gdy tracisz AppDomain. IIS wykonuje Restart co 29 godzin , więc możesz nigdy nie gwarantuj, że będziesz miał swoje przypadki w pobliżu. Również po pewnym czasie bez aktywności AppDomain jest również wyłączony. Powinieneś spróbować wrócić szybko. Może uda ci się wykonać inicjalizację asynchronicznie (ale uważaj na problemy z wielowątkowością). Możesz użyć zaplanowanych zadań, które wywołują strony obojętne w aplikacji w czasie, gdy nie ma żądań, aby zapobiec śmierci AppDomain, ale w końcu tak się stanie.

Zakładam również, że gdy zmienisz konfigurację plik lub zmienić zespoły będzie restart.

 54
Author: Andreas,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-03-26 09:03:09

Jeśli szukasz maksymalnej wydajności we wszystkich połączeniach, powinieneś dokładnie rozważyć swoją architekturę. Na przykład, może to mieć sens, aby pre-cache często używane wyszukiwania w pamięci RAM serwera, gdy aplikacja ładuje się zamiast używać wywołań bazy danych na każde żądanie. Technika ta zapewni minimalny czas reakcji aplikacji dla powszechnie używanych danych. Jednak musisz mieć pewność, że masz dobrze zachowaną politykę wygaśnięcia lub zawsze Wyczyść pamięć podręczną za każdym razem, gdy wprowadzane są zmiany, które wpływają na buforowanych danych, aby uniknąć problemów z współbieżnością.

Ogólnie rzecz biorąc, należy dążyć do projektowania architektur rozproszonych tak, aby wymagały żądań danych opartych na IO tylko wtedy, gdy lokalnie buforowane informacje stają się przestarzałe lub muszą być transakcyjne. Każde żądanie danych "over the wire"zwykle trwa 10-1000 razy dłużej niż lokalne pobieranie w pamięci podręcznej. Ten jeden fakt sam w sobie często sprawia, że dyskusje na temat "zimnych i ciepłych danych" są nieistotne w porównaniu do "lokalnych i ciepłych danych". zdalny " problem z danymi.

 8
Author: mcstar,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-27 14:13:09

Ogólne wskazówki.

  • Wykonaj rygorystyczne logowanie, w tym co jest dostępne i Czas żądania .
  • wykonuj fałszywe żądania podczas inicjowania aplikacji do warm boot bardzo powolne żądania , które odbierasz z poprzedniego kroku.
  • nie przejmuj się optymalizacją, chyba że jest to prawdziwy problem, komunikuj się z konsumentem aplikacji i pytaj. Uzyskaj komfort posiadania ciągłej pętli sprzężenia zwrotnego, jeśli tylko chcesz dowiedzieć się , czego potrzebujesz optymalizacja .

Teraz wyjaśnię, dlaczego fałszywe żądania nie są złym podejściem .

  • mniejsza złożoność - rozgrzewasz aplikację w sposób, który będzie działał niezależnie od zmian w frameworku i nie musisz wymyślać prawdopodobnie funky API / Framework wewnętrzne, aby to zrobić we właściwy sposób.
  • większy zasięg - rozgrzewasz wszystkie warstwy buforowania naraz związane z powolnym Prośba.

Aby wyjaśnić, kiedy pamięć podręczna staje się"zimna".

Dzieje się to na dowolnej warstwie w Twoim frameworku, która stosuje pamięć podręczną, dobry opis znajduje się na górze strony wydajności.

  • gdy cache musi zostać zweryfikowany po potencjalnej zmianie, która powoduje, że cache jest przestarzały, może to być limit czasu lub bardziej inteligentny (np. zmiana w buforowanym elemencie).
  • gdy element cache jest eksmitowany, algorytm do tego celu jest opisany w sekcja "algorytm eksmisji pamięci podręcznej" w artykule o wydajności, który podlinkowałeś , ale w skrócie.
    • Lfru (Least frequently - recently used) cache na liczbę trafień i wiek z limitem 800 pozycji.

Inne rzeczy, o których wspomniałeś, w szczególności rekompilacja i ponowne uruchomienie IIS, czyszczą części lub wszystkie pamięci podręczne w pamięci.

 7
Author: udoprog,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-29 05:43:26

Jak już stwierdziłeś, użyj "wstępnie wygenerowanych widoków", to naprawdę wszystko, co musisz zrobić.

Wydobyty z twojego linku : "Gdy widoki są generowane, są one również weryfikowane. Z punktu widzenia wydajności, zdecydowana większość kosztów generowania widoków jest w rzeczywistości walidacją widoków "

Oznacza to, że wydajność będzie miała miejsce podczas budowania zespołu modelu. Twój obiekt kontekstowy pominie "zimne zapytanie" i pozostanie responsywny przez czas cykl życia obiektu kontekstowego, jak również kolejne konteksty nowych obiektów.

Wykonywanie nieistotnych zapytań nie będzie służyć żadnemu innemu celowi niż zużywanie zasobów systemowych.

Skrót ...

  1. Pomiń całą dodatkową pracę wstępnie wygenerowanych widoków
  2. Tworzenie kontekstu obiektu
  3. Odpal to słodkie nieistotne zapytanie
  4. następnie zachowaj odniesienie do kontekstu obiektu przez czas trwania procesu (niezalecane).
 3
Author: hotpie,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-28 21:12:53

Nie mam doświadczenia w tym zakresie. Ale w innych kontekstach, np. Solr, całkowicie fałszywe odczyty nie będą zbyt przydatne, chyba że możesz buforować cały DB (lub indeks).

Lepszym podejściem byłoby rejestrowanie zapytań, wyodrębnianie najczęstszych z dzienników i używanie ich do rozgrzewania się. Pamiętaj tylko, aby nie logować zapytań rozgrzewających lub nie usuwać ich z dzienników przed kontynuowaniem.

 2
Author: estani,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-23 15:13:14