Adam Szendzielorz
Donatorzy-
Postów
186 -
Dołączył
-
Ostatnia wizyta
-
Wygrane w rankingu
22
Ostatnia wygrana Adam Szendzielorz w dniu 21 Stycznia
Użytkownicy przyznają Adam Szendzielorz punkty reputacji!
Informacie firmowe
-
Firma/marka
Progreso.pl
-
Funkcja w firmie
Właściciel
Ostatnie wizyty
Blok z ostatnimi odwiedzającymi dany profil jest wyłączony i nie jest wyświetlany użytkownikom.
Osiągnięcia Adam Szendzielorz
-
Uczciwie byłoby wspomnieć ile było pozostałych "standardowych" zgłoszeń i w jakim czasie zostały obsłużone, bo stawia Pan naszą obsługę w bardzo złym świetle, a chyba nie jest tak źle - większość pozostałych zgłoszeń została obsłużona w ciągu maksymalnie kilku minut To w końcu temat z opiniami o nas.
- 57 odpowiedzi
-
- 2
-
-
- progreso
- progreso.pl
-
(i 1 więcej)
Oznaczone tagami:
-
Wykonałem dla p. Roberta mocno niestandardową rzecz u nas kilka miesięcy (a może lat?) wcześniej i teraz chciał cofnąć zmiany, których nikt w Helpdesku poza mną nie cofnie. A że w ostatnich miesiącach byłem mocno niedostępny to temat rzeczywiście ciągnął się bardzo długo. Moja wina i nauczka na przyszłość, żeby nie wychodzić poza schemat - ale człowiek chciał być dobry Nie mamy oczywiście absolutnie żadnych pretensji do p. Roberta - jego nasze wewnętrzne sprawy nie powinny interesować. Jak już zamkniemy temat to postaramy się choć trochę jakoś zrekompensować tę sytuację
- 57 odpowiedzi
-
- 3
-
-
- progreso
- progreso.pl
-
(i 1 więcej)
Oznaczone tagami:
-
Cześć, Zaraz sprawdzę w/w. Telefon działa cały czas -> 500 450 100 - działamy 24/h.
- 57 odpowiedzi
-
- progreso
- progreso.pl
-
(i 1 więcej)
Oznaczone tagami:
-
@Robert Przekaż proszę mi na priv login serwera - sprawdzimy, gdzie i dlaczego sprawa utknęła Codziennie odpowiadamy na ~100 zgłoszeń ze średnim czasem odpowiedzi na poziomie kilkunastu minut. Owszem - przy tej ilości zdarzają się sprawy, które ciągną się dłużej (szczególnie jeżeli chodzi o jakieś niestandardowe prośby / sprawy), jeżeli to była takowa - z góry przepraszam i obiecuję zająć się tym w pierwszej kolejności jak tylko dostanę login Całość korespondencji najlepiej kierować via helpdesk -> nowe zgłoszenie w panelu. Tylko tam dostęp do zgłoszeń ma cała ekipa progreso i tam odpowiedź będzie możliwie najkrótsza Pozdrawiam!
- 57 odpowiedzi
-
- progreso
- progreso.pl
-
(i 1 więcej)
Oznaczone tagami:
-
Rootnode był, jest i pozostanie niezależny - ustaliliśmy to już na samym początku jego tworzenia. "Dotacja" mogłaby być potraktowana przez każdą inną firmę występującą tutaj na forum jako swego rodzaju łapówka - "masz i zrób tam porządek" Nie, na pewno nikt tego z administracji rootnode'a nie zaakceptuje.
-
"Wszędzie dobrze gdzie nas nie ma" W Sopocie byłem kilka razy ale dawno temu. I byłem też w październiku zeszłego roku - zauroczyło mnie to miasteczko i to jak się zmieniło na przestrzeni lat. Jest naprawdę ładnie Coprawda spałem w łodzi zacumowanej przy słynnym sopockim molo, a nie w hotelu - może to wpłynęło na inną percepcję tego miejsca
-
Owszem, zgadzam się. Acz dalej stoję na stanowisku, że Vanilla Benchmark nie mierzy "szybkości serwera", a jedynie jeden z jego elementów (procesor). Porównywanie "szybkości hostingu" przez pryzmat tego benchmarku nie ma sensu. Zmierzyć należy wydajność w rzeczywistych warunkach (symulując realny ruch na stronie), a nie tylko pojedynczy komponent, wtedy test miałby sens. Pozdrawiam
-
Nie zgodzę się. Liczy się suma dostępnej mocy CPU, a nie wydajność pojedynczego CPU. Wydajność pojedynczego CPU ma znaczenie tylko jeżeli stronę odwiedza w jednej chwili tylko jeden użytkownik (jak wiemy PHP działa jednowątkowo i nie może "skorzystać" z dwóch lub więcej CPU jednocześnie). Ale w każdym innym przypadku - tj. jeżeli stronę jednocześnie ogląda dwóch lub więcej użytkowników - każdy ze skryptów jest przetwarzany przez inny proces PHP. Czyli dwóch użytkowników na stronie = dwa jednocześnie działające procesy PHP. Pięciu - pięć. Oczywiście limit child-procesów PHP to osobny temat ale w każdym normalnym środowisku produkcyjnym jest to zwykle conajmniej maksymalnie 10 child-procesów. Wtedy do akcji wkracza Linuxowy CPU Scheduler który dzieli dostępne zasoby CPU sprawiedliwie (lub według tego co ustawi administrator) na wszystkie działające procesy. I moc pojedynczego CPU przestaje mieć znaczenie. Bo dwa procesory o umownej mocy 80 jednostek każda wykonają dwa równolegle pracujące skrypty prawie 1,6 x szybciej (prawie, bo minimalna ilość mocy zostanie zmarnowana na context switch CPU) niż pojedynczy procesor o mocy 100 jednostek. Żeby potwierdzić moją pisaninę - zrobiłem kilka prostych testów wykorzystując skrypt Vanilla Benchmark uruchomiony na hostingu z 1 CPU, potem z 2CPU. Przy "concurrency level" 2 oraz 5 (czyli symulując dwóch oraz pięciu użytkowników na stronie). Oto wyniki: Server Software: Apache [...] Server Port: 80 Document Path: /benchmark.php Document Length: 3693 bytes 2 użytkowników na stronie: 1CPU: Concurrency Level: 2 Time taken for tests: 23.292 seconds Complete requests: 100 Failed requests: 0 Total transferred: 385000 bytes HTML transferred: 369300 bytes Requests per second: 4.29 [#/sec] (mean) Time per request: 465.838 [ms] (mean) Time per request: 232.919 [ms] (mean, across all concurrent requests) 2CPU: Concurrency Level: 2 Time taken for tests: 11.375 seconds Complete requests: 100 Failed requests: 0 Total transferred: 385000 bytes HTML transferred: 369300 bytes Requests per second: 8.79 [#/sec] (mean) Time per request: 227.503 [ms] (mean) Time per request: 113.751 [ms] (mean, across all concurrent requests) 5 użytkowników na stronie: 1CPU: Concurrency Level: 5 Time taken for tests: 19.626 seconds Complete requests: 100 Failed requests: 0 Total transferred: 385000 bytes HTML transferred: 369300 bytes Requests per second: 5.10 [#/sec] (mean) Time per request: 981.308 [ms] (mean) Time per request: 196.262 [ms] (mean, across all concurrent requests) 2CPU: Concurrency Level: 5 Time taken for tests: 9.348 seconds Complete requests: 100 Failed requests: 0 Total transferred: 385000 bytes HTML transferred: 369300 bytes Requests per second: 10.70 [#/sec] (mean) Time per request: 467.411 [ms] (mean) Time per request: 93.482 [ms] (mean, across all concurrent requests) Co wynika z testów? Że wydajność skryptu Vanilla Benchmark już przy dwóch użytkownikach jednocześnie na stronie jest wręcz liniowo zależna od sumy "mocy" CPU jaką mają do dyspozycji skrypty, a nie do wydajności pojedynczego CPU w serwerze. Oczywiście prędkość rdzeni CPU jest ważna - im są szybsze, tym strona będzie szybsza. Ale jak we wszystkim - zawsze mamy do dyspozycji jakiś ograniczony budżet. I moim zdaniem - trzeba w tym budżecie szukać sumy mocy jakie będziemy mieli do dyspozycji przez wszystkie dostępne CPU, a nie tylko patrzeć na szybkość pojedynczego rdzenia. Bo dwa 20% słabsze procesory nadal będą bardziej wydajne niż jeden szybszy. Środowisko webhostingowe jest mocno wielowątkowe - test Vanilla Benchmark wykonany na pojedynczym CPU nijak się ma do jego rzeczywistości. To jak silnik w samochodzie - Wy mierzycie i chwalicie się dużym ciśnieniem doładowania jednego cylindra, a użytkownika interesuje jeszcze ile tam łącznie jest garów R12 będzie zawsze lepszy od R4! Tyle ode mnie. Pozdrawiam
-
Prawda też jest taka, że ostatecznie liczy się przede wszystkim porządna optymalizacja aplikacji, serwera WWW i posiadane łącznie zasoby w danym budżecie. Benchmarkami możemy sobie mierzyć różne rzeczy na serwerze. I nawet jak nam wyjdzie CPU 2 x szybsze to dobrze optymalizując aplikację, czy serwer - możemy na tym słabszym CPU wyciągnąć 100 x większą wydajność. Owszem - optymalizując aplikację, czy serwer na hostingu z szybszymi CPU osiągniemy być może 2 x większą wydajność, ale waga samej optymalizacji w stosunku do np. prędkości CPU jest wielokrotnie większa Dodatkowo - serwisy WWW to środowisko stricte multi-user, więc jak w tym samym budżecie możemy dostać serwer z 2 x CPU, które mają np. 180% mocy szybszego ale pojedynczego CPU - to ostatecznie to dwuprocesorowe środowisko będzie dla strony bardziej wydajne (obsłuży więcej gości, mimo że w testach szybkości pojedynczego rdzenia, a chyba to właśnie robi Vanilla Benchmark - poprawcie mnie jeżeli się myle, wypadnie gorzej). Każdy wie do czego zmierzam więc pozdrawiam wszystkich
-
Wszystko się zgadza, był to normalny proces przekształcenia spółki cywilnej w spółkę kapitałową
-
Czy ja gdzieś napisałem, że progreso.pl jest średnią/dużą firmą i marką znaną mamie i żonie Łukasza? No nie jest. Więc nie wiem po co to porównanie
-
Uważam, że jest dużo wyższe prawdopodobieństwo, że mogą się zwinąć mając niski kapitał niż jakby mieli kapitał 10 baniek Bo to oznacza, że zaangażowanie środków w ten biznes był/jest taki sobie i w razie jakichś problemów nie ma nawet czego spieniężyć (oczywiście mogą mieć kapitał zakładowy 5k pln, a spółka może mieć majątek na 10 mln pln ale tego nie wiemy, a jakby mieli kapitał 10 mln - to byśmy wiedzieli, bo potwierdził to notariusz PS. W żadnym wypadku nie chcę szkalować tu Smarthost - z moich obserwacji są spoko firmą
-
Smarthost nie jest ani znaną (poza naszym hostingowym światkiem) marką ani średnią/dużą firmą. Istnieje też stosunkowo krótko. Pokaż markę, którą chociaż trochę kojarzy Twoja żona oraz Twoja mama i która ma kapitał 5k pln
-
Mam podobne zdanie - nie chodzi tu o żadne zabezpieczenie prawne (bo kapitał zakładowy to nie odłożone pieniądze na koncie jak niektórym się wydaje ale o samo podejście do biznesu. Znacie średnie / duże spółki, jakąkolwiek znaną markę, która ma kapitał 5k pln?
-
Panowie spokojnie Prawdą jest, że nie mamy aż tak rozbudowanego działu handlowego i większość sił ulokowana jest jednak w helpdesku. Mamy obecnie dość zwariowany okres (od 3 dni działamy w innej formie prawnej) i tysiąc różnych spraw na głowie, przez co odpowiedzi na niektóre pytania mogą się nieco opóźnić. Acz wydaje mi się, że mimo wszystko i wciąż - czasy reakcji i odpowiedzi są na wysokim poziomie :) Pozdrawiam!
- 57 odpowiedzi
-
- 7
-
-
- progreso
- progreso.pl
-
(i 1 więcej)
Oznaczone tagami:
