exa

Wygodniej nauczyć się obsługi aptitude: http://www.linux-magazine.pl/issue/06/Cove...ry_aptitude.pdf

No racja, wypadałoby testować to samo distro przy takiej samej konfiguracji, albo przynajmniej serwery HTTP w tej samej wersji. No to i nawet przy ab wyników nie możemy porównywać.

Uważam, że panuje stereotypowe przekonanie, że tylko kompilacja ze źródeł jest pr0, a instalacja apache z paczki to z niewyjaśnionych (przynajmniej w tym topicu, oprócz argumentu o wydajności) przyczyn to zło i cienizna. Otóż jeżeli chodzi o stabilność, bezpieczeństwo i konfigurację (jeżeli nie potrzebujemy funkcjonalności niedostępnej w paczce, a tak jest w 99%) uważam, że instalacja z paczek jest jak najbardziej na miejscu. Na kompilację ze źródeł pozwolić sobie może tylko doświadczony administrator, który rozumie po co i dlaczego należy wstępną konfigurację serwera wykonać w taki a nie inny sposób. Etch to wersja stabilna i nie wyobrażam sobie upgrade do wersji testowej na serwerze produkcyjnym. Apache 2.2 i php5 to nie są starocie. Na serwerze produkcyjnym nie instaluje się najnowszego oprogramowania tylko pracuje się na znanych, oficjalnych i załatanych wydaniach. Po to jest standardowo dostępne repo security.debian.org z łatkami, żeby zapewnić maksimum stabilności i bezpieczeństwa. Kompilując usługi ze źródła w najnowszej wersji obniżamy bezpieczeństwo systemu jeżeli nie śledzimy na bieżąco bugtraq i nie kompilujemy za każdym razem całego środowiska. Szybciej pojawi siłę łatka w repo security (i wystarczy kilka sekund na instalację) niż poprawisz serwery rekompilując środowisko. Jest jeszcze kwestia wydajności. Kompilacja ze źródła może zrobić optymalizację pod nasz procesor, dając jak ktoś wspomniał 2-5% wydajności. Zawsze można zrobić rebuild paczki z deb-src. Czyli społeczność debiana, wydając kilka lat temu etcha do dzisiaj nie poprawiła błędów w paczkach, czy jak to inaczej rozumieć? Możecie rozwinąć?

ab do testów CPU jak najbardziej się nadaje. @p, widziałem na angielskim WHT temat o tym teście i jeżeli dobrze pamiętam, to generował load w granicach 12. Wygenerowanie takiego load na VPSie bez limitu CPU podejrzewam, że może grozić reakcją supportu i blokadą VPSa przynajmniej do wyjaśnienia.

apt-get install php5-xmlrpc

Prohost ma rację, do testowania wydajności CPU powinieneś przygotować mniejsze pętlę (żeby wykonywania skryptu trwało powiedzmy 1/100 sekundy) i uruchomić Apache Benchmark (ab) z opcją wykonywania dużej ilości równoległych połączeń (ab -n100 -c100 http://adres/skryptu.php). Nie wszyscy usługodawcy oferujący VPSy na ograniczają dostęp do rdzeni.

Dzięki za wyjaśnienie wyniku MT, bo byłem skołowany. Wygląda na to, że Wordpress to ślimak. Co do AB to jakoś nie mogę sobie wyobrazić sytuacji, w której ten test przekłamywałby wyniki. AB nie jest jakąś tylną furtką korzystającą z API apache, to zwykły program wysyłający/odbierający żądania HTTP do/od serwera. Wydaje mi się, że nie ma możliwości, żeby "dał ciała".

Ktoś korzysta? Jak się spisują VPSy? Chyba ceny ostatnio obniżyli, oferta wygląda bardzo atrakcyjnie a do tego niby gwarantują 99,8% uptime.

Sprawdź drugą opcję z http://www.cheapvps.co.uk/plans i poczytaj o ofercie +50% http://www.cheapvps.co.uk/specials.

Ktoś odważny ma u nich VPSa? Jeżeli tak, to jak długo, do czego używa i jak się ten VPS sprawuje?

Wynik: 1.83698 sekund. Wynik: 1.86398 sekund. Wynik: 2.05488 sekund. Wynik: 1.91418 sekund. ChaepVPS, Core2 Duo CPU E8400 @ 3.00GHz na pokładzie, bez limitu na procesor.

Mi działa i panel i VPS. Przecież hetzner nie rozdaje dedyków za darmo, musieli je opłacić. Ja dalej uważam, że nie opłacałoby się im w tym momencie zwinąć, bo niby na czym mieliby zarobić? Nie robili żadnej promocji dla płacących rok z góry, Czy może coś przeoczyłem.

Bo pewnie uczysz się ze starego kursu z czasów php 3 i chcesz odebrać zmienną w taki zapsób echo $miasto; zamiast echo $_GET['miasto']; Tu masz kurs: http://pl.wikibooks.org/wiki/Php. W ogóle z takimi pytaniami to powinieneś iść na formu webmasterów i nie WHT. [EDIT] hehe

A pisałem, żebyś nie zmieniał sendmail_path. RevDNS dla domeny zacznie działać poprawnie po max. 24 godzinach. Jeżeli poprawnie dopiszesz rekord SPF w DNS domeny to poczta będzie dochodziła na każdy serwer.

3 dni temu trafiłem na taki topic na WHT: http://www.webhostingtalk.com/showthread.php?t=727938. Sprawa się nie wyjaśniła a enno.pl podało, że drvps.net był tylko ich klientem (ale ktoś wcześniej wytknął, że obie domeny stały na jednym IP, ale już nie sprawdzimy czy w czasie sprzedaży kont czy po całej aferze właściciel drvps.net zrobił przekierowanie na enno, żeby zmylić trop). Mój VPS dalej działa i szczerze to nie chce mi się wierzyć, że ktoś budował sobie na tym forum prawie 2 tygodnie markę tylko po to, żeby naciągnąć ludzi na kilka złotych, w ogóle im by się to nie opłacało, więc poczekajmy na wyjaśnienia firmy. Może mają problem z hetznerem po ataku DDoS.

Jeszcze wczoraj o 23:15 w z logów wynikało, że postfix wysyła maile (ale SMTP o2.p ich nie chce odebrać bo brakuje revDNS dla twoje IP) a dzisiaj masz błąd z wywołaniem postfixa w ogóle. Wróć do takiej konfiguracji, jaką miałeś wczoraj i poproś firmę, u której kupiłeś serwer, żeby przypisała reverse DNS dla twojego IP o treści twojej domeny. Ewentualnie napisz co takiego pozmieniałeś w konfiguracji od wczoraj, jeżeli nie potrafisz tego naprawić.

/var/log/mail.* pokaż a nie logi apache. nie. Wywal exima (apt-get --purge remove exim4) i zainstaluj sobie postfixa wg. tego tutoriala: http://www.howtoforge.com/perfect_setup_debian_etch_p5 Przy generowaniu certyfikatów w polu "Common Name (your name):" wpisz nazwę swojej domeny (zapomnieli o tym wspomnieć w tutorialu). Do tego skonfiguruj sobie rekord SPF (a ja nie masz SPF to TXT) dla domeny o takiej treści: v=spf1 a include:twojadomena.pl ~all

Na swoim serwerze hostingowym w panelu klienta musisz skonfigurować zakupioną domenę. Następnie w panelu domeny musisz ustawić serwery DNS Twojego hostingu. Domena zacznie działać po około 24 godzinach.

Każda strona jest odbierana w jakimś kodowaniu (prawy przycisk myszy i "Pokaż informacje o stronie" dla Firefox). Ja się poddaję , podałem już wystarczająco dużo informacji, żeby poradzić sobie z polskimi znakami.

Każdy serwer współdzielony ma limity zasobów. Jeżeli ktoś został usunięty z hekko to na pewno jego strona generowała obciążenie przekraczające ustalone limity. Właściciel takiej strony pewnie na każdym współdzielonym hostingu dostałby informację, że powinien się przenieść na serwer VPS lub dedykowany.

Zalogowałeś się z konsoli do mysql i nie ma krzaków? A na stronie WWW są? To odszukaj w swoich skryptach linię mysql_connect grep -R mysql_connect /katalog/z/skryptem Dalej nie wiem jakie masz kodowanie w bazie docelowej/na stronie, więc zaraz za mysql_connect będziesz musiał wkleić albo wersję z latin2 albo utf8: mysql_query('SET NAMES latin2'); lub mysql_query('SET NAMES utf8'); Pamiętaj, że twoja strona www musi mieć takie samo kodowanie jak baza danych.

Ale namieszane . OK, najważniejsza jest informacja o kodowaniu pliku baza.sql. Wygląda na to, że jest to UTF8. Otwórz plik w edytorze obsługującym UTF-8 i sprawdź, czy polskie znaki wyświetlają się poprawnie. Jeżeli tak, to albo bazę wgrasz jako UTF8 albo przekonwetujesz ją na latin2 i dopiero wgrasz. Ale to nie koniec. Pokaż mi dowolną instrukcję TABLE CREATE (kilka linii, aż do średnika, część z nazwami pól możesz pominąć) z pliku baza.sql, bo zapisane domyślne kodowanie znaków może być błędne.

Witam, od kilku lat zajmuję się administracją pod systemem Debian, przenosiłem też dziesiątki baz danych pomiędzy różnymi wersjami serwera MySQL (od 3.x do 5.0). Jestem też programistą PHP, administracją i optymalizacją serwisów WWW zajmuję się na co dzień. Jeżeli jest Pan zainteresowany proszę wysłać na PW adresy sklepów, które mają zostać przeniesione oraz ewentualnie dodatkowe uwagi. Po przenosinach będzie mógł Pan sprawdzić działanie sklepów przez przepięciem domen na nowe serwery (o ile sklepy można uruchomić poprzez adres inny niż domena, pod którą stoją - tj. nie mają sztywnej licencji na domenę).

wykonaj komendę file na baza.sql, bo na 99% nie jest to latin1 (latin2 jak już, w latin1 nie zapiszesz polskich znaków): file baza.sql

Po pierwsze musisz włączyć mod_rewrite dla apache # a2enmod rewrite Po drugie musisz usunąć z /etc/apache2/sites-enabled/ istniejące dowiązanie symboliczne o nazwie 000-default . Błędy mogą być tylko wtedy, jeżeli masz w tym katalogu jeszcze inne wpisy.