18:16
8/5/2013

* [Poznań] Atmosphere 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ą.

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

14 komentarzy

Dodaj komentarz
  1. cache statyki (np. varnish). wygrałem? :)

  2. 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 :)

  3. Agregacja CSS/JS,
    Optymalizacja zapytań SQL,
    Cache/memcached,
    Optymalizacja grafik ;)

  4. Optymalizacja?
    Cachowanie rekordów z bazy danych.
    Smarty posiada zintegrowany system cachowania ;)

  5. Gdzie jest na stronie konferencji napisane cokolwiek o Raspberry? Do tej pory słyszałem tylko o koszulce ;)

    • zobacz na fejsie.

  6. 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 :)

  7. 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.

  8. 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

  9. 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.

  10. 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

  11. no i kto jedzie do poznania?

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: