Tuesday, November 13, 2012

Индикатор загрузки данных

Мелочь а вечно не мог подобрать подходящий. Вот: (ajaxload.info) замечательный сервис для генерации разнообразных индикаторов.

Friday, July 6, 2012

yii + startup, история запуска и оптимизации

Некоторое время назад сработал проект выпущенный группой единомышленников с моим участием. (30к уников в день/200к страниц в день)

Приходилось сталкиваться с рядом проблем, хочется расказать о них, а также о решениях принятых в процессе разработки и поддержки.

1. В команде не было дизайнера/верстальщика, мы готовы были в целом их оплатить, но идея висела в воздухе, нужно было реализовать все крайне быстро.

В этом нам очень сильно помог twitter bootstrap framework, а также решение об использовании yii bootstrap extension. Не обладая внятными навыками в разработке интерфейсов мы смогли сделать достаточно простое приложение.

2. Ожидался минимальный функционал. Нужно было быстро разработать, а также иметь возможность развернуть на любом хостинге, сервера у нас не было.

Использование php + yii framework дало нам возможность реализовать прототип в предельно сжатые сроки. Это было действительно быстро.

3. Одна из основных фишек проекта, поиск по документам по ряду аттрибутов.

mysql + избыточность хранения данных, дали нам предельно быстрые выборки для небольших объемов данных. На текущем этапе смотрим в mongodb, теоретически это дает нам идеальный результат. Дело в том что аттрибуты для сущностей получаются в виде json, мы можем хранить готовые документы в mongodb в оригинальном виде, что заодно и решит проблему с версионностью документов.

4. Хранение файлов и место. Это одна из основных проблем, основная проблема в отстуствии прогнозируемых трат при использовании облачных хралищ данных.

Тут решения все еще нет :( Пока обходимся арендой сервера с большим дисковым пространством.

Все эти проблемы были встречены при разработке и особых проблем не вызвали. Самое веселое началось при росте посетителей.

5. Монетизация, хоть это и известно, но было неприятно понять на своей шкуре, что о монетизации нужно было заботиться заранее.

Пожертвования совсем себя не оправдали.

Баннеры кое как покрывали расходы на первый сервер. Эффективность крайне низкая.
Инвестиции от заинтересованных в развитии проекта лиц спасли его. Т.е. в общем случае мы могли вылететь в трубу.

1. База данных как всегда начала дохнуть первой.

При помощи memcached избавились от yii запросов к кэшированию схем таблиц, полностью были закешированы запросы к словарям ( они у нас практически не меняются). Это снизило нагрузку в два раза.

Далее шел вдумчиваый анализ каждой страницы, и рутинная работа по оптимизации запросов, изучения возможности их кэширования. После этого за базу данных мы были спокойны.

2. После того как разобрались с базой, имели большой load average и нагрузку на диски, думали это из за специфики сервиса, оказалось все до тривиального просто. Одно из расширений было включено в режиме дебага, а в этом режиме оно перезаписывало кучу assets'ов при каждом обращении к страницы. Это создавало дикую нагрузку на диск. Собственно запретив для него debug мы полностью решили свои проблемы.

3. У нас был мониторинг медленных запросов, он начал пухнуть, причем на операции которая по cron script обрабатывала документы, для построения ряда специфических поисковых таблиц. И эти операции лочили таблицы. Вместо того чтобы запускать его с определенной периодичностью отдавая небольшую пачку документов, мы перенесли его на время, когда пользователей на сайте практически нет, и заставили его обрабатывать все документы за день. Лог медленных запросов стал практически пустым. 4. Теперь у нас быстро генерировалась страница, но долго грузилась в браузере. Использование scriptMap + yiicomporessor решели проблему кучи js скриптов, а также их минимизации.

Использование yii extension contentCompresssor позволило ужать наш гигантский html до внятных размеров.

За счет этих простых триков, по версии google analytics мы ускорили время загрузки страницы с 5 секунд до 1й секунды.

Не знаю имеет ли смысл в этой статье без особых тех подробностей, но показал ход развития проекта и общие принятые решения. Мне было крайне интересно, а ведь будет еще интереснее :)

