8/5/2013
W dniach 13-14 maja w Poznaniu odbędzie się pierwsza edycja konferencji Atmosphere http://atmosphere-conference.com, Główną ideą Konferencji Atmosphere jest zbudowanie platformy wymiany wiedzy dotyczącej funkcjonowania i optymalizacji serwisów internetowych pomiędzy uczestnikami z Europy Środkowo-Wschodniej. Zaproszeni są wszyscy, którzy chcą budować rozwiązania na dużą skalę, szczególnie inżynierowie z doświadczeniem i wizją, którzy chcą rozmawiać o nieszablonowych problemach aplikacji web.
Uczestnicy w trakcie konferencji będą mogli dowiedzieć się, jak połączyć metody pracy różnych działów, posługujących się odmiennym językiem i różnie definiujących cele – menadżerów projektu, DevOps i programistów – tak, aby mogli efektywnie ze sobą współpracować i dostarczać jak najlepsze rozwiązania. Dla osób, które chcą budować własny globalny startup odbędą się wykłady, na których zainteresowani dowiedzą się, co może ich spotkać w bliskiej przyszłości. Poza tym w ramach Atmosphere 2013 poruszane będą tematy takie jak SaaS, DDoS, optymalizacja Javascript i CCS, HTTP i REST, struktury danych, TDD oraz skalowalność i wydajność serwisów internetowych. Uczestnicy otrzymają Raspberry PI – komputer wielkości karty kredytowej, który podłącza się do wyświetlacza oraz klawiatury. Uczestnicy nie wrócą z konferencji z kolejnym plecakiem, a z genialnym gadżetem, który inspiruje i daje możliwość stworzenia projektu w oparciu o minikomputer.
Cena: 1500 PLN netto (15% zniżki można otrzymać z kodem niebezpiecznik_15).
Mamy dla Was jedną wejściówkę, aby ją zdobyć, należy w komentarzu opisać sposób/technikę optymalizacji serwisu internetowego, którą zastosować może praktycznie każdy programista bez ponoszenia jakichkolwiek kosztów (można podawać nazwy pomocnych narzędzi/oprogramowania). W piątek o 23.59 wybierzemy jednen z komentarzy i nagrodzimy wejściówką.
Weź udział z kolegami w jednym z naszych 8 cyberwykładów. Wiedzę podajemy z humorem i w przystępny dla każdego pracownika sposób. Zdalnie lub u Ciebie w firmie. Kliknij tu i zobacz opisy wykładów!
Każdy powinien zobaczyć te webinary! Praktyczna wiedza i zrozumiały język. 6 topowych tematów — kliknij tutaj i zobacz szczegółowe opisy oraz darmowy webinar.
cache statyki (np. varnish). wygrałem? :)
varnish sie jednak nie kwalifikuje jako rozwiazanie bezkosztowe, przynajmniej jakis ram trzeba mu fostarczyc no i w wersji minimum napisac pare linijek konfiga. na szczęście mamy 2 cdny, które działają jako cache w chmurze i konkurują zaciekle nie pobierając opłat w standardowych planach:
http://www.sitepoint.com/battle-of-cdn-comparing-cloudflare-incapsula/
bierzcie pod uwagę w waszych protipach, ze czas programisty to tez koszt :)
bonusowe punkty za analizę bezpieczeństwa używania zewnętrznych cacheów: http://www.ehackingnews.com/2012/11/incapsula-vs-cloudflare-security-review.html?m=1
Witajcie ;)
Moim zdaniem każdy może oprzeć stronę o mysql i css.
Wszelkie operacje, które można wykonać w mysql przenosić właśnie na mysql.
Odciąża to znacząco prace serwera www.
Dodatkowo jeśli chodzi o ciężar witryny to zamiast opierać stronę o obrazki .png .jpg. .gif itd to tworzyć wszystkie możliwe elementy w css. Jest to bardzo optymalne, odciąża serwer i wszystko stworzone w css nie traci jakości wraz ze skalowaniem wielkości witryny.
Pozdrawiam
Romek :)
Agregacja CSS/JS,
Optymalizacja zapytań SQL,
Cache/memcached,
Optymalizacja grafik ;)
Optymalizacja?
Cachowanie rekordów z bazy danych.
Smarty posiada zintegrowany system cachowania ;)
Gdzie jest na stronie konferencji napisane cokolwiek o Raspberry? Do tej pory słyszałem tylko o koszulce ;)
zobacz na fejsie.
1. Zamienić apache i htaccess na nginx, lighttpd (to przy wyborze hostingu)
2. CSS Sprites, długi czas expires dla plików statycznych
3. Kompresja gzip dla plików statycznych, cssminify, jsminify.
4. Przeniesienie wszystkich CSS, JS inline do zewnętrzego pliku.
5. Korzystanie z CDN dla jquery, mootools, etc.
Ostatni najprostszy – wywalić wszystkie widgety z facebooka, google plus, twitter :)
Cloudflare, wersja darmowa.
Minify dla CSS i JS.
Kompresja GZIP assetów.
Opóźniony start Javascriptu na stronie.
Umieszczanie niewielkich fragmentów JS/CSS inline zamiast w osobnych plikach.
Rozwiązania na hostingu współdzielonym:
1. Lazy loading obrazów/contentu
2. javascript defer
3. css/js minify
4. Optymalizacja struktury bazy danych oraz zapytań-indeksowanie i podział na odpowiednie tabele ( Słowo kluczowe EXPLAIN może pomóc przy optymalizacji )
5. generowanie podstron jako plain html
6. cacheowanie plików statycznych przez dodanie odpowiedniego headera
7. Redukcja rozmiaru obrazów
8. css sprite
9. Witryna ajaxowa( przeładowywana tylko część contentu )
10. rezygnacja z bibliotek/systemów takich jak jquery / zend framework i użycie lżejszych alternatyw( inne popularne biblioteki lub własny kod, do jednego zapytania ajaxa na całej witrynie nie potrzebujemy całego jquery ;) )
Rozwiązania przy własnej maszynie:
1. nginx/gwan jako static serwer ( odciążenie głównego serwera od tworzenia zbędnych wątków-zwłaszcza apache)
2. redis/memcached do cacheowania danych
3. Generowanie pliku cachegrind.out przez xdebug i analiza w kcachegrind – wyszukiwanie zbędnych, lub powolnych wywołań i optymalizacja kodu
4. varnish/esi lub inny load balancer z obsługą esi
5. w wypadku apache wyłączyć obsługe .htaccess i reguły przenieść do konfiguracji hosta- w innym wypadku przy każdym requeście apache sprawdza czy w katalogu znajduje się plik .htaccess
6. Odpowiednia konfiguracja webserwera – użycie pamięci, przydzielona liczba wątków( dla nginxa ustawiamy tyle wątków, ile mamy rdzeni )
7. Aktualizacja php z wersji 5.3 do 5.4 – znaczny wzrost wydajności
1) Analiza bieżących wymagań.
2) Analiza kierunków rozwoju – co z tego że zoptymalizujesz, jeśli zaraz
okaże się, że projekt może być dogłębnie zmieniany.
3) Oszacowanie ruchu na stronie, czy optymalizacja jest w ogóle potrzebna?
4) Oszacowanie korzyści z optymalizacji – proces optymalizacji bywa drogi,
często jest nieopłacalny.
5) Jeśli optymalizujemy, to powrót do punktu 1 i 2 – po niektórych
optymalizacjach serwis może być trudny w modyfikacji i rozwoju. Trzeba
dobrze zrewidować jaka ma być docelowa funkcjonalność. Każda funkcjonalność
może wymagać innej optymalizacji!
6) Jeśli mimo wszystko nadal chcemy optymalizować, to najpierw: ustalenie
wąskiego gardła, co jest wąskim gardłem:
a) procedury obliczeniowe?
b) transfer?
c) operacje dyskowe?
d) zewnętrzne źródła danych?
e) ludzka praca?
7) Najdroższa jest ludzka praca, a najcenniejszy wolny czas, więc pierwsze pytanie:
czy da się zoptymalizować tylko przy pomocy konfiguracji, albo poprzez zakup
lepszego sprzętu?
a) gdy wąskim gardłem są obliczenia:
– czy można obliczenia przenieść na JS po stronie klienta?
– czy można zakupić biblioteki do obliczeń?
– czy obliczenia można przeprowadzać równolegle na wielu procesorach/komputerach?
– czy obliczenia można wykonać na kartach grafiki i czy jest gotowy soft na GPU?
– w ostateczności musimy zakasać rękawy i wklepać lepszy kod samodzielnie, albo
zatrudnić do tego celu ludzi.
b) gdy wąskim gardłem jest transfer:
– czy można kupić szybsze łącze?
– czy można część zapytań przenieść na inny komputer z niezależnym łączem?
– czy dane są kompresowane przed wysłaniem?
– czy można wysłać same dane, a obrobić je dopiero w JS po stronie klienta?
– czy można buforować dane po stronie klienta? pliki statyczne powinny mieć
odpowiednie nagłówki.
– może warto na stronie zamieści applety i obiekty flash, one często mogą
pobierać precyzyjne dane z serwera, choć same stanowią pewien narzut.
c) gdy wąskim gardłem są operacje dyskowe:
– zwykle kodu, html, plików konfiguracyjnych jest stosunkowo mało w porównaniu do
danych. największą bzdurą jest próba optymalizowania dostępu do jakiegoś jednego
pliku konfiguracyjnego jak .access. Problemy tego typu mają swoje źródłow dużych
zbiorach danych.
– optymalizacja buforowania wszelkich plików z danymi, można to robić z poziomu
systemu operacyjnego, specjalistycznych programów narzędziowych, albo poprzez
konfigurację bazy danych – jeśli takowej używamy.
– gdy chcemy zrobić mikro-optymalizację to pomaga przejście na gorszą, ale
szybszą bazę danych, np. mysql, albo sqlite.
– gdy to nie pomaga, próbujemy lepszego sprzętu, macierze RAID, dyski SSD, itd.
– gdy chcemy zrobić optymalizację z prawdziwego zdarzenia, to instalujemy
na klastrze porządny serwer baz danych (oracl, postgres, mssql, itd)
d) gdy wąskim gardłem są zewnętrzne źródła danych:
– chyba tylko możemy rozejrzeć się za lepszym źródłem danych, lepszym dostawcą.
e) gdy wąskim gardłem jest ludzka praca:
– analiza pracy całego zespołu, czy da się ich lepiej zorganizować?
– analiza narzędzi z jakich korzysta zespół, czy można im przygotować coś
bardziej pomocnego?
– zatrudnienie większej ilosci pracowników, może lepszych specjalistów.
8) I jeszcze raz: unikanie drobiazdkowości. Jeśli warto optymalizować, to powinny
też być pieniądze na porządne podejście do tematu.
Witam
Jeśli ma być bez kosztowo to przede wszystkim:
Określenie wąskich gardeł (własny system profilowania lub np. Xdebug), w zależności od wyników trzeba podjąć odpowiednie kroki między innymi.
– Optymalizacja kodu.
– Optymalizacja schematu bazy danych, odpowiedni dobór silników magazynowania danych, przyjrzenie się rodzajom przechowywanych danych, odpowiednie dobranie indeksów
– Odpowiednia konfiguracja bazy danych, serwera etc.
– Zastosowanie cache np Memcache
– Do optymalizacji wyszukiwania pełno tekstowego można użyć Sphinksa
– Zastosowanie replikacji
no i kto jedzie do poznania?