gb1

@patryk ludzi z wiedzą zawsze brakuje więc jeśli ktoś chętny i rzeczywiście wiedzę posiada aby wnieść do r&d to polecam się i faktury przyjmę z chęcią :-) Znasz jakieś zestawienie które zawiera szersze informacje na temat udziałów w rynku tych podmiotów ? Przyznam że o części z wymienionych marek / podmiotów nawet nigdy wcześniej nie słyszałem. Nie twierdzę, że nie można prowadzić zyskownego lub dużego biznesu hostingowego bazując na standardowych panelach. Twierdzę jedynie, że taka sytuacja pokazuje świadomość techniczną, posiadaną wiedzę i chęć inwestowania w r&d przez dostawcę usługi. Ostatnio w celach poznawczych zakupiłem usługę u jednego z lokalnych dużych dostawców usług hostingowych, może mam za mała wiedzę ale trzykrotnie musiałem kontaktować się ze wsparciem aby ustalić dość podstawowe sprawy. Przyznam, że doświadczenie było dość traumatyczne i rozumiem dlaczego duża część klientów godzi się płacić stawki po promocyjne aby tylko nie przechodzić przez cały proces ponownie :-) Uprzedzając pytanie, to były trzy różne panele, każdy do czego innego, jednak widać, że po stronie dostawcy brak chęci do inwestowania w r&d w celu ujednolicenia całości choć patrząc na wyniki finansowe to środki posiada aby inwestować.

@Rafiki dużo słów, ale brak odpowiedzi. Pamiętajmy że wartość przychodów to tylko jeden z parametrów wyników finansowych. Tak na marginesie to jakieś 12 lat temu na wht była duża dyskusja na temat obrotów jednego z dostawców hostingu (także obecny na tym forum), nikt jednak nie zauważył że wynikało to z niestandardowej jednorazowej operacji nie związanej z podstawową działalnością :-) Jednak wrażenie było bardzo pozytywne dla większości :-)

Sam sobie odpowiedziałeś :-) Zgadzam się w całości, że rzetelne świadczenie usług wymaga odpowiedniej wiedzy, jednak patrząc na rynek to odnoszę wrażenie, że nie jest tak różowo jakby mogło się wydawać. Jednak posiadając wiedzę utrzymaniową korzystając ze standardowych paneli pozwala na świadczenie usługi na rozsądnym poziomie, jednak ograniczając ją do tego co panel pozwala oraz dynamiki rozwoju panelu. Posiadanie własnego oprogramowania wymaga znacznie wyższych kosztów oraz zasobów wiedzy na potrzeby r&d. Poprzez budowę własnych rozwiązań buduje się znacznie większą wartość wiedzy i doświadczenia, aniżeli wyłącznie świadcząc usługi na bazie standardowego oprogramowania.

Wskażesz gdzie widzisz te limity obecnie ? Przyznam że jeśli istnieją to tak dobrze schowali że nie potrafię ich znaleźć. Kiedyś znajdowały się w tabelce ze specyfikacją usługi, obecnie ich tam nie ma.

@patryk możesz wymienić te duże hostingi niemieckie wraz z porównaniem jakie udziały posiadają w rynku ? pozwoli to ocenić czy rzeczywiście co rozumiane jest przez "duże" z punktu widzenia lokalnego rynku w Niemczech ? przyznam że nie znam rynku niemieckiego zupełnie, zatem chętnie czegoś nowego się dowiem. Patrząc się jednak na dużych graczy światowych to nie widzę takich którzy korzystają ze standardowych paneli. Musisz przyznać, że świadczenie usługi za pomocą standardowego panelu nie wymaga zbytnio dużej wiedzy i świadomości technicznej, a tym bardziej nakładów na r&d.

@Rafiki dokonałeś stwierdzenia "OVH raczej nie musi się "odkuwać"", zatem byłem ciekawy czy takiego stwierdzenia dokonałeś na podstawie wiedzy która uzyskałeś z wyników finansowych wymienionej Spółki czy tylko na podstawie swojej subiektywnej oceny. Dwa razy unikałeś odpowiedzi na proste pytanie, zatem widocznie to druga opcja. Miałem nadzieję na bardziej merytoryczną dyskusję :-)

@Rafiki ciekawe podejście przedstawiasz, choć mało konkretne i zgodne z rzeczywistością. Tylko tak na marginesie należy dodać, że znajomość marki i wielkość firmy nie oznacza że nie muszą się "odkuwać". Dobrym przykładem jest Nokia. Wracając do meritum, widziałeś wyniki finansowe ?

Wiedza tajemna :-) podziela się zatem prywatnie :-)

Czytaj ze zrozumieniem :-) nigdy czegoś takiego nie twierdziłem. Podzielisz się pozostałymi ?

Czy to nie ilustruje wiedzę i chęć inwestowania w r&d przez lokalnych dostawców usług hostingu ?

a co z limitami ?

rozwiąż to lepiej zatem samodzielnie i będziesz miał problem rozwiązany. widziałeś ich wyniki finansowe że tak twierdzisz ?

W mainline nie ma, ale dwa różne podejścia od wielu lat są, jedno to port (chyba) z FreeBSD. Jeśli brakuje Tobie TRIM to stań się maintainerem :-) jestem pewien że przyjmą pomoc z otwartymi ramionami

