CT - Creative Technology

Category: webdevelopment

WARNING: MaxClients of xyz exceeds ServerLimit value of 256 servers

Jeśli przytrafia Wam się komunikat ostrzeżenia przy podnoszeniu/przeładowaniu Apache:

  1.  

to rozwiązanie jest prostrze niż się wydaje.
Najprawdopodobniej w konfiguracji serwera brakuje Wam dyrektywy ServerLimit lub jest ona umieszczona za MaxClients. Wtedy właśnie serwer przyjmuje dla ServerLimit domyślną wartość 256 i wyrzuca ostrzeżenie o limitowaniu MaxClients do tej wartości. Wystarczy wrzucić ServerLimit przed MaxClients i problem rozwiązany.

Przykładowa błędna konfiguracja:

  1.  

Przykładowa dobra konfigruracja:

  1.  

Strona galerii z dużą ilością ciężkich zdjęć, a problem wydajności

Dziś opisuję “od kuchni”  niektóre niuanse działania jednego z serwisów, którymi się opiekuję, tym samym odsłaniając niektóre z tajemnic.

Przygotowując nowe rozwiązanie na potrzeby Legionisci.com (czyli tak na prawdę doskonale znane kibicom – Legialive.pl), przypomnieliśmy sobie o pewnym problemie i mankamencie przeglądania dużych galerii pełnych zdjęć w wysokiej (jak na Internet) rozdzielczości.

Continue reading

O ZTM i o doładowaniu WKM słów kilka

Skuszony informacją, że spersonalizowaną Warszawską Kartę Miejską (WKM) można doładować online, postanowiłem olać kolejki w kioskach i spróbować. Wydawało się, że to dość banalna operacja, którą bez problemu powinien móc przeprowadzić przedszkolak, ale niestety w naszym kraju nic nie może być proste, oczywiste i działać od razu bez zarzutu. Cała historia chronologicznie wyglądała/wygląda (bo w sumie jeszcze z tym dziadostwem walczę) tak.

Wszedłem na stronę główną. Wszystko cacy i niby taka opcja jak zakup biletu online, z której ZTM żyje, powinna być w miarę na wierzchu. Niestety najpierw trzeba wyszukać zakup biletu, co powiedzmy jeszcze można przeżyć i jakaś logika w tym jest, choć nie ułatwia tematu szybkiego załatwienia sprawy. Niby micro fail, ale da się jeszcze przeżyć.
Tam już na dzień dobry widać naszą wymarzoną opcję – kup bilet on-line. Wchodzimy i mamy 2 opcje. Zalogowania się/rejestracji/przypomnienia hasła lub doładowania, poprzedzonego komunikatem “W celu dokonania zakupu biletu użytkownik musi być zalogowany w serwisie.”. I niby fajnie, tylko po co prezentować formularz umożliwiający doładowanie klientowi, który jeszcze nie jest zalogowany. Nie wczytując się w treść strony wyklikałem wszystko po kolei, wybrałem opcję płatności mTransfer i wszystko super, nawet dostałem numer transakcji i komunikat, że szczegóły przyjdą na email. Tylko chwila – na jaki email?? Przecież żadnego mojego emaila skojarzonego z numerem WKM jeszcze nie mają? Tutaj odnotowujemy FAIL NUMERO UNO.

Zważając na to, że ZTM chce jakoś to wszystko powiązać do kupy i potrzebuje mojego emaila, przystąpiłem do rejestracji. Mała dygresja – szkoda, że po FAIL NUMERO UNO tego nie zaproponowano i nie doprowadzono tamtej transakcji do końca. Wypełniam wszystkie dane niezbędne do rejestracji i na koniec, po długiej chwili mielenia (czyżby baza danych była niezoptymalizowana i były problemy z dodawaniem kolejnych identyfikatorów klientów?) dostałem info, żebym w skrzynce wypatrywał wiadomości email z aktywacją konta – “Na podany adres został wysłany e-mail, w którym znajduje się instrukcja dotycząca potwierdzenia rejestracji.”. Znowu wszystko cacy, tylko wypatruje go, wypatruje i wypatrzeć nie mogę. Uprzedzając ewentualne podpowiedzi – w SPAMie tej wiadomości też nie ma. Tu mamy FAIL NUMERO DUE.

Od dłuższego czasu nie widać emaila z danymi aktywacyjnymi, to ponawiamy rejestrację. Odziwo system nie ma problemu z przyjęciem tych samych danych rejestracyjnych, co poprzednio. Wychodzi na to, że konfliktu z duplikatem adresu email lub numerku WKM nie ma. Analizując jeszcze głębiej – można domniemywać, że pierwsza rejestracja nie zapisała się w bazie, system może nie mieć czego dalej procesować, a tym samym może nie mieć podstaw do tego, żeby wysłać do kogo kolwiek jaki kolwiek email. To był FAIL NUMERO TRE.

