Skocz do zawartości

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

Kolaborator

Kolaborator (7/14)

  • Stały gość
  • Reakcyjny
  • Dyskutant
  • Pierwszy post
  • Rozmówca

Najnowsze odznaki

172

Reputacja

  1. 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.
  2. 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ę
  3. Cześć, Zaraz sprawdzę w/w. Telefon działa cały czas -> 500 450 100 - działamy 24/h.
  4. @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!
  5. 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.
  6. "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
  7. 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
  8. 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
  9. 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
  10. Wszystko się zgadza, był to normalny proces przekształcenia spółki cywilnej w spółkę kapitałową
  11. 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
  12. 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ą
  13. 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
  14. 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?
  15. 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!
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.

Proszę nie wysyłać wiadomości na ten adres e-mail: [email protected]