WordPress ma to do siebie, że nie dba zbytnio o ograniczenie zużycia pamięci. Niestety, przy dodaniu większej ilości wtyczek (większej niż 5-7) zaczynają się problemy z wykorzystanym limitem pamięci.

Błędy pojawiają się najprędzej w panelu administracyjnym, co czynnie uniemożliwia poprawną pracę z systemem.

[11-Sep-2009 15:35:01] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 170031 bytes) in /home/.../wp-includes/wp-db.php on line 501

Plugin WP-Memory-Usage pokazuje ile z dostępnej pamięci jest w użyciu.

Przyczyny

Co może być przyczyną takiego stanu rzeczy, i czy możemy coś z tym zrobić? Główną przyczyną jest funkcja inicjująca init oraz poprzedzające ją plugins_loaded i widgets_init. Funkcje te ładują do pamięci wtyczki oraz widgety, inicjują całą aplikację. Aby sprawdzić jak wygląda ładowanie strony pod względem wykorzystania pamięci możemy posłużyć się wtyczką WP Tuner. Po zainstalowaniu wtyczki przechodzimy do panelu zarządzania wtyczką wybieramy jedno z ustawień Presets: np Analyze Timing. Następnie otwieramy dowolną stronę panelu i przewijamy stronę do samego dołu: Jak widzimy na screenie ilość użytej pamięci skacze drastycznie do 26MB! po załadowaniu funkcji init do ponad 20MB tylko po załadowaniu pluginów! Dawno nie widziałem takiego marnotrawstwa pamięci

Rozwiązania

Możliwości rozwiązania problemu mamy kilka. Zacznijmy od najprostszych: zwiększenie limitu pamięci Jednak w przypadku, gdy nasz wordpress nie jest postawiony na dedyku mamy małą szansę na możliwość ingerencji w to ustawienie. Możemy napisać @ do admina. Jeśli natomiast mamy możliwość zmian konfiguracji możemy zastosować kilka wpisów: php.ini:

;; set new memory limit
memory_limit = 64M

.htaccess:

# set new memory limit
php_value memory_limit 64M

lub w php:

 // set new memory limit
ini_set('memory_limit','64M');

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Podczas pisania aplikacji internetowych ważną częścią projektu jest wiedza na temat działania owego produktu. Zdarzają się błędy wynikłe nie tylko ze złej implementacji, kodu aplikacji, ale także te niezależne od programisty. Mogą to być różnego rodzaju przerwy w działaniu innych serwisów, problemy z połączeniem internetowym, awarie. W takiej sytuacji bardzo przydatnym narzędziem jest możliwość logowania zdarzeń. W tym wpisie zajmę się opisaniem własnego pomysłu na klasę loggera.

Zacznijmy od założeń, wymagań stawianych takiej klasie.

• elastyczność
• możliwość umieszczania logów w różnych formatach, miejscach
• łatwość użycia
• umożliwienie szybkiej zmiany sposobu przechowywania

Zdarza się czasem, iż chcemy przechowywać logi w plikach, czasem w bazie danych. Nasza klasa powinna mieć możliwość łatwej zmiany silnika przechowywania logów oraz w miarę prostego sposobu przełączania się pomiędzy nimi.

Ewentualnie też, mogłaby mieć możliwość korzystania z kilku silników w jednym skrypcie. Ta opcja nie jest taka ważna, a na pewno nie jest koniecznością, jednak może się przydać w ekstremalnych sytuacjach. Załóżmy, że swoją klasę logowania ustawiliśmy na zapis do bazy. Co jednak w przypadku, gdy połączenie z bazą zostanie przerwane? W takiej sytuacji przydałoby się zapisać log w łatwiej dostępne miejsce – plik .log, .xml.

Aby móc korzystać z możliwości łatwego przełączania silnika loggera należy dobrze rozplanować struktury klas. Możemy skorzystać z klas abstrakcyjnych, interfejsów lub zwykłych klas. Aby zachować kompatybilność dodatkowych sterowników loggera postanowiłem oprzeć log class o interfejsy.

Jak podaje wikipedia: interfejs jest abstrakcyjną reprezentacją klasy pozwalającą na korzystanie z niej niezależnie od faktycznej implementacji.

Interfejs w PHP jest tak jakby tylko pomocnikiem dla programisty. Pokazuje jakie metody klasy implementujące muszą zaimplementować lecz sam ich nie udostępnia (w odróżnieniu od klasy abstrakcyjnej). Dla naszego zastosowania będzie to bardzo dobre rozwiązanie. Każdy rodzaj sterownika będzie dodawał zdarzenia do logów w inny sposób. Dodatkowo korzystając z interfesu będziemy mieli pewność, że dodatkowe sterowniki będą posiadały wymagane metody.