Kolejną przetestowaną funkcjonalnością było przywracanie hasła. Tradycyjnie podajemy email, na który, znów po długim mieleniu, powinniśmy dostać owe zapomniane hasło. Przez pierwsze 2-3 razy przypominanie działało i dostawałem info, że na skrzynkę trafi wiadomość ze szczegółami dalszych działań, które są konieczne do podjęcia. Po kolejnych próbach otworzenia/rejestracji zaczął się już regularnie pojawiać napis – “Nie powiodło się wysłanie hasła na wskazany adres.”. Oczywiście nie muszę chyba wspominać, że żaden email nadal nie dotarł? FAIL NUMERO QUATTRO.

Podejście kolejne to przeprowadzenie procesu rejestracji z IE, a konkretnie IE8, bo może faktycznie mój hi-security FireFox z Adblockiem, No-Scriptem, Permit Cookie i innymi patentami mogą coś mieszać w prawidłowym działaniu apli. Oczywiście, znów uprzedzając podejrzenia, przed całymi zabawami wszystko zostało ustawione na umożliwiające prawidłowe działanie witryny ZTMu i ich partnera rozliczającego transakcje online – DotPay.
Pod misiem (pieszczotliwa nazwa MSIE, czyli Internet Explodera) rejestracja na te same dane znowu przechodzi bez problemu. Odtwarzanie hasła za pierwszym razem też śmigało bez problemu. Tutaj mamy już FAIL NUMERO CINQUE.

W międzyczasie wpadłem na pomysł, czy jednak pomimo tego całego bajzlu, system na pewno zna już mój adres email. Wpisałem dla testu dupa@dupa.com i system takiego adresu nie znał – “Podany adres e-mail nie istnieje w systemie.”. Wpisałem ponownie mój pierwotny i ten już znał, nawet informując o wysyłaniu na niego, przez kilka pierwszych razy, stosownych danych. Tutaj w zasadzie bez FAILa 🙂

Idąc za ciosem, i na prawdę chcą naładować ten &#@%&@ bilet, postanowiłem wprowadzić małą niespodziankę do całego procesu – zmieniłem adres email 🙂 I co się okazało? “Wprowadzony numer karty istnieje już w systemie i został skojarzony z kontem innego użytkownika. Nie możesz dokonywać zakupów dla tej karty.”, czyli jak system chce, to jednak wie i ma zapisane co i jak. Pytanie, czemu pozwala rejestować się kilka razy na te same dane – tego pewnie się nie dowiemy. FAIL NUMERO SEI.

Żeby utwierdzić się w tym, że jednak jest jakiś fuckup z rejestracją, wybrałem opcję przypominania hasła. Po wpisaniu adresu email, na który rejestowałem się i po dlugim mieleniu (ach te kosztowne indeksy na właściwych kolumnach baz danych), dostaje info, że “Nie powiodło się wysłanie hasła na wskazany adres.”. Coś z tym przypominaniem jest nie halo, raz działa, raz nie – FAIL NUMERO ….. SETTE.

Suma sumarum – mail z:
1. aktywacją – brak
2. przypomnieniem hasła – brak
Do tego bilet wciąż nienaładowany, a fail goni faila.

PS Mała dygresja na koniec – pod IE8 w całym procesie widać jakieś błędy przetwarzania JS, ale już nie będę wnikał w mało istotne szczegóły.
PS2 Dzięki temu wpisowi poduczyłem się włoskich liczebników 😉
PS3 Jeśli udało Wam się doładować WKM przez net, to w komentarzu wpiszcie przepis 🙂

Hosting w godaddy, a problem Error 404 przy zastosowaniu mod_rewrite

Dziś na jednym z kont posiadanych w godaddy chciałem dopisać regułkę mod_rewrite. Wszystko super, tylko niestety na hostingu współdzielonym dostawca ma problem z regułkami. Nie mniej i na to znalazło się wyjście.

Zakładając, że nasza reguła znajduje się w subdomena.domena.pl/pierwszyFolder/drugiFolder/ i przykładowo plik .htaccess wygląda następująco:

  1.  

Powinno to zostać zastąpione przez:

  1.  

Już po komunikatach błędów widać, że niby ścieżka odwołania do docelowego pliku jest prawidłowa, a mimo to serwer ma problemy z jej znalezieniem. Dodanie RewriteBase je rozwiązuje.