Aktualne i zaniechane kierunki rozwoju VIPserv.org.
Jeśli masz potrzeby techniczne nie wymienione na liście to napisz do nas.
- Sprzedaż domen
- Serwery VPS
- Serwery dedykowane
- Serwery ShoutCast (radio internetowe)
- Obsługa języka ASP
- Obsługa Java/JSP (Tomcat)
- Hosting Pylons
- Serwery gier
- Oferta resellerska
- APC, eaccelerator a także memcache
- memcache
- node.js
- Dodatkowe rozszerzenia PostgreSQL (np. postgis)
- mod_pagespeed
- Sprzedaż domen
Na chwilę obecną nie prowadzimy sprzedaży domen. Nasi klienci chcąc posiadać własną domenę muszą zakupić ją u dowolnego rejestratora następnie oddelegować na nasze serwery dns - więcej informacji
Rozważamy wejście na rynek rejestracji domen lecz wstępne badania wykazują że przychód z tego typu przedsięwzięcia nie był by duży, a problemy, koszty znaczne. Nasza energia prawdopodobniej będzie lepiej spożytkowana na dostarczaniu jak najwyższej jakości pozostałych usług.
- Serwery VPS
Na chwilę obecną prace nad udostępnianiem vps zostało zatrzymane. M.in. kończąca się ilość adresów IPv4 bardzo świadczenei tego typu usług.
- Serwery dedykowane
Nie planujemy rozszerzania oferty o serwery dedykowane.
- Serwery ShoutCast (radio internetowe)
Nie planowane. Do takich rozwiązań polecamy usługi VPS (nie ma w naszej ofercie).
- Obsługa języka ASP
Rozwój w tym kierunku został zaniechany z powodu braku możliwości uruchomienia takiego środowiska z różnymi prawami użytkowników bez dużego narzutu wymagań mocy obliczeniowej. Jeśli znasz rozwiązanie techniczne które pozwoliło by na takie wprowadzenie tej oferty to zapraszamy do kontaktu.
Do takich rozwiązań polecamy usługi VPS (nie ma w naszej ofercie).
- Obsługa Java/JSP (Tomcat)
Rozwój w tym kierunku został zaniechany z powodu braku możliwości uruchomienia takiego środowiska z różnymi prawami użytkowników bez dużego narzutu wymagań mocy obliczeniowej i braku możliwości szybkich restartów serwera tomcat, możliwości uruchamiania rzadko wywoływanych aplikacji bez ciąglego, nieproporcjonalnie ogromnego użycia pamięci.Jeśli znasz rozwiązanie techniczne które pozwoliło by na takie wprowadzenie tej oferty to zapraszamy do kontaktu.
Do takich rozwiązań polecamy usługi VPS (nie ma w naszej ofercie).
- HostingpPylons, plone, zope
Aplikacje pythonowe (np. django) hostujemy z użyciem mod_passenger (phusion passenger). Niestety mimo licznych testów nie udało się nam uruchomić pylons z passengerem, mimo stosowania się do tych zaleceń.
Na razie mało jest wiadomo o uruchamianiu pylons, plone, zope przez passengera. Powinno to być jednak możliwe przy użyciu odpowiedniego pliku config.ru który inicuje aplikację WSGI. Jeśli chcesz samemu spróbować utwórz przez nasz panel projekt django i zastąp w nim wszystko poza plikiem config.ru - który to trzeba odpowiednio edytować. Jeśli ci się uda napisz do nas.
- Serwery gier
Nie planowane. Do takich rozwiązań polecamy usługi VPS (nie ma w naszej ofercie).
- Oferta resellerska
Niestety nasz panel nie był projektowany z myślą o takim działaniu, więc wymagane będą większe zmiany w kodzie. Na chwilę obecną nie są prowadzone prace w tym kierunku.
- APC, eaccelerator, xcache (opcode cache dla php).
Tego typu systemy sprawdzają się dla serwisów które używają niewielkiej ilości kodu by serwować treść dużym ilościom ludzi - stronom o dużych natężeniach ruchu. Na hostingu współdzielonym wygląda to zupełnie inaczej - ogromna różnorodność oprogramowania i małe intensywności ruchu - tysiące stron na pojedyńczych maszynach.
Sprawdzaliśmy działanie APC. Po pierwsze apc nie może współdzielić cache między handlerami php sprawnowanymi przez menadżery procesów wbudowane w mod_fastcgi czy mod_fcgid. Istnieje możliwość wykorzystania menadżera z php-fpm lecz wprowadza on szereg innych niedogodności m.in. problemy ze swobodną definicją własnych php.ini oraz znaczne skopilowanie i zwiększenie narzutu przy udostępnianiu wielu wersji php jednocześnie (musieli byśmy zmuszą do upgrade-ów a tego robić nei chcemy). Istnieje także możliwość użycia mod_fastcgi z menadżerem procesów wbudowanym w php, lecz nie daje to możliwości dynamicznego spawnowania ilości handlerów (więc także odczytu o ich zajęciu) - tą opcję właśnie testowaliśmy.
W testach zapewniliśmy cache apc 32MB wszystkim klientom na serwerze i stałą liczbę 15 handlerów php na klienta (wspólny cache między nimi). Większość stron klientów miała hit ratio na cache <25% po godzinie działania. Użycie pamięci znacznie wzrosło (tak jak mówiliśmy - to jest dla bardzo dużych stron). Użycie procesora nieznacznie spadło, obserowany przez nas czas generacji stron nie uległ zmianie. Spadku użycia dysku (iops) nie zaobserwowaliśmy. Wnioski? Z coraz szybszymi procesorami współcześnie, proces kompilacji jest małym narzutem mocy (przynajmniej w php). Użycie dysku zmalało (a powinno) - zapewne ze względu na nieliniowośc zapisów i odczytów w nowoczesnych dyskach twarych z dużymi cache - dostęp do tablicy plików jest niemal tak samo szybki (bardziej wolny) jak dostęp do tablicy + odczytanie małego pliku. Głównym spowolnieniem generacji stron jest własnie dysk (oprócz samej konstrukcji aplikacji webowej). Dlatego używamy nośników ssd dla baz, a na dyskach z aplikacjami webowymi nie umieszczamy baz. Znaczny wzrost użycia pamięci RAM na cache (które i tak były skuteczne w mniej niż 25%) oznaczał by zwiększenie cen od 2 do 5 razy.
Podsumowując - dla małych i średnich serwisów to większy koszt niż zysk. - memcache
Podobnie jak w przypadku apc (opcode cache) są to systemy, które sprawdzają się dla dużych stron. W przypadku dobrego wykorzystania memcache można uzyskać dużo lepsze rezultaty niż przy opcache, ale to wymaga dobrej obsługi ze strony aplikacji i samej potrzeby w niej. Nie ma możliwości użwania memcache na naszych serwerach. Do tego polecamy usługi typu vps (nie ma w naszej ofercie).
- node.js
Otrzymujemy co jakiś czas zapytania o node.js od klientów. Klienci pytani do czego chcą użyć node.js odpowiadają że do niczego, chcieli by mieć taką opcje żeby sie pouczyć. Do nauki służy własny komputer, ew. z wirtualizacją jak VirtualBox.
Node.js na porcie wysokim - nie każdy użytkownik internetu ma możliwość łączenia się na wysokie porty.
Node.js na porcie 80 zza proxy - cała szybkość node.js zostanie zniwelowana przez użycie proxy.
Do takich rozwiązań polecamy usługi VPS (nie ma w naszej ofercie).
Dodatkowo projektowanie własnego serwera www na node.js to raczej "proof of concept" a nie coś co warto stosować.
- Dodatkowe moduły do PostgreSQL (np. postgis)
Zrezygnowaliśmy z udostępniania dodatkowych modułów do PostgreSQL. Powodowały one problemy przy aktualizacjach a także w środowisku współdzielonym stanową potencjalne luki bezpieczeństwa dla całego serwera. Do takich rzeczy polecamy serwery VPS (nie ma w naszej ofercie).
- mod_pagespeed
W sierpniu 2011 przeprowadziliśmy szereg transparentnych testów mod_pagespeed z udziałem wszystkich stron naszych klientów. Testy przeprowadzaliśmy z udziałem wszystkich filtrów oraz tylko z filtrem cache_extend. Testy wykazały:
- mod_pagespeed znacznie zwiększa obciązenie systemu dyskowego (2-4 krotnie). Jest to zapewne wynikiem kopiowania do cache dyskowego setek MB danych w ciągu minut.
- mod_pagespeed zwiększa użycie pamięci (ok. 500kB per handler) - nie tak dużo, ale jednak (na każdym procesie apache, nawet jeśli mod_pagespeed jest aktywny dla jednej z tysiąca domen).
- mod_pagespeed nie ma mechanizmu czyszczenia cache pamięciowego. Wyczyszczenie cache dyskowego per konto/domena można wymusić, ale w cache pamięciowym pozostają elementy. Cache oznacza że zmiany elementów statycznych jak css i js nie są widoczne nawet przez godzinę od dokonania zmian. Nie mamy wystarczającej mocy supportowej aby odpowiadać na liczne pytania "czemu mi się nie zmienia strona", nawet jak udostępnimy panel do czyszzczenia cache dyskowego.
Nie zamierzamy więc udostępniać mod_pagespeed w najbliższym czasie. Ceny naszych usług musiały by być wielokrotnie większe. mod_pagespeed to duża cena za wtórną optymalizacje w locie, tego co można także dokonać optymalizując samą aplikację. Nie tędy droga, należy optymalizować aplikację, a nie w locie, przy każdym zapytaniu, optymalizować to co ona serwuje.
Główna optymalizacja pagespeed to kompresja, która nie ma tak dużego narzutu mocy. Kompresja jednak nie jest niczym nowym i można ją włączyć u nas od dawna, w dziale "domeny i subdomeny > optymalizacje".