Jakie metody będą nam potrzebne? Jak dla mnie wystarczą 3 podstawowe: error();, warn();,info();. Schemat interfejsu będzie następujący:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<?php
/**
 * Interfejs dla klas logów
 * @author Vokiel
 * @package log
 */
interface log_log{
	/**
	 * Dodanie błędu do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function error($msg);
	/**
	 * Dodanie ostrzeżenia do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function warn($msg);
	/**
	 * Dodanie komunikatu informacyjnego do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function info($msg);	
}// end of logInterface
?>

Nasz interfejs posiada 3 metody do których przekazywany jest komunikat. Zapytacie czemu nie jedna metoda z flagą oznaczającą rodzaj komunikatu. Otóż wynika to z trzeciego punku założeń. Utworzyliśmy metody statyczne, dzięki temu będziemy mogli się do nich odwołać poprzez:

<?php
log::info('Wszystko ok');
log::error('Wszystko jak krew w piach!');
?>

Co dalej? W dalszych odcinkach zajmiemy się tworzeniem klas implementujących interfejs log_log oraz utworzeniem klasy trzymającej to wszystko w kupie.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Tak więc przez ostatnio miesiąc nauczyłem się dużo nowych rzeczy, i chciałbym się z Wami zdobytą wiedzą podzielić, a zaczął bym od stylu programowania, czyli standardów jakie sami sobie powinniśmy narzucić, by nasz kod był przejrzystszy i czytelniejszy nawet dla nas samych w późniejszym etapie rozwoju kodu.

Wcięcia Wcięcia powinny składać się z 4 spacji, tak spacje zamiast tabulatorów, dlaczego 4 a nie 2? Ponieważ wyraźnie zaznaczamy różnice w kodzie, i jest ona czytelniejsza dla naszego zmęczonego oka.

Składnia Zacznijmy od nazewnictwa zmiennych,

$someVariable

Tak pewnie zaraz zwrócicie uwagę mi że jest to cAmEl z Javy, i co z tego? :>

Funkcje i metody

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

someFunction($objTpl, $var) {
    // some part of code
}
 
class BigMama {
    public $variable;
    protected $_variable2;
    private $_variable;
 
    private function _setShowMeTrue() {
        $this->variable = true;
        return $this;
    }
 
    public function getShowMeTrue() {
        return $this->variable;
    }
}

Tak, nazwę klasy zaczynamy z wielkiej litery, nie robimy żadnych przerw pomiędzy nazwą a jej drugim członem tylko drugi człon z wielkiej litery. Metody w klasie protected oraz private, ich nazwy zaczynają się od dolnego podkreślenia. Z tym pod kreślnikiem to samo tyczy się zmiennych private oraz protected.

Warunek

1
2
3
4
5

if( $a == 0 ) {
    echo ':)';
} else {
    echo ':(';
}

Jak widać na załączonym obrazku, w warunku wyrażenie jest oddzielone od nawiasów spacją (białym znakiem), uwierzcie mi lub nie, ale to jest czytelniejsze!

String(c-string)

echo 'Some tekst is ' . $funnyImg . ' so much';

Widzimy że kropki łączące string są, pooddzielane spacjami (znów białe znaki) od apostrofu. Używanie cudzysłowu powinno być stosowane tylko w przypadkach koniecznych takich jak np znak nowej linii czyli \n

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Jak każdy tak i ja chcę swoje 3 grosze wrzucić do tego tematu, o czym chciałbym napisać, a o modelach, każdy dobrze wie czym jest mvc (nie czuje że rymuje), a jak nie to proszę wikipedia i tam jest bardzo ładnie opisane, tak więc co z tymi modelami, problem w tym że trzeba by te modele ładować w kontrolerach, albo przy dyspozytorze ładować kontroler, model i widok, ale można też to zrobić trochę inaczej, każdy kto się zdecydował na pracę z Doctrine, ma przecudowne narzędzie do utworzenia aplikacji zorientowanej obiektowo o wzorzec mvc, rozwiązującej problemy w pewnym stopniu z architekturą strukturalną plików i katalogów. A tak po ludzku to chodzi mi o to że Doctrine ładuje za nas modele bazy danych, czyli jak np za pomocą doctrine wygenerujemy modele z bazy danych, to Doctrine utworzy za nas 3 pliki dla każdej z tabel, oraz 1 katalog. Będzie to:

|--------------------------------
|- models/
|- - - generated/
|- - - - BaseArticles.php
|- - Articles.php
|- - ArticlesTable.php
|--------------------------------

A taki przykład, i teraz dzięki Doctrine, w kontrolerach będziemy mogli bezpośrednio odwoływać się do metod w pliku ArticlesTable, a to jest tylko przedsmak tego co dzięki Doctrine jesteśmy w stanie zrobić. Przy następnym wpisie pokażę jak tego użyć, jak to zrobić. Może sami macie jakieś ciekawe propozycje, pomysły, czekam