Serwis Morizon.pl to wyszukiwarka nieruchomości. Dość ciekawa aplikacja, duża baza (500k ofert, 1250 biur nieruchomości współpracujących), istotny już traffic (blisko 300k wizyt miesięcznie).
Zachęcamy do zapoznania się, a w przypadku pytań, postaramy się odpowiedzieć
Wybrane funkcjonalności serwisu:
dodawanie ofert
wyszukiwanie (Sphinx) i prezentacja ofert
parsery z różnych programów (w tym desktopowych) dla biur nieruchomości (działanie wielowątkowe)
zaawansowane mechanizmy pozycjonowania i sortowania ofert
wyszukiwanie na mapie (jQuerry)
zarządzanie z poziomu biura nieruchomości
rozbudowane raporty
mailingi (m.in. szablony maili w bazie danych)
i wiele innych…
Mamy ambitne i ciekawe plany na rozwój aplikacji, wiec jeszcze wiele przed nami (sporo w ramach frontendu i backendu)!
Czy morizon.pl stosuje słowa kluczowe (meta.keywords) tylko na głównej stronie ?
Na stronie http://www.morizon.pl/pages/porady-eksperta użycie podwójnego cudzysłówu w meta.description nie jest poprawne.
dzięki za komentarze. serwis działa wolno, bo ruch ostatnio znacznie wzrósł i nie nadążamy z infrastrukturą troche taki comeback NK, choć jeszcze oczywiście nie ta skala, ale już się wewnętrznie śmiejemy, że mistera Gąbkę trzeba zaprojektować na ruchliwsze momenty…
co do metatagów - temat optymalizacji SEO jeszcze również przed nami.
Witam, jestem programistą w Morizon.
To nie jest problem N+1 (dla pewności sprawdziłem).
Używamy tekstowej wyszukiwarki Sphinx.
Poza tym w Morizon prezentujemy 10 wyników i z moich testów wynika, iż includowanie np Miasta, Dzielnicy, Ulicy, Typu nieruchomości itd wpływa minimalnie na wydajność (tylko zwiększa zużycie pamięci).
Problemem są procesy importów (kilkaset nowych plików dziennie z aktualizacją ponad 100tyś ofert).
Łącznie kilkanaście zadań rake (działają równolegle) pracuje na tym tym samym serwerze co www, pliki statyczne (baza danych jest wydzielona).
Dużo by pisać…
Do końca wakacji czeka nas migracja na nowe serwery. Wykorzystujemy rozwiązania Blade oparte o HP, które dotuje nam UE ;).
Jeśli chcecie poznać szczegóły, lub planujecie do nas dołączyć to chętnie odpowiem na wasze pytania.
[quote=morizon]Problemem są procesy importów (kilkaset nowych plików dziennie z aktualizacją ponad 100tyś ofert).
Łącznie kilkanaście zadań rake (działają równolegle) pracuje na tym tym samym serwerze co www, pliki statyczne (baza danych jest wydzielona).[/quote]
Wow. To i tak szacun, że przy jednej maszynie aplikacyjnej to wszystko jako-tako działa
Skoro można pytac to jaka konkretnie maszyna ? tzn ile pamięci i jaki procek, aha i ile na tym instancji aplikacji chodzi ? Dużego kopa dało wydzielenie bazy na inny server ?
3 instancje w Passengerze + (w tym momencie) 12 zadań rake
napisałem prosty skrypt, który nie uruchamia zadań rake jeśli “średni load” przekracza zadaną wartość podaną jako parametr (np MAX_LOAD=3.0) lub zadań tego samego typu jest więcej niż zadana wartość (np MAX_PROC=5) - zadania z mniejszym priorytetem uruchamiane są gdy load spada poniżej 2.0
to oczywiście rozwiązuje problem “przeciążenia serwera”, niemniej load w waha się w granicach 1.5-6.0
“od zawsze” mamy wydzielony serwer na bazę, w nowej architekturze znajdzie się miejsce na 2-3 slejwy
Oczywiście optymalizacja jest zawsze możliwa, może któryś/aś z was chce spróbować?
Z naszych doświadczeń wynika, że serwer bazodanowy to ostatnie, co trzeba będzie skalować. Zwłaszcza że skalowanie horyzontalne DB jest najbardziej upierdliwym ze skalowań.
Memcached, memcached, memcached
[quote=Tomash]Z naszych doświadczeń wynika, że serwer bazodanowy to ostatnie, co trzeba będzie skalować. Zwłaszcza że skalowanie horyzontalne DB jest najbardziej upierdliwym ze skalowań.
Memcached, memcached, memcached wink[/quote]
Memcached oczywiście! Ale nie do wszystkiego się nadaje. Być może mam za mało doświadczenia aby ten mechanizm w pełni wykorzystać.
Proszę bardzo: #lib/environment_ext.rb
if $0.index(‘rake’)
if loads = IO.popen(“uptime”).gets.match(/load average: (.), (.), (.*)/)
max_load = ENV[‘MAX_LOAD’].to_f > 0 ? ENV[‘MAX_LOAD’].to_f : 7.0
if loads[1].to_f > max_load || loads[2].to_f > max_load
puts “load average: #{loads[1]}, #{loads[2]} available load is #{max_load}”
puts “EXIT”
exit
end
end
end
if ENV[‘MAX_PROC’] && (max_proc = ENV[‘MAX_PROC’].to_i)>0
ps = IO.popen(“ps aux”)
procs = 0
while (line = ps.gets)
procs+=1 if line.index($0) && line.index(ARGV[0].strip)
end
if procs>max_proc
puts “#{procs-1} instances of #{$0} #{ARGV[0].strip} is running. MAX_PROC is #{max_proc}.”
puts “EXIT”
exit
end
end
Ważne aby wywołać ten kawałek kodu przed załadowaniem środowiska.
Teraz wpadłem na pomysł aby umieścić go na początku pliku Rakefile
2 sekundy z 5 (kolejne odswiezenie) to ladowanie obrazkow - moze jakies cache’owanie + CDN? Wszystkie wasze css i js mozecie ‘minify’ w locie, nie pamietam jak sie plugin od tego nazywal, ale jest taki. I wlaczcie gzip. Mysle ze na tym mozna obciac ponad polowe czasu (pomijajac wiszace requesty w railsach).
No i jeszcze mozna by np. strone glowna cache’owac na jakies 5 minut dla niezalogowanych, albo chociaz fragment cache. Z tego co widze to tylko pasek z ofertami jest dynamiczny - ekstremalnie mozna wrzucic wszystko do cache a oferty zaladowac ajaxem - wtedy wiekszosc glownej strony zaladuje sie bez dotykania railsow.
Najlepiej użyc sobie na gotowym projekcie YSlow (taki dodatek do firebug) lub coś podobnego i sprawdzić gdzie oblewamy i poprawić. Wstępnie pozwala poprawić wyniki.
Wstępnie powiem że dostała F u mnie a to gorzej się nie da. NIe popakowane CSS i JS i tak dalej, odpalić i sprawdzić -> poprawić, każdy wynik gorszy od A to źle jak dla mnie.
Tylko, że to co piszecie poprawia wydajność po stronie klienta a nie serwera. Skoro load na serwerze jest dosyć spory (6 to już trochę za dużo) to najpierw trzeba popracować nad wydajnością samej aplikacji railsowej, a gzipowanie, minimalizacja czy też cdn (tu już lekka przesada z tą sugestią) niewiele zmienią.
Macie albo strasznie wolną aplikację, albo na tyle popularną, że serwer już nie wyrabia. Powinniście przyjrzeć się wydajności samej aplikacji (zapytania, znaleźć wąskie gardło - nie zgadywać, a mierzyć), dopiero potem pomyśleć nad keszowaniem i być może nad silniejszym serwerem? Te skrypty w rake robią aż tak ciężkie operacje? Może powinny chodzić na gorszej, ale jednak osobnej maszynce.
Na forum jest ogłoszenie. Jak bardzo chcecie pomóc to wysyłajcie CV i do pracy - zachęcam :). gotar - praca w centrum Gdyni jest raczej atrakcyjna, nie musiałbyś nigdzie dojeżdżać ;-). Jeśli chodzi o wydajność serwery, backend processing to Morizon ma sąsiadów, którzy dobrze na tym się znają - nokaut.pl, trochę podpytają i dadzą rade. Jestem pewien, że opanują sytuacje.
Gzip poprawiony - nasza nieuwaga, nie był włączony dla application/x-javascript oraz text/css.
Jetem ciekaw, czy na obciążenie serwera ma wpływ gzip (spada teoretycznie transfer)?
Tak mamy wsparcie od chłopaków z Nokaut’u - pomagają nam przenieść się na nowe serwery.
Jak pisałem, głównym problemem są procesy eksportów które w nowej architekturze będą pracowały na oddzielnych maszynach.
Dla przykładu: otrzymujemy pliki zip (z xml i zdjęciami), które osiągają rozmiary do 10GB (20tyś zdjęć), samo rozpakowanie takiego archiwum zajmuje kilka minut, następne fazy to:
przetwarzanie xml
nadpisanie/dodanie ofert (to też dwa etapy ze względu na różne formaty danych wejściowych)
mapowanie lokalizacji np “gdynia, śródmieście blisko morza”
przetwarzanie zdjęć
geolokalizacja
Teraz się skupiamy na stronie frontendowej, co powiecie o nowej stronie głównej Morizon.pl
Mamy wsparcie specjalisty od usability, a już niedługo również od seo.
troche taki comeback NK, choć jeszcze oczywiście nie ta skala, ale już się wewnętrznie śmiejemy, że mistera Gąbkę trzeba zaprojektować na ruchliwsze momenty…