https://jwt.io/ Pomyśl ile serwisów korzysta z tego rozwiązania rzeczywiście trzymając poufne dane w cookies.

Czyli jednak gra rolę czy aplikacja jest monolityczna czy rozproszona :-) Z powyższym się jak najbardziej zgadzam, jednak zaprzecza to Twojemu pierwszemu zdaniu. Jeśli jeden "node" w aplikacji się "crashuje" nie oznacza że socket na którym przyszło zapytanie musi zostać zwolniony, zatem monitorowanie tego socketu nie jest zbytnio istotne. Pamiętajmy jakiego konkretnego przypadku dyskusja dotyczy.

@Archi Według mnie to co sugerujesz jest naturalnym rozwiązaniem, jednak musisz przyznać że zadziwiające jest że obecne rozwiązanie które jest opisywane w przypadku tego wymienionego dostawcy jest dość kuriozalne i z mojego powodu mało przydatne do realnego wykorzystania. Pytanie pozostaje jedynie jaki procent użytkowników z tego segmentu zdaje sobie sprawę, że jakieś limity istnieją. Większość z nich nawet nie zbliży się zapewne do tych limitów. Pamiętajmy że usługa nie jest kierowana do jak to ująłeś "POWAŻNYCH" klientów biznesowych, większość z poważnych klientów biznesowych nie zawierzy swoich danych usłudze za kilka złotych miesięcznie czyli zapewne znacznie poniżej wartości obiadu który zjada przeciętny pracownik firmy. Inny segment rynku, inna oferta, inny odbiorca z innymi oczekiwaniami. Nie zgodzę się jednak z Tobą, że "POWAŻNY" klient godzi się na otrzymanie dodatkowych opłat, z mojego doświadczenia większość klientów woli wyższą wartość miesięczna ale stałą która w większości przypadków zaspokoi ich potrzeby. Według mnie rynek biznesowy w Polsce nie jest zbytnio gotowy mentalnie na zasadę elastycznych płatności od rzeczywistego wykorzystania jak w przypadku chmur publicznych typu Azure, GCE, czy AWS. Myślę że tutaj podajesz czas jedynie za pracę techniczne, pomijając wszelkie inne, a które zwykle zajmują znacznie więcej czasu. Ale szacunek za realne podejście przynajmniej w zakresie technicznym :-) Podzielam Twoje zdanie, ale jak widać rynek nie uważa tego za czynnik sprawiający że oferta jest odrzucana.

@mariaczi czystą ciekawością :-) choć także chęcią zweryfikowania lub potwierdzenia posiadanej wiedzy na temat tego segmentu rynku :-) Jaki według Ciebie poziom iops byłby dla takiej usługi odpowiedni ? Osobiście uważam że oferta jest ciekawa dla segmentu rynku do którego jest kierowana. Jedynie jej "wykonanie" jest niezwykle kiepskie co powoduje, że przestaje być interesująca do rzeczywistego zastosowania.

hmmm... ciekawe podejście, imho mało konstruktywne w dyskusji, ale jak widać podyktowane jedynie aspektem finansowym. Ja jedynie z ciekawości chciałem poznać Twoje zdanie ;-)

Tak aby struktury danych odpowiadały całości aplikacji. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Torvalds, Linus (2006-06-27)

@Archi zgadzam się z Tobą jednak bierzesz pod uwagę monolityczne aplikacje, trudno aby bardziej złożone aplikacje o architekturze rozproszonej się w taki sposób zachowywały Tak powinno być, jednak życie pokazuje że teoria znacznie różni się od praktyki :-)

Według Ciebie jaki poziom limitu iops byłby rozsądny ?

Według mnie gorsze jest to że dostawca nie udostępnia informacji o zużyciu limitu dziennego, użytkownik usługi dowiaduje się o wykorzystaniu limitu po wyłączeniu serwera. bardziej to jak tanio kupić udział w jeżdżeniu autem sportowym przez kilka godzin w miesiącu, a w pozostałym czasie zwykłym. Należy jednak pamiętać że to jest usługa kierowana do segmentu "lubię mieć możliwości" czyli usługa za przystępną cenę umożliwiająca posiadanie możliwości, oraz korzystanie z niej tylko przez ograniczony okres czasu, ponieważ przez większość nie ma potrzeby jej wykorzystywać. W usługach typu AWS, Azure czy GCE zasób dyskowy z gwarancją wykonania 10k iops kosztuje kilkaset razy więcej.

Rozwiązania widzę dwa: throttling - czyli ograniczenie parametrów lub płatność za wykorzystanie ;-) który bardziej przemawia do Twojego zastosowania ? Czy widzisz inne rozwiązania ?

Według Ciebie jak rozwiązane limity byłby rozsądne ?

Wszystko zależy od architektury aplikacji, jeśli składa się z licznych komponentów w formie subsystemów, mikroserwisów lub podobnych to część odpowiedzialna za otwarty socket jest tylko gatewayem, zatem jeśli inny komponent zwraca błąd lub jest "crashed" nie oznacza że musi zwolnić socket. Dobrym przykładem jest serwer http (np. apache lub nginx) i serwer aplikacji php działający osobno (w formie fpm lub podobnej). Błąd aplikacji lub serwera aplikacyjnego nie oznacza w takim przypadku konieczności zwolnienia socketu. Jednak coś czuję że to jest jednak aplikacja monolityczna :-)