Cache - jak, czym, kiedy |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Cache - jak, czym, kiedy |
25.01.2014, 16:16:17
Post
#21
|
|
Grupa: Zarejestrowani Postów: 435 Pomógł: 40 Dołączył: 16.02.2003 Skąd: Wrocław Ostrzeżenie: (0%) |
Cytat - operacje zapisu (Command / INSERT, UPDATE, DELETE / HTTP POST, PUT, DELETE) odkladasz na kolejke (MQ) - pozwoli to kontrolowac przepływ i ilośc transakcji względem warstwy persistence Czyli każdy select do bazy danych opakowujesz w swoją kolejkę *MQ? Jaki w tym sens? Serwery same posiadają mechanizmy kolejkowania żądań - po co robić na to kolejną/możliwie awaryjną warstwę abstrakcji?! Cytat Jest jeszcze jeden mega plus: zauważ, że jeżeli w kolejce masz więcej niż jedną operacje zapisu TEGO SAMEGO REKORDU, to możesz zdjąc z kolejki WSZYSTKIE starsze operacje i zapisać tylko najnowszy stan Jak z kolejki zdjąć inne operacje dla tego samego rekordu? ... Cytat Zakładając, że trzymasz się SQL, to sorry ale "cachowanie" to proteza, która działa może przy blogu lub forum ale nie w systemie ERP. Polecam zainteresować się modelem CQRS (Command Query Responsibility Segregation), dodatkowo tematyka MOM (Message Oriented Middleware). Twój problem jest prosty do rozwiązania przykładowo za pomocą takiej architektury: Architektura która opisałeś to przecież nic innego jak zwykłe cacheowanie wynikow zapytań do bazy danych, z dodanymi "protezami" w postaci własnych kolejek. Nie ma sensu ich wprowadzać tylko żeby zastosować throttling w bazie danych. Przy połączeniach z zewnętrznymi systemami/webservices - ok, ale do własnej bazy danych?! Jaki w tym cel? Ten post edytował ano 25.01.2014, 16:21:56 -------------------- Linkedin | ...
|
|
|
25.01.2014, 16:33:24
Post
#22
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 7 Dołączył: 27.01.2010 Ostrzeżenie: (0%) |
Architektura która opisałeś to przecież nic innego jak zwykłe cacheowanie wynikow zapytań do bazy danych, z dodanymi "protezami" w postaci własnych kolejek. Zupełnie źle mnie zrozumiałeś Ja nie kolejkuje "zapisów do bazy" czyli gołych upsertów, tylko kolejkuje transakcje biznesowe. Przykładowo, aktor uruchamia serwis np: generujący dane do wyświetlenia aktualnego stanu konta użytkownika wraz z np: billingiem i statami, korzysta z najróżniejszych warstw persistence i innych serwisów, tak długo jak użytkownik nie będzie zmieniał stanu swojego konta, tak długo nie ma potrzeby odswieżania tych informacji, a jeżeli wygenerowanie ich zajmuje relatywnie dużo czasu, bądz obciąża zasoby, a użytkownik ma interakcje z systemem w między czasie, jest możliwośc zdjęcia tych transakcji, których wynik będzie już nieaktualny zanim aktor wykona daną transakcje. Inna sprawa, wiele serwisów szybciej oblicza wynik, niż jest go w stanie zapisać, architektura tego typu, pozwala na uzyskanie wyniku zanim "spłynie" on do warstwy persistence. Po prostu działa to asynchronicznie względem wejścia czyli np: interfejsu webowego. U nas, podobna architektura sprawdza się doskonale w usługach restowych, umożliwiając niemal liniowe skalowanie i kontrolowanie przepływu informacji przez legacy sql, a mówie wielu milionach użytkowników. PHP to dość debilna technologia i ze współbierznością ma niewiele wspólnego, ale tego typu rozwiązania są jak najbardziej w użyciu np: Akka.io w Scali. -------------------- |
|
|
14.02.2014, 06:20:42
Post
#23
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Co do APC miałem na myśli fakt, że będzie ono za chwilę częścią PHP więc nie trzeba będzie dbać o doinstalowywanie go jako biblioteki. Coś się Tobie PORZĄDNIE pomieszało - od PHP 5.5 w core Zend Engine (silnika PHP) jest OPCACHE, a nie APC. PHP rezygnuje ze wspierania APC z tego powodu, że to stare i źle zaprojektowanie rozwiązanie, z którym były CIĄGLE problemy (developerzy męczyli się tygodniami, aby wprowadzać update'y z powodu tragicznego designu). |
|
|
14.02.2014, 06:38:41
Post
#24
|
|
Grupa: Zarejestrowani Postów: 125 Pomógł: 7 Dołączył: 27.01.2010 Ostrzeżenie: (0%) |
W 5.5 jest APCu, opcache to cache do opcodu, APC mialo jeszcze szybki keystore w pamieci, i APCu nadal realizuje ta funkcjonalnosc.
-------------------- |
|
|
24.03.2014, 16:56:24
Post
#25
|
|
Grupa: Zarejestrowani Postów: 77 Pomógł: 4 Dołączył: 14.05.2013 Ostrzeżenie: (0%) |
czyli cachujac: Front-end używamy Varnish, kod PHP używamy APC, a zapytania do bazy danych REDIS ?
|
|
|
1.06.2014, 20:54:00
Post
#26
|
|
Grupa: Zarejestrowani Postów: 150 Pomógł: 4 Dołączył: 3.01.2010 Ostrzeżenie: (0%) |
kiedyś czytałem że od wersji php 5.5 jest Zend Opcache, jeżeli mój skrypt będzie się opierał na php+mysql mogę sobie darować dodatkowe cachowanie przez jakieś klasy czy własne rozwiązania?
|
|
|
25.01.2015, 12:49:48
Post
#27
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%) |
Ja zapytam z innej beczki troszkę. Jakie macie metody na rozgrzewkę cache?
Ja myślałem żeby odwiedzić sitemap.xml jakimś curlem czy czymś. Macie jakieś rozwiązania inne? |
|
|
25.01.2015, 16:25:15
Post
#28
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
Z racji na to, że rodzajów cache'a mogą być dziesiątki, gdzie część z nich nie jest zależna od tego czy strona jest odwiedzana czy nie sugerowałbym coś w deseń rozwiązania z Symfony: http://blog.whiteoctober.co.uk/2014/02/25/...rmup-explained/
W ten sposób mógłbyś przygotować sobie jakieś narzędzia do rozgrzewania konkretnych rzeczy. |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 14:08 |