Меня очень порадовал тот момент, что я не оптимизировал проект заранее, я лишь имел представление о потолке наших возможностей и при приближении к нему проводил ряд оптимизаций, которые откатывали нагрузку на предыдущий уровень.

Monday, March 26, 2012

Мелочи для mysql консоли

Век живи век учись.

Поработав с postgres, понравилось отображение текущей базы данных в строке состояния консоли.

Вернувшись к mysql мне стало этого сильно не хватать. Но оказывается это делается очень просто.

В консоли ( или .bashrc ) устанавливаем нужную строку состояния, например

#export MYSQL_PS1="(\u@\h) [\d]> "

Запускаем клиента
#mysql

Получаем строку состояния вместо

mysql>

Вот такую

(USER@HOSTNAME) [DBNAME]>




ТАкже из консоли mysql можно узнать имя текущей базы при помощи запроса

mysq>select database();

Wednesday, August 24, 2011

Крик души, мнение о Zend Framework.

Меня тошнит от Zend Framework. Вот получили задание, переписать существующий сайт на Zend Framework. Задача не сложная, текущий код "портяночный", неправильный, там нет разделения логики от вида и т.д. Но вот я смотрю его, он простой, легко читаемый, прозрачный. Видно что его писал неглупый, возможно неопытный человек. Но в нем присутствует стройность. Более того, я считаю, что код вполне соответствует задаче.

И вот мы начинаем его переписывать. В своей жизни я создал порядка 5ти сайтов на ZF. Начинал еще с версии 0.6, потом 0.9, далее не помню. Тем не менее считаю что сам фреймворк не знаю абсолютно.

И вот как я представлю в какое умно все это превратится. И ведь даже выразить это невозможно.

Я уважаю Zend Framework как набор компонент, они удобны, хороши, просты, с ними мало проблем. И я удивляюсь, насколько убого создано то, что является MVC Framework'ом на основе этих компонент.

Ребята похоже заигрались в "крутых ооп" программистов. Все такое независимое, компонентное, легко расширяемое, маштабируемое и прочая, прочая, прочая.

Читаю последние обзоры, примеры мануалы. Я в шоке, там все такие крутые перцы. Сидят обсуждают преимущества и недостатки одних паттернов от других. Сервисный слой блять, бизнес логика, толстая модель, тонкий ибать контроллер, датамаппер, тейблгейтвей, иок. Я вот читая форумы обзоры флеймы аж вспотел, зачастую чтобы понять кого то мне приходилось освежать память.

Так сука и хочется спросить. Если вы такие умные хуле вы на пхп пишете?

Казалось бы нытье? Наверное да. Но вот открываю я quickstart zf. А конкретно http://framework.zend.com/manual/en/learning.quickstart.create-model.html вот этот раздел.

Нас в мануале учат что для работы с базой мы будем использовать DataMapper, который нам вернет модели, которые мы assign в темлейте и будем там использовать. Т.е. получается.

1. наследни DbTable
2. Кастомный DataMapper
3. Кастомная модель??? Структура с кучей геттеров.

Что я вижу?

1. Классы не требуются, т.е. это идет на уровне соглашения. Т.е. в мануале нам говорят как писать, но это не требуется, более того применения не будет.
2. Весь такой клевый гибкий ооп зенд, в своем мануале нам показывает как в DataMapper ОБЪЕКТ!! превращают в сырой массив (словарь,хэш) который передается дальше! Вообще в этом так то плохого ничего нет. Но как это делается!!!
 

foreach ($resultSet as $row) {
$entry = new Application_Model_Guestbook();
$entry->setId($row->id)
->setEmail($row->email)
->setComment($row->comment)
->setCreated($row->created);
$entries[] = $entry;

Что меня тут убивает. Вообще row я как понимаю инстанс Zend_Db_Tale_Row у котого есть метод toArray()

Application_Model_GuestBook в конструкторе может принимать массив значений.

т.е. написать $entries[] = new Application_Model_Guestbook( $row->toArray() ) ; Видимо религия не позволяет.

Ну конечно они возможно хотели показать как должны идти преобразования данных в том случае когда хранение данных отличается от доменной модели. Но ведь нет таких объяснений. И пример крайне неудачный. Даже далеко не у самых глупых программистов должен возникнуть простой вопрос. А на хрена?

Насколько пользователей нужно считать идиотами я даже не знаю. Конечно можно возразить что это мануал, а умный напишет как правильно, да блин 60% клинических идиотов потом так и будут писать. Вот в текущей задаче есть таблица на 40 полей. Конечно скорее всего база данных будет изменена, но блин вот напишут мне модельку из 40 геттеров, 40 сеттеров, 40 филдов. А потом внутри датамаппера 40 строчек сета, вот красота то будет. А потом ищи опечатку среди этого бардака.

Ну ладно так то мелочь и можно забыть, таки мануал и я 100% уверен что люди так не пишут. НО!!!

http://habrahabr.ru/blogs/zend_framework/123285/

Финиш. Все. Приплыли. Люди так пишут! Правда они умные, они блять парсят sql. И генерят код чтобы не опечататься.

У них ведь даже базовые классы появились :(

Бли до какой степени все убого, даже углубляться не хочется :( Как я люблю yii framework.

Ну вот получите
 

class I_Love_Zend_Naming_Huh_Model
{
protected $_properties = array();

protected $_data = array();

public function __construct(array $options = null )
{
if ($options !== null )
$this->fromArray($options);
}

public function __set($name, $value)
{
$this->__checkProperty($name);//check if property exists

$setterMethod = 'set'.$name;//buid setterName

if (method_exists($this, $setterMethod))// if setter exists
return $this->$setterMethod($value);//call it

$this->_data[$name] = $value;//no setter, remember data
return $this;
}

public function __get($name)
{
$getterMethod = 'get'.$name;

if (method_exists($this, $getterMethod))
return $this->$getterMethod();

if (key_exists($name, $this->_data))
return $this->_data[$name];

return null;
}

public function toArray()
{
return $this->_data;
}

public function fromArray(array $options)
{
foreach ($options as $key => $value)
$this->$key = $value;

return $this;
}

private function __checkProperty($name)
{
if (!in_array($name, $this->_properties))
throw new Exception('Undefined property ' . $name );
}

}


Вот сука нате, получите и распишитесь, тупорылая модель домена. Как использовать
 

class Super_Puper_Model extends I_Love_Zend_Naming_Huh_Model
{
protected $_properties = array('id', 'first_name', 'last_name');
}



Все бля работает. А как же ибать сеттеры? Вдруг я потом поменяю логику извлечения айдишника?

Да на те

 

class Super_Puper_Model extends I_Love_Zend_Naming_Huh_Model
{
protected $_properties = array('id', 'first_name', 'last_name');

public function getId()
{
return $this->first_name . $this->last_name;
}
}

Все, можете не париться, ваш код как вызывал $entity->id, так и вызывает, а поведение поменялось.

А мне в ответ: "Ага! У тебя волшебные методы, все пиздец приплыли тормоза!" А в мануале их бля нет....

Я еще про могучие плагины не рассказал, а инверсия зависимостей ага, работает. Хрен найдешь что вызывается на самом деле. Код нельзя прочитать! (Ну конечно можно, особенно с опытом) Но вот на yii я написал 3 сайта, и считаю что его уже знаю. А на zf 5 и считаю что его не знаю :(

Я не спорю что он крутой. Но такой некрасиый, такой нестройный. Такой не логичный. В yii framework достаточно понять смысл CComponent класс вроде из (40-100) строк, и дальше уже все понятно. А тут :(.

Да господи, они со своей гибкостью вообще шизданулись. Когда возникает вопрос зачастую находишь перлы, что нужно писать так, но это не работает поэтому вот такой грязный хак, другой пишет так незя писать нужно вот такой хак использовать. :(

Tuesday, March 29, 2011

yii, облегчаем прототипирование.

Введение



Я давно работаю с yii framework. И пока это единственный framework в мире php. Из минусов для меня то, что он слишком низкоуровневый, отсутствует много плюшек, которые я с успехом возмещаю разумным использованием Zend компонент. Как набор компонент Zend хорош, чего не скажешь о его framework'е.

Ну так вот, возвращаясь к низкоуровневому yii. Его CRUD хорош, хорош для прототипирования, но плодит кучу файлов. Многие из которых со временем вырезаются и сильно модифицируются. Моим кошмаром была работа на небольшим по объему backend проектом. Где вся работа сводилась к администрированию кучи таблиц с текстовыми и буленовскими полями. При помощи CRUD все было сделано быстро, но большую часть времени я потратил на украшение админки, checkboxes вместо input, фильтры вида true|false вместо 0,1 и тому подобной ерунды. Таблиц было много, view еще больше. Я с нежностью вспоминал django и жалел что проект на PHP.



Прошло время, и вот во время работы над очередным проектом выдалась несколько часов, в результате которых было рождено небольшое расширение над CRUD.



Краткая суть. CRUD очень похожи, и их можно объединить. Второй задачей является способ указания системе типов данных в моделях, для того чтобы CRUD мог на основе этих типов создавать фильтры, приводить к строковому виду автоматически.

Это получилось, пока начало, но проект не закончен. Но уже можно пользоваться.

Что получилось? Получился модуль который позволяет не запуская CRUD получить CRUD странички над любой моделью при условии что она отнаследована от особого ActiveRecord + в ней определен один единственный метод. В качестве небольшого бонуса есть простая возможность слегка менять список полей и их порядок на полученных страницах.


Ниже небольшой туториал как заставить это работать. Текста много, но он расчитан на новичка в yii. Если вы накоротке с yii можете сразу читать с установки модуля.



Инициализация yii проекта


Можно пропустить, если хотите воспользоваться существующим.
Описание как создать yii проект с нуля. Для того чтобы потом использовать модуль.


Создание директории проекта.



Я буду использовать локальный вебсервер, с дефолтными настройками. Проект создам в папке AdminTest внутри моего document root /var/www/

 
claymore:$ mkdir /var/www/AdminTest
claymore:$ cd /var/www/AdminTest/
claymore:$


Папка создана, скачиваем yii-framework
 
Среда 2011-03-30 11:03 box:/var/www/AdminTest
claymore:$ wget http://yii.googlecode.com/files/yii-1.1.7.r3135.tar.gz
--2011-03-30 11:12:58-- http://yii.googlecode.com/files/yii-1.1.7.r3135.tar.gz
Преобразование адреса yii.googlecode.com... 74.125.87.82
Устанавливается соединение с yii.googlecode.com|74.125.87.82|:80... соединились.
Запрос HTTP послан, ожидание ответа... 200 OK
Длина: 2550331 (2,4M) [application/x-gzip]
Saving to: «yii-1.1.7.r3135.tar.gz»

100%[=============================================================================================================================>] 2 550 331 780K/s в 3,2s

2011-03-30 11:13:01 (780 KB/s) - «yii-1.1.7.r3135.tar.gz» saved [2550331/2550331]

Распаковываем

claymore:$ tar xf yii-1.1.7.r3135.tar.gz

Переименовываем, или делаем символическую ссылку( кому как удобнее), я переименовываю, т.к. работаю в рамках демонстрации
   
claymore:$ mv yii-1.1.7.r3135 yii

Удаляю скаченный архив

claymore:$ rm yii-1.1.7.r3135.tar.gz

Проверяем что у нас есть распаковааная папка с yii framework

claymore:$ ls
yii

Переходим в папку со скриптами yii framework
 
claymore:$ cd yii/framework/

Запускаем скрипт создания проекта

claymore:$ ./yiic webapp /var/www/AdminTest/
Create a Web application under '/var/www/AdminTest'? [Yes|No] Yes
mkdir /var/www/AdminTest/css
generate css/form.css
generate css/main.css
generate css/bg.gif
generate css/ie.css
generate css/screen.css
generate css/print.css
mkdir /var/www/AdminTest/assets
mkdir /var/www/AdminTest/images
generate index.php
generate index-test.php
mkdir /var/www/AdminTest/themes
mkdir /var/www/AdminTest/themes/classic
mkdir /var/www/AdminTest/themes/classic/views
mkdir /var/www/AdminTest/themes/classic/views/site
mkdir /var/www/AdminTest/themes/classic/views/layouts
generate themes/classic/views/.htaccess
mkdir /var/www/AdminTest/themes/classic/views/system
mkdir /var/www/AdminTest/protected
mkdir /var/www/AdminTest/protected/data
generate protected/data/schema.sqlite.sql
generate protected/data/testdrive.db
generate protected/data/schema.mysql.sql
generate protected/yiic
mkdir /var/www/AdminTest/protected/messages
mkdir /var/www/AdminTest/protected/tests
mkdir /var/www/AdminTest/protected/tests/unit
mkdir /var/www/AdminTest/protected/tests/functional
generate protected/tests/functional/SiteTest.php
generate protected/tests/phpunit.xml
generate protected/tests/bootstrap.php
generate protected/tests/WebTestCase.php
mkdir /var/www/AdminTest/protected/tests/fixtures
mkdir /var/www/AdminTest/protected/tests/report
mkdir /var/www/AdminTest/protected/views
mkdir /var/www/AdminTest/protected/views/site
mkdir /var/www/AdminTest/protected/views/site/pages
generate protected/views/site/pages/about.php
generate protected/views/site/login.php
generate protected/views/site/index.php
generate protected/views/site/contact.php
generate protected/views/site/error.php
mkdir /var/www/AdminTest/protected/views/layouts
generate protected/views/layouts/column1.php
generate protected/views/layouts/column2.php
generate protected/views/layouts/main.php
mkdir /var/www/AdminTest/protected/runtime
generate protected/.htaccess
mkdir /var/www/AdminTest/protected/components
generate protected/components/Controller.php
generate protected/components/UserIdentity.php
mkdir /var/www/AdminTest/protected/config
generate protected/config/main.php
generate protected/config/test.php
generate protected/config/console.php
mkdir /var/www/AdminTest/protected/commands
mkdir /var/www/AdminTest/protected/commands/shell
mkdir /var/www/AdminTest/protected/controllers
generate protected/controllers/SiteController.php
mkdir /var/www/AdminTest/protected/models
generate protected/models/ContactForm.php
generate protected/models/LoginForm.php
mkdir /var/www/AdminTest/protected/extensions
generate protected/yiic.bat
generate protected/yiic.php
mkdir /var/www/AdminTest/protected/migrations

Your application has been created successfully under /var/www/AdminTest.
Среда 2011-03-30 11:03 box:/var/www/AdminTest/yii/framework
claymore:$

Проверяем
 
claymore:$ wget http://127.0.0.1/AdminTest/index.php -q -O - | grep Yii
....
Congratulations! You have successfully created your Yii application.
...

Создаем базу данных admintest. При помощи вашего любимого средства.
 
mysql> create database admintest;
Query OK, 1 row affected (0.02 sec)


Прописываем настройки базы данных в protected/config/main.php


Теперь у нас есть болванка для веб сайта на основе шаблона yii.



Установка модуля.



Переходим в директорию расширений. (Если пропустили первый шаг, замените /var/www/AdminTest/ на путь до папки вашего проекта, содержащей protected)


 
claymore:$ cd /var/www/AdminTest/protected/extensions/

Скачиваем расширение.


 
claymore:$ hg clone -q https://yii-rextensions.googlecode.com/hg/ YiisyCrudAdmin -r YiisyCrudAdmin

[Опционально] удаляем информацию о репозитории, особенно ваш проект уже под системой контроля версий.


 
claymore:$ rm -rf YiisyCrudAdmin/.hg
Среда 2011-03-30 11:03 box:/var/www/AdminTest/protected/extensions

Модуль установлен.



Пример создания crud административной страницы.


Для примера нам понадобится любая модель.


Создаем таблицу в созданной базе данных.


  
mysql> create table example(id int primary key auto_increment, name char(20), is_good_record tinyint(1) default 0 , long_description text);
Query OK, 0 rows affected (0.08 sec)

Переходим в папку protected


  
claymore:$ cd /var/www/AdminTest/protected

Создаем модель.


  
claymore:$ ./yiic shell config/main.php
Yii Interactive Tool v1.1 (based on Yii v1.1.7)
Please type 'help' for help. Type 'exit' to quit.
>> model Example example
generate models/Example.php
generate fixtures/example.php
generate unit/ExampleTest.php

The following model classes are successfully generated:
Example

If you have a 'db' database connection, you can test these models now with:
$model=Example::model()->find();
print_r($model);
>>

Модифицируем модель.


Цель. Отнаследоваться от расширения CActiveRecord объявленному в YiisyCrudAdmin.RActiveRecord. И реализовать абстрактный метод getFieldsDescription


Открываем /var/www/AdminTest/protected/models/Example.php в любимом редакторе


   
Yii::import("ext.YiisyCrudAdmin.RActiveRecord"); //Добавляем эту строчку импорта в верх файла.

В модель Example добавляем новый метод


   
Yii::import("ext.YiisyCrudAdmin.RActiveRecord");
class Example extends RActiveRecord
{
//...
// в последней версии данный метод не требуется в модели, может создаваться по желанию в классе ExampleAdmin
public function getFieldsDescription()
{
return array(
'is_good_record' => 'RDbBoolean',
'long_description' => 'RDbText',
);
}
//...
}

Этот метод предоствляет расширенную информацию о полях модели. На данный момент реализованы пока Bool и Text.


Т.к. метод абстрактный ( чтобы про него не забывали), реализация обязательна, метод может возвращать пустой массив если нет желания заморачиваться.


Создаем в вашем любимом редакторе controllers/ExampleController.php


    
Yii::import('ext.YiisyCrudAdmin.RController');
class ExampleController extends RController
{
protected $_modelName = 'Example';
}

Тестируем


Открываем в браузере http://127.0.0.1/AdminTest/index.php?r=example/admin


Получаем типичный yii crud с небольшими улучшениями.



  • Поля, отмеченные как boolean, отображаются в виде чекбоксов при редактировании. Также в наличии встроенный фильтр для этих полей на странице actionAdmin.

  • Текстовые поля при редактировании редактируются в textarea. При просмотре в griidview обрезаются. (Пока и в view обрезаются, но это уже решаемый вопрос :) )


Из плюсов такого подхода, все сделано стандартными средствами yii. Т.е. после этапа прототипирования, вы уже можете использовать существующую базу кода, достаточно заглянуть в RController


Гибкость, например в методе getFieldsDescription модели, элеметом массива может быть массив, формирующий CGridColumn, в этом случае все обрабатывается в обычном для yii ключе.


Улучшаем внешний вид


Как поменять порядок полей в actionAdmin ?


Прямо в файле модели создаем класс


    
Yii::import('ext.YiisyCrudAdmin.RModelAdmin');
class ExampleAdmin extends RModelAdmin
{
public function getAdminFields()
{
return array(
'name', 'long_description', 'is_good_record', 'id'
);

}
}

После этого в actionAdmin наблюдаем поля в указанном порядке

.

Как исключить поле из отображения в actionAdmin ?


   
Yii::import('ext.YiisyCrudAdmin.RModelAdmin');
class ExampleAdmin extends RModelAdmin
{
public function getAdminExcludedFields()
{
return array(
'id',
);
}
}

И это все. Оба метода можно комбинировать.



Ну и вот интерфейс RModelAdmin, отвечающий за порядок и отображаемые поля


  
public function getViewExcludedFields();// список полей для исключения в actionView

public function getAdminExcludedFields();//список полей для исключения в actionAdmin

public function getViewFields();// список полей для отображения в actionView

public function getSearchFields();//список полей для отображения в расширенной форме поиска actionAdmin

public function getAdminFields();// список полей для отображения в actionAdmin

public function getFormFields();// список полей для создания/редактирования.


Почему методы а не массивы? Например для динамической генерации в зависимости от условий.




UPDATED:


В последней версии метод getFieldsDescription перенесен из модели в ModelAdmin класс.

Thursday, August 26, 2010

Немного об оптимизации веб-сайтов. часть 1.

Большую часть работы я трачу на поддержку и развитие уже написанных сайтов. Немалую долю времени при поддержке приходится тратить на оптимизацию. Именное ей и будет посвящен набор статей виде отдельных историй об одном абстрактном программисте.


Этап 1 - становление.


Опыт 1.


Начинающий веб программист получает заказ на небольшой сайт. На удивление сайт завершен за 2 недели до сроков, даже с учетом затребованных изменений. Программист понимает что код его далек от идеала, многие вещи реализованы не оптимально. Принято решение заняться оптимизацией сайта. Сказал - сделал. Время генерации сайта до оптимизации 0.02 секунды, время генерации сайта после оптимизации 0.015 секунды. Т.е. страница генерируется на 25% быстрее. Итак по мнению программиста сайт обслужит на 25% больше пользователей.


Проверка.


Пусть следующий скрипт эмулирует сайт до оптимизации.



$echo “<?php usleep(20000);” > /var/www/site_before.php

А следующий после:



$echo “<?php usleep(15000);?>” > /var/www/site_after.php

Запускаем проверку.



$ ab -q -n 1000 -c 150 http://127.0.0.1/site_before.php | grep "Requests per second"
Requests per second: 64, 3[#/sec] (mean) (усреднено по трем замерам)


$ ab -q -n 1000 -c 150 http://127.0.0.1/site_after.php | grep "Requests per second"
Requests per second: 64 [#/sec] (mean) (усреднено по трем замерам)

Результат.


Прироста в 25% нет. Есть падение производительности в рамках погрешности.


Предположение.


При фиксированных параметрах веб серверва и физических ресурсах сервера есть некое пороговое значение времени выполнения процесса ниже которого оптимизация теряет смысл.


Подтверждение



$echo “<?php ” > /var/www/site_null.php
$ ab -q -n 1000 -c 150 http://127.0.0.1/site_null.php | grep "Requests per second"
Requests per second: 67 [#/sec] (mean) (усреднено по трем замерам)

Т.е. даже если убрать весь код из нашего проекта мы получим лишь 4% прирост производительности вебсервера.


Объяснение.


Пороговая производительность веб сервера при выполнении какой либо задачи напрямую связана с типом задачи. В нашем примере скорее всего значительную часть времени было потрачено на запуск интерпретатора, что составляло настолько большую долю в процессе отдачи страницы, что временем выполнения скрипта вообще можно было пренебречь.


Резюме.


При выполнении оптимизации вы должны быть четко уверены в том что она нужна.
Перед оптимизацией кода будьте уверены что проблема именно в нем. Есть много способов оптимизации сайта, которые не затрагивают исходные коды.


Мое мнение.


Вообще вывод тривиален, да, согласен. Но я склонен считать что этой ошибке подвержены все начинающие веб программисты. В целом нет ничего плохого в том, что делал наш абстрактный программист, он изучал возможности языка и это очень полезное качество. Вопрос тут в другом. Нужно правильно расставлять акценты. Не нужно подменять понятия. В своей жизни я видел задержки проектов по срокам, из-за подобной деятельности, при этом человек занявшись "оптимизацией" (на самом деле просто игрался), начинал сам верить что оптимизирует сайт и даже обижался когда ему указывали на срыв сроков. И начинал заговариваться утверждая, что его действия необходимы для поддержки и развития проекта. Начинающий программист должен понимать, что если он занимается оптимизацией, а никаких оснований для этого нет, то он просто изучает язык, приемы, но никак не улучшает конечный продукт.

 
Каталог сайтов, Добавить сайт