Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 4236 сообщений
Cообщения с меткой

оптимизация - Самое интересное в блогах

Следующие 30  »
Akva_Marinka

Оптимизация!

Воскресенье, 21 Августа 2016 г. 20:18 (ссылка)

Это цитата сообщения Katra_I Оригинальное сообщение






Четыре пары (штуки?) джинсов на пятнадцати сантиметрах жилплощади. Это рекорд! Теперь в мой шкаф войдет тряпок в три раза больше!  И еще порядок



DSCI2149 (700x525, 418Kb)



Хотите так же? А вот...   



   

И дальше... Про носочки просто песТня!
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
s-postu

Модернизация заводов и автоматизация систем – разумное вложение денег » Креативный дизайн архитектурных сооружений | идеи дизайна, уникальные постройки, интересные памятники

Воскресенье, 21 Августа 2016 г. 11:29 (ссылка)
desibuilt.ru/639-modernizac...deneg.html

Модернизация завода? Очень разумное решение! Эволюция – это только благо, это широкий шаг к развитию и процветанию, это новые возможности и оптимизированные условия работы.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Когда стоит задуматься об оптимизации ИТ-инфраструктуры?

Среда, 10 Августа 2016 г. 17:10 (ссылка)

image

Думать об оптимизации никогда не рано и не поздно. Даже самая современная IT-инфраструктура уже завтра может не справиться со всеми возложенными на неё задачами. К тому же, оптимизация – это далеко не всегда приобретение новых активов, это в том числе и перевод части сервисов в публичные облака, и оптимизация IT-процессов, и тонкая настройка производительности существующих компонентов.



Задачи оптимизации



Главная задача оптимизации – обеспечение качественной и непрерывной работы бизнес-процессов с минимальными затратами на поддержку IT-инфраструктуры. Однако хотелось бы провести декомпозицию данной цели, чтобы можно было понять, за счёт чего могут быть достигнуты требуемые результаты.

Прежде всего, IT-инфраструктуру модернизируют для решения четырёх основных задач:



• непрерывность обслуживания;

• наращивание производительности (вычислительных мощностей);

• снижение стоимости поддержки;

• обеспечение информационной безопасности компании.



Данные задачи решаются за счёт достаточно широкого набора методов, которые можно условно объединить в группы:



image



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



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

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



Зачем нужно обследование?



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



image

Как вы можете видеть, прямой зависимости нет, поскольку автоматизируются бизнес-процессы за счёт различных программных управляющих комплексов (например, различные ERP-, CRM-системы). А вот уже сами программные комплексы зависят от существующей инфраструктуры напрямую.



Для одной системы наиболее критичными могут являться, к примеру, сети передачи данных, для другой – количество выделенных виртуальному серверу объёмов памяти и дискового пространства, для третьей – не столько объёмы выделенной памяти, сколько её быстродействие.



То есть для каждой автоматизированной системы механизм зависимости от используемого «железа» будет свой. Поэтому в первую очередь ключевой задачей оптимизации IT-инфраструктуры является понимание существующих взаимосвязей между конкретными компонентами вычислительных систем и обслуживаемых ими бизнес-приложений.



Прекрасно, когда эти взаимосвязи известны и постоянно поддерживаются в актуальном состоянии, но в большинстве случаев ситуация всё-таки далека от идеала. Часто решения об автоматизации того или иного бизнес-процесса принимаются в разное время и разными людьми, причём, как правило, при этом не проводится никакого анализа (или проводится минимальный) на соответствие существующей IT-инфраструктуры новым требованиям.



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

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



Подходы для решения задач оптимизации ИТ-инфраструктуры



Отказоустойчивость



Поддержание непрерывности работы всех автоматизированных бизнес-процессов, а значит, выход из строя какого-либо компонента IT-инфраструктуры не должен приводить к их деградации или же полной остановке. Это, в свою очередь, значит, что в IT-инфраструктуре не должно присутствовать единичных точек отказа (англ. SPOF – Single Point Of Failure).



image

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



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



Если, к примеру, львиная доля ваших продаж совершается через web-сайт, расположенный на вашей собственной вычислительной площадке, а соединение с сетью Интернет у вас не зарезервировано, то неполадки на линии приведут к серьёзным потерям для вашего бизнеса, следовательно, повышение отказоустойчивости интернет-соединения будет являться для вас высокоприоритетной задачей.



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



Катастрофоустойчивость



Часто бывает так, что отказоустойчивой инфраструктуры недостаточно для непрерывной работы бизнеса. Если, к примеру, ваш основной вычислительный кластер расположен в сейсмоопасном регионе, а построенный на нём программно-аппаратный комплекс управляет географически распределённым производством, то сам ЦОД (центр обработки данных) целиком становится единичной точкой отказа.



Таким образом, у вас появляется необходимость в создании резервной площадки, которая, в случае форс-мажора на первичном объекте, замкнёт на себя все необходимые бизнес-процессы.



image

Создание запасного ЦОДа всегда связано с серьёзными вложениями и высокими операционными расходами, поэтому необходимо чётко понимать, насколько данные инвестиции будут соизмеримы с возможными потерями, связанными с простоем в работе программно-аппаратного комплекса (ПАК) на основном объекте. По этой причине в качестве резервного ЦОДа очень часто используются арендованные вычислительные мощности специализированных сервис-провайдеров, а реально защищаются от возможных катастроф только самые необходимые сервисы и приложения.



Виртуализация IT-инфраструктуры



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



image

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



• повышение отказоустойчивости и катастрофоустойчивости;

• изоляция служб;

• возможность гибкого распределения ресурсов между службами;

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

• экономия места в стойках;

• снижение энергопотребления и тепловыделения;

• упрощение администрирования;

• широкие возможности по автоматизации развертывания и управления серверами;

• снижение вынужденных и запланированных простоев системы за счет failover-кластеров и live migration.



Организация «частных облаков»



Дальнейшим развитием технологий виртуализации является концепция «частного облака» (англ. Private Cloud), когда серверы объединяются в пул, из которого на решение определённых задач выделяются вычислительные ресурсы, не привязанные к конкретным физическим серверам. Такие облака строятся на базе ЦОДа компании, что позволяет сделать IT-услуги ещё более «эластичными», при этом, в отличие от использования публичных облачных сервисов, остаются полностью закрытыми все вопросы безопасности и соблюдения конфиденциальности данных, расположенных в частных облаках.



image

Гибридная IT-инфраструктура



Можно по-прежнему полагаться на собственную инфраструктуру, однако ресурсы на базе публичных облаков становятся более привлекательными вне зависимости от того, кто их предоставляет. Перенос части вычислительных мощностей в «облако» или расширение локальных мощностей за счёт ресурсов «облачных» провайдеров перестало быть чем-то экзотическим и в настоящее время является совершенно стандартной практикой.



image

Главным преимуществом данного подхода является возможность сэкономить (причём иногда весьма существенно) на развитии собственной IT-инфраструктуры.



В современных реалиях порой бывает очень сложно спрогнозировать реально необходимое количество ресурсов, особенно, если ваш бизнес подчинён некоторым сезонным пикам активности. С одной стороны, можно докупить необходимое количество оборудования и покрыть все потребности собственными ресурсами, но, с другой стороны, Вы будете вынуждены отдавать себе отчёт в том, что некоторые из ваших ресурсов будут простаивать большую часть времени (от пика до пика), создавая тем самым дополнительную финансовую нагрузку на денежные потоки компании.



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



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


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/307542/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Const и оптимизации в C

Воскресенье, 07 Августа 2016 г. 08:21 (ссылка)

Сегодня на /r/C_Programming задали вопрос о влиянии const в C на оптимизацию. Я много раз слышал варианты этого вопроса в течении последних двадцати лет. Лично я обвиняю во всём именование const.



Рассмотрим такую программу:



void foo(const int *);

int
bar(void)
{
int x = 0;
int y = 0;
for (int i = 0; i < 10; i++) {
foo(&x);
y += x; // this load not optimized out
}
return y;
}


Функция foo принимает указатель на const, который обещает от имени автора foo что значение x не будет изменено. Может показаться, что компилятор может предположить, что x всегда равен нулю, а значит и y тоже.



Однако, если мы посмотрим на ассемблерный код, генерируемый несколькими разными компиляторами, то увидим, что x загружается при каждой итерации цикла. Вот что выдал gcc 4.9.2 с -O3, с моими комментариями:



bar:
push rbp
push rbx
xor ebp, ebp ; y = 0
mov ebx, 0xa ; цикл по переменной i
sub rsp, 0x18 ; allocate x
mov dword [rsp+0xc], 0 ; x = 0

.L0: lea rdi, [rsp+0xc] ; вычисляем &x
call foo
add ebp, dword [rsp+0xc] ; y += x (не оптимизировано?)
sub ebx, 1
jne .L0

add rsp, 0x18 ; deallocate x
mov eax, ebp ; возвращаем y
pop rbx
pop rbp
ret


clang 3.5 (с -fno-unroll-loops) выдал примерно то же самое, только ebp и ebx поменялись местами, и вычисление &x вынесено из цикла в r14.



Неужели оба компилятора не способны воспользоваться этой полезной информацией? Разве если fooизменит x, это не будет undefined behavior? Как ни странно, ответ — "нет". В этой ситуации, это будет абсолютно верным определением foo.



void
foo(const int *readonly_x)
{
int *x = (int *)readonly_x; // cast away const
(*x)++;
}


Важно помнить, что const — не значит константный. Возьмите себе на заметку, что это неправильное название. Это не инструмент для оптимизации. Он нужен чтобы информировать программиста — а не компилятор — как инструмент, помогающий поймать определенный класс ошибок во время компиляции. Мне нравится, когда его используют в API потому что он сообщает, как функция будет использовать свои аргументы, или как вызывающий должен обращаться с возвращенными указателями. Обычно он недостаточно строгий, чтобы изменить поведение компилятора.



Несмотря на то, что я сказал, иногда компилятор может воспользоваться const для оптимизации. В спецификация C99, в §6.7.3¶5, есть одно предложение об этом:



Если сделана попытка изменить объект объявленный с модификатором const через использование lvalue без модификатора const, поведение неопределенно.




Исходный x был без модификатора const, поэтому это правило не применилось. И нет никакого правила против приведения к не-const типу, чтобы изменить объект который сам по себе не const. Это значит, что вышеприведённое поведение foo это не undefined behavior для этого вызова. Обратите внимание, что неопределенность foo зависит от того, как она была вызвана.



Одним изменением в bar я могу сделать это правило применимым, позволяя оптимизатору поработать.



    const int x = 0;


Компилятор теперь может предположить, что изменение x в foo — это undefined behavior, и потому никогда не происходит. Как бы то ни было, в основном так оптимизатор C рассуждает о ваших программах. Компилятор может предположить, что x никогда не изменяется, позволяя ему оптимизировать и загрузку в каждой итерации, и y.



bar:
push rbx
mov ebx, 0xa ; переменная цикла i
sub rsp, 0x10 ; allocate x
mov dword [rsp+0xc], 0 ; x = 0

.L0: lea rdi, [rsp+0xc] ; вычисляем &x
call foo
sub ebx, 1
jne .L0

add rsp, 0x10 ; deallocate x
xor eax, eax ; возвращаем 0
pop rbx
ret


Загрузка исчезает, y исчезает, и функция всегда возвращает ноль.



Любопытно, что спецификация позволяет компилятору пойти еще дальше. Он может разместить x где-нибудь вне стека, даже в read-only памяти. Например, он может произвести такую трансформацию:



static int __x = 0;

int
bar(void)
{
for (int i = 0; i < 10; i++)
foo(&__x);
return 0;
}


Или на x86-64 (-fPIC, модель малой памяти), где получается избавиться от еще нескольких инструкций:



section .rodata
x: dd 0

section .text
bar:
push rbx
mov ebx, 0xa ; переменная цикла i

.L0: lea rdi, [rel x] ; вычисляем &x
call foo
sub ebx, 1
jne .L0

xor eax, eax ; возвращаем 0
pop rbx
ret


Ни clang, ни gcc не заходят так далеко, видимо потому, что это более опасно для плохо написанного кода.



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


Original source: habrahabr.ru.

https://habrahabr.ru/post/307266/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kiev2376393

NVIDIA ищет пути оптимизации ВР-изображения

Пятница, 29 Июля 2016 г. 19:26 (ссылка)

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

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

JIT-компилятор оптимизирует не круто, а очень круто

Понедельник, 18 Июля 2016 г. 22:12 (ссылка)

Недавно Лукас Эдер заинтересовался в своём блоге, способен ли JIT-компилятор Java оптимизировать такой код, чтобы убрать ненужный обход списка из одного элемента:



// ... а тут мы "знаем", что список содержит только одно значение
for (Object object : Collections.singletonList("abc")) {
doSomethingWith(object);
}


Вот мой ответ: JIT может даже больше. Мы будем говорить про HotSpot JVM 64 bit восьмой версии. Давайте рассмотрим вот такой простой метод, который считает суммарную длину строк из переданного списка:



static int testIterator(List list) {
int sum = 0;
for (String s : list) {
sum += s.length();
}
return sum;
}


Многим Java-программистам известно, что этот код полностью эквивалентен следующему:



static int testIterator(List list) {
int sum = 0;
Iterator it = list.iterator();
while(it.hasNext()) {
String s = it.next();
sum += s.length();
}
return sum;
}


Разумеется, в общем случае в list может оказаться всё что угодно и поэтому JIT-компилятору придётся сгенерировать честные виртуальные вызовы на месте iterator(), hasNext() и next(), что, конечно, не очень быстро. Но что случится, если мы всегда будем вызывать этот метод, подавая ему на вход singletonList? Давайте добавим простенький метод main():



public class Test {
static int res = 0;

public static void main(String[] args) {
for (int i = 0; i < 100000; i++) {
res += testIterator(Collections.singletonList("x"));
}
System.out.println(res);
}
}


Здесь мы вызываем наш testIterator в цикле достаточное количество раз, чтобы скомпилировать метод JIT-компилятором C2. Как некоторые из вас уже знают, в виртуальной машине HotSpot есть два JIT-компилятора: C1 (клиентский) и C2 (серверный). В 64-битной версии Java 8 с настройками по умолчанию они работают совместно. Сперва метод компилируется с помощью C1 (который компилирует быстро, но создаёт не очень оптимальный код). При этом в код добавляются дополнительные инструкции, которые собирают некоторую статистику (это называется "профилирование"). Это, конечно, замедляет выполнение, но пригождается в дальнейшем. Среди различных профилей собирается профиль типов. В нашем случае JVM внимательно следит, какой тип имеет параметр list при каждом вызове. И тут виртуальная машина замечает, что в 100% случаев на входе был список типа Collections$SingletonList (который возвращает метод singletonList).



Когда количество вызовов метода достигает некоторого порога, метод перекомпилируется компилятором C2, которому доступен собранный профиль. C2 делает разумное предположение, что раз до сих пор всегда был SingletonList, то и далее он будет часто попадаться. А значит, iterator() точно вызовет метод singletonIterator(). Но там уже нетривиальный объект, который, к примеру, содержит поле hasNext, чтобы отследить, что его не вызвали дважды, и кинуть если надо NoSuchElementException. Способен ли C2 с этим побороться?



Чтобы узнать ответ, мы можем попросить JIT-компилятор вывести ассемблер сгенерированный для методов. Для этого нам потребуется установить hsdis. Потом можно воспользоваться удобными инструментами вроде JITWatch или написать JMH-бенчмарк и воспользоваться опцией -perfasm. Но здесь у нас пример простой, поэтому мы обойдёмся без сторонних инструментов и просто запустим виртуальную машину с такими волшебными параметрами:



$ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintAssembly Test >output.txt


Будьте осторожны: вывод этой команды может напугать маленьких детей. Но порывшись в нём, вы найдёте код, сгенерированный для нашего метода testIterator. Вот что сгенерировал C2 на платформе Intel x64 с кучей до 4 Гб:



Ассемблер, можно не вчитываться
  # {method} {0x0000000055120518} 'testIterator' '(Ljava/util/List;)I' in 'Test'
# parm0: rdx:rdx = 'java/util/List'
# [sp+0x20] (sp of caller)
0x00000000028e7560: mov %eax,-0x6000(%rsp)
0x00000000028e7567: push %rbp
0x00000000028e7568: sub $0x10,%rsp ;*synchronization entry
; - Test::testIterator@-1 (line 15)

0x00000000028e756c: mov 0x8(%rdx),%r10d ; implicit exception: dispatches to 0x00000000028e75bd
0x00000000028e7570: cmp $0x14d66a20,%r10d ; {metadata('java/util/Collections$SingletonList')}
0x00000000028e7577: jne 0x00000000028e75a0 ;*synchronization entry
; - java.util.Collections::singletonIterator@-1
; - java.util.Collections$SingletonList::iterator@4
; - Test::testIterator@3 (line 16)

0x00000000028e7579: mov 0x10(%rdx),%ebp ;*getfield element
; - java.util.Collections$SingletonList::iterator@1
; - Test::testIterator@3 (line 16)

0x00000000028e757c: mov 0x8(%rbp),%r11d ; implicit exception: dispatches to 0x00000000028e75c9
0x00000000028e7580: cmp $0x14d216d0,%r11d ; {metadata('java/lang/String')}
0x00000000028e7587: jne 0x00000000028e75b1
0x00000000028e7589: mov %rbp,%r10 ;*checkcast
; - Test::testIterator@24 (line 16)

0x00000000028e758c: mov 0xc(%r10),%r10d ;*getfield value
; - java.lang.String::length@1
; - Test::testIterator@30 (line 17)

0x00000000028e7590: mov 0xc(%r10),%eax ;*synchronization entry
; - Test::testIterator@-1 (line 15)
; implicit exception: dispatches to 0x00000000028e75d5
0x00000000028e7594: add $0x10,%rsp
0x00000000028e7598: pop %rbp
0x00000000028e7599: test %eax,-0x27b759f(%rip) # 0x0000000000130000
; {poll_return}
0x00000000028e759f: retq
... // дальше холодные пути


Первое, что бросается в глаза — это краткость кода. С вашего позволения я прокомментирую, что тут происходит:



// Стандартный стековый фрейм - подобным образом начинается всякий JIT-компилированный метод
mov %eax,-0x6000(%rsp)
push %rbp
sub $0x10,%rsp
// Загружаем идентификатор класса объекта из переменной list (указатель на объект пришёл в метод в регистре rdx).
// Идентификатор класса лежит в объекте по смещению 0x8. Это похоже на вызов list.getClass().
// При этом здесь происходит неявная проверка на null. Если окажется, что передали в метод null,
// процессор сгенерирует аппаратное исключение в связи с обращением по запрещённому адресу.
// Исключение перехватит виртуальная машина и заботливо транслирует его в NullPointerException
mov 0x8(%rdx),%r10d
// Сравниваем list.getClass() с идентификатором класса Collections$SingletonList. Этот идентификатор не меняется
// за время работы JVM и, конечно, JIT его знает, поэтому это просто сравнение с константой
cmp $0x14d66a20,%r10d
// Если list - это не SingletonList, выпрыгиваем на холодный путь
jne 0x00000000028e75a0
// Читаем приватное поле Collections$SingletonList.element в регистр rbp. Хотя указатели 64-битные, при размере кучи
// меньше 4 Гб верхние 32 бита всегда нули, поэтому виртуальная машина их не хранит и копирует только 32 нижних бита в ebp
mov 0x10(%rdx),%ebp
// Читаем идентификатор класса элемента и сверяем его с идентификатором класса String (аналогично тому, что выше)
mov 0x8(%rbp),%r11d
cmp $0x14d216d0,%r11d
// Если элемент списка - не строка, выпрыгиваем наружу на холодный путь (там будет создано и выброшено ClassCastException)
jne 0x00000000028e75b1
// Читаем приватное поле String.value в регистр r10. Это массив char[], в котором хранится сама строка
mov %rbp,%r10
mov 0xc(%r10),%r10d
// Читаем длину массива в регистр eax, который стандартно используется для передачи возвращаемого значения метода
mov 0xc(%r10),%eax
// Восстановление стекового фрейма
add $0x10,%rsp
pop %rbp
// Проверка на safe-point. С её помощь JVM может забрать контроль у скомпилированного кода, например, для сборки мусора.
test %eax,-0x27b759f(%rip)
// Выход из метода
retq


Если кому-то всё ещё сложно это понять, давайте перепишем на псевдокоде:



if (list.class != Collections$SingletonList) {
goto SLOW_PATH;
}
str = ((Collections$SingletonList)list).element;
if (str.class != String) {
goto EXCEPTIONAL_PATH;
}
return ((String)str).value.length;


Видите? На горячем пути нет ни цикла, ни выделения памяти под итератор, ни одного вызова метода. Всего лишь несколько разыменований и две быстрые проверки (которые всегда были ложны, поэтому предсказание ветвлений в процессоре отработает на ура). JIT-компилятор заинлайнил всё, что можно, понял, что итератор из метода не убегает, избавился от выделения памяти, развернул цикл и даже смог удалить флаг hasNext и связанные с ним проверки, статически доказав, что они не нужны! Сложение и переменная sum также испарились. И тем не менее, метод полностью корректен. Если окажется, что при следующем вызове ему передадут не singletonList, а что-то другое, он просто уйдёт на холодный путь (который, конечно, значительно медленнее). Остальные исключительные ситуации тоже обрабатываются. Можно передать null вместо list или подсунуть в список не строку (слава type erasure) — всё это будет обработано в соответствии с семантикой языка.



Что же произойдёт, если сценарий работы программы изменится? Предположим, через некоторое время мы вообще перестали передавать в этот метод singletonList и передаём теперь всякие другие списки. На медленном пути виртуальная машина продолжает собирать статистику. Если она обнаружит, что медленный путь происходит сильно часто, JIT-компилятор перекомпилирует метод, убрав специальную обработку singletonList и вставив сразу честные виртуальные вызовы. Может ещё, кстати, сделать две ветки, если вы используете только две разные реализации списков. Этим JIT отличается от приложений скомпилированных заранее: исполняемый машинный код вашей программы может меняться, следуя за изменениями в её поведении.


Original source: habrahabr.ru.

https://habrahabr.ru/post/305894/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ermolenko_ludmila

Тормозит компьютер. Программа для очистки компьютера за 1 клик WISE CARE 365 PRO

Среда, 06 Июля 2016 г. 07:05 (ссылка)






4877129__1_ (223x52, 2Kb)
Метки:   Комментарии (1)КомментироватьВ цитатник или сообщество
NetFact

Создание веб-интерфейсов с помощью HTML и CSS. Продвинутый интенсив (2015) Видеокурс » NetFact.Ru: Скачать бесплатно – Популярная Интернет Библиотека

Вторник, 05 Июля 2016 г. 17:17 (ссылка)
netfact.ru/videotech/2331-s...okurs.html


Создание веб-интерфейсов с помощью HTML и CSS. Продвинутый интенсив (2015) Видеокурс




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



Программа интенсива:



1 раздел: организация рабочего процесса (workflow)

*Как будет организован учебный процесс на интенсиве.

*Введение в Git.

*Обзор препроцессоров.

*Обзор систем сборки.

*Обзор средств автоматизации.

*Обзор других полезных инструментов (emmet, его аналоги, и др.).



2 раздел: методология

*Вёрстка независимыми блоками (БЭМ).

*Работа с инспектором.

*Методы поиска проблем.

*Как верстать, чтобы не ломалось.



3 раздел: препроцессоры, часть 1

*LESS.

*SASS.

*Stylus.

*И компания.



4 раздел: препроцессоры, часть 2

*Продолжаем разговор о препроцессорах.



5 раздел: адаптивность, сетки

*Резиновая вёрстка.

*Медиавыражения, брейкпоинты, принцип «перестройки сетки».

*Адаптивность с фиксированными сетками.

*Адаптивность с резиновыми сетками.

*Подходы: от простой сетки к сложной, от сложной к простой.

*Обзор flexbox.



6 раздел: адаптивность, графика, типографика

*Адаптивные графика и медиаконтент.

*Оптимизация графики.

*Ретина.

*SVG.

*Иконочные шрифты.



7 раздел: фреймворки

*Bootstrap и сотоварищи.

*Если вы решили создать свой фреймворк?



8 раздел: прикладной javascript, часть 1

*Улучшаем UX с помощью скриптов.

*Ajax.

*Весёлые анимации, трансформации.



9 раздел: прикладной javascript, часть 2

*Продолжаем разговор о javascript.



10 раздел: введение в автоматизацию

*Проверка кода.

*Оптимизация кода.

*Оптимизация графики.

*Сборка.







Создание веб-интерфейсов с помощью HTML и CSS. Продвинутый интенсив (2015) Видеокурс Создание веб-интерфейсов с помощью HTML и CSS. Продвинутый интенсив (2015) Видеокурс Создание веб-интерфейсов с помощью HTML и CSS. Продвинутый интенсив (2015) Видеокурс






Информация о видеокурсе

Название: Создание веб-интерфейсов с помощью HTML и CSS. Продвинутый интенсив

Автор: Александр Першин., Николай Громов, Алексей Симоненко

Год выхода: 2015

Жанр: Видеокурс

Выпущено: HTML Academy

Продолжительность: 19:59:33



Файл

Формат: MP4 (+ доп. материалы)

Видео: AVC, 1152х720-1728х1080, ~200-705 Kbps

Аудио: AAC, 160-256 Kbps, 48.0 KHz

Размер файла: 5.82 Gb



Скачать: Создание веб-интерфейсов с помощью HTML и CSS. Продвинутый интенсив (2015) Видеокурс



Скачать | Download | TurboBit.net

http://turbobit.net/pngvfbnthxf1/prodvin.intensiv.rar.html



Скачать | Download | HitFile.net

http://www.hitfile.net/EDgdWyQ/prodvin.intensiv.rar.html



Скачать | Download | Файлообменник.рф

http://файлообменник.рф/6x9wgo5ox5ak/prodvin.intensiv.rar.html

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Оптимизация веб-сервиса подсказок для почтовых адресов и ФИО

Пятница, 01 Июля 2016 г. 21:13 (ссылка)

В данной статье я хотел бы поделиться опытом разработки веб-сервиса на C++. На мой взгляд, это достаточно интересная тема, поскольку использование C++ для веб-разработки — вещь редкая и зачастую вызывает в ИТ-кругах недоумение. В Интернете можно найти много аргументов не в пользу данного подхода. Использование указателей, утечки памяти, сегфолты, отсутствие поддержки веб-стандартов «из коробки» — вот неполный перечень того, с чем нам пришлось ознакомиться прежде, чем принять решение о выборе данной технологии.



Разработка, о которой идет речь в данной статье была выполнена в 2015 году, однако предпосылки к ней появились значительно раньше. Все началось с того, что в 2008-ом году у нас возникла идея разработать веб-сервис по стандартизации и исправлению пользовательских контактных данных, таких как почтовые адреса и номера телефонов. Веб-сервис должен был получать посредством REST API контактные данные, которые указал некий пользователь в произвольном текстовом виде, и приводить эти данные в порядок. По сути, сервис должен был решать задачу распознавания пользовательских контактных данных в произвольной текстовой строке. Дополнительно в ходе такой обработки сервис должен был исправлять опечатки в адресах, восстанавливать пропущенные компоненты адреса, а также приводить обработанные данные к структурированному виду. Сервис разрабатывался для нужд бизнес-пользователей, для которых корректность клиентских контактных данных является критичным фактором. В первую очередь это интернет-магазины, службы доставки, а также CRM и MDM системы больших организаций.



В вычислительном плане поставленная задача оказалась достаточно тяжелой, поскольку обработке подлежат неструктурированные текстовые данные. Поэтому вся обработка была реализована на C++, тогда как прикладная бизнес-логика была написана на Perl и оформлена в виде FastCGI-сервера.



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



Обработка в реальном времени



Формирование подсказок в режиме реального времени подразумевает, что сервис получает от пользователя новый HTTP-запрос всякий раз, когда тот вводит очередной символ почтового адреса или ФИО в процессе заполнения некоторой формы с контактными данными. В рамках запроса сервис получает текстовую строку, введенную пользователем к настоящему моменту, анализирует ее и формирует несколько наиболее вероятных вариантов ее автодополнения. Пользователь видит полученные от сервиса подсказки и либо выбирает подходящий вариант, либо продолжает ввод. В реальности это должно выглядеть примерно следующим образом.







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



Для оценки приемлемого времени отклика мы провели ряд экспериментов с регулируемой задержкой. В результате чего пришли к выводу, что подсказки перестают быть полезными, когда время отклика начинает превышать 150 мс. Наша исходная архитектура сервиса позволяла оставаться в этих рамках при одновременной работе 40 пользователей (эти показатели получены для сервера с двумя ядрами и 8Гб ОЗУ). Для увеличения этого числа необходимо наращивать количество процессоров у серверного железа. А поскольку функции подсказок для почтовых адресов и ФИО разрабатывались для их свободного использования всеми желающими, мы понимали, что процессоров и серверов может потребоваться значительно больше. Поэтому возник вопрос о том, нельзя ли оптимизировать обработку запросов за счет изменения архитектуры сервиса.



Исходная архитектура



Архитектура сервиса, которую нужно было улучшить, имела следующий вид.







Согласно данной схеме, пользовательское приложение (например, веб-браузер), генерирует HTTP-запросы, которые получает веб-сервер (в нашем случае используется легковесный веб-сервер lighttpd). Если в запросах имеем дело не со статикой, то они транслируются серверу приложений, который соединен с веб-сервером посредством FastCGI интерфейса (в нашем случае сервер приложений написан на Perl). Если запросы касаются обработки контактных данных, то они передается дальше серверу обработки. Для взаимодействия с сервером обработки используются сокеты.



Можно заметить, что если в данной схеме заменить сервер обработки на сервер БД, то получится достаточно распространенная схема, применяемая в традиционных веб-приложениях, разрабатываемых с использованием популярных фреймворков для Python или Ruby, а также для PHP под управлением php_fpm.



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







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



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



Далее запрос проходит через сервер приложений. На это тратится дополнительные 20% времени. В нашем случае никакой обработки запроса сервером приложений не выполняется. Приложение лишь выполняет парсинг HTTP-запроса, передает его дальше серверу обработки, получает от него ответ и передает его обратно FastCGI интерфейсу. Фактически 20% времени уходит на парсинг запроса и на издержки интерпретатора, поскольку приложение реализовано на скриптовом языке.



Еще 20% времени уходит на прохождение данных через сокетный интерфейс, который используется для связи приложения с сервером обработки. Этот интерфейс работает чуть быстрее, в сравнении с FastCGI (20% против 25%), поскольку соответствующий протокол и его реализация значительно проще. Обработка самого запроса, заключающаяся в формировании подсказок для введенных пользователем данных, отнимает лишь 10% от всего времени (в тестах использовался один из самых тяжелых, с точки зрения обработки, запросов).



Хотелось бы подчеркнуть, что вся специфика нашей задачи в проведенных экспериментах проявляется лишь на последней стадии и именно эта стадия, с точки зрения производительности, вызывает меньше всего вопросов. Остальные этапы весьма стандартны. Так, мы используем событийный веб-сервер, который просто извлекает полученный запрос из одного сокета, ассоциированного с прослушиваемым HTTP-портом, и кладет эти данные в FastCGI-сокет. Аналогично сервер приложений – извлекает данные из FastCGI-сокета и передает их сокету сервера обработки. В самом приложении оптимизировать по большому счету нечего.



Удручающая картина, при которой лишь 10% от времени отклика приходится на полезные действия, заставила нас задуматься о смене архитектуры.



Новая архитектура сервиса



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



Событийный сервер приложений



В рамках данного варианта была рассмотрена возможность реализовать событийный сервер приложений, например, на Node.js или Twisted. В такой реализации количество сокетных интерфейсов, через которые проходят запросы, остается прежним, поскольку каждый запрос поступает на балансирующий веб-сервер, тот передает его одному из экземпляров сервера приложений, который в свою очередь транслирует запрос серверу обработки. Суммарное время обработки запроса остается прежним. Однако число одновременно обрабатываемых запросов увеличивается за счет асинхронного использования сокетов. Грубо говоря, пока один запрос находится в процессе перехода через сокетный интерфейс, другой запрос может проходить через бизнес-логику приложения в рамках того же экземпляра.



От данного варианта реализации пришлось отказаться, поскольку мы посчитали неоправданным реализацию полностью асинхронного приложения лишь ради устранения одного узкого места в старой архитектуре – сокетного интерфейса между приложением и сервером обработки. Остальные операции ввода-вывода, такие как журналирование, фиксация пользовательской статистики, рассылка почты и взаимодействие с другими сервисами в старом приложении выполнялись отложенно в отдельных потоках, поэтому асинхронности не требовали. Кроме того, данная архитектура не позволяет сократить время обработки единичного запроса, так что пользовательские приложения, работающие с сервисом через API, прироста в производительности не получат.



Интеграция приложения и веб-сервера



Здесь была рассмотрена реализация приложения в виде Java-сервлета или .Net приложения, который напрямую вызывается веб-сервером. В этом случае удается избавиться от FastCGI интерфейса, а заодно от интерпретируемого языка. Сокетный интерфейс с сервером обработки сохраняется.



На принятии решения не в пользу данного подхода сказалась привязка всего решения к конкретному веб-серверу, который должен поддерживать выбранную технологию. Например, Tomcat для Java-сервлетов или Microsoft IIS в случае использования .Net. Нам хотелось сохранить совместимость приложения с легковесными серверами lighttpd и nginx.



Интеграция приложения с сервером обработки



В данном случае привязки к конкретному веб-серверу нет, поскольку интерфейс FastCGI сохраняется. Приложение реализуется на C++ и объединяется с сервером обработки. Таким образом, мы уходим от использования интерпретируемого языка, а также устраняем сокетный интерфейс между приложением и сервером обработки.



К недостатку данного подхода можно отнести отсутствие достаточно популярного и обкатанного на больших проектах фреймворка. Из кандидатов мы рассматривали CppCMS, TreeFrog и Wt. По части первого у нас возникли опасения на счет будущей поддержки проекта ее разработчиками, поскольку свежих обновлений на сайте проекта давно не было. TreeFrog базируется на Qt. Эту библиотеку мы активно используем в офлайновых проектах, однако посчитали ее избыточной и недостаточно надежной для поставленной задачи. По части Wt – фреймворк имеет большой акцент на GUI, тогда как в нашем случае GUI – вещь второстепенная. Дополнительным фактором при отказе от использования этих фреймворков было желание минимизировать риски, связанные с использованием сторонних библиотек, без которых в принципе можно обойтись, поскольку в данном случае имела место переработка существующего работающего сервиса, который не хотелось сломать из-за недостаточно отлаженной сторонней библиотеки.



Вместе с тем, сам факт существования таких проектов натолкнул на мысль о том, что разработка веб-приложений на C++ дело не такое уж безнадежное. Поэтому было решено провести исследование имеющихся библиотек, которые можно было бы использовать при разработке веб-приложения на C++.



Имеющиеся библиотеки



Для взаимодействия с веб-сервером приложение должно реализовывать один из поддерживаемых веб-сервером протоколов HTTP, FastCGI или SCGI. Мы остановились на FastCGI и его реализации в виде libfcgi.



Для парсинга HTTP-запросов и формирования HTTP-ответов нам подошла библиотека cgicc. Данная библиотека берет на себя все заботы по разбору HTTP-заголовков, извлечению параметров запроса, декодированию тела полученного сообщения, а также по формированию HTTP-ответа.



Для парсинга XML-запросов, которые могут приходить от пользователей сервиса в рамках REST API, был выбран Xerces.



В C++ нет поддержки юникода «из коробки», поэтому для работы с текстом было принято решение использовать стандартные STL-строки при условии обязательного соблюдения внутреннего соглашения, что все строковые данные всегда должны быть представлены в UTF-8.



Для взаимодействия с внешними сервисами и почтовыми серверами было решено использовать libcurl, а для генерации хешей — openssl.



Самописные компоненты



Для генерации html-представлений нам нужен был несложный шаблонизатор. В старой реализации сервиса для этих целей использовался HTML::Template, поэтому при переходе на C++ нужен был шаблонизатор с похожим синтаксисом и похожими возможностями. Мы попробовали поработать с CTPP, Clearsilver и Google-ctemplate.



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



У Clearsilver весь интерфейс реализован на чистом C и для его использования потребовалось писать внушительную объектную обертку. Ну а Google-ctemplate не покрывал все возможности HTML::Template, которые использовались в старой версии сервиса. Для его полноценного использования потребовалось бы менять логику, отвечающую за формирование представлений. Поэтому в случае с шаблонизатором пришлось разработать собственный велосипед, что и было сделано.



Разработка собственного C++ шаблонизатора отняла около трех дней, тогда как на поиск и изучение готовых решений, указанных выше, мы потратили вдвое больше времени. Кроме того, свой шаблонизатор позволил расширить синтаксис HTML::Template, добавив в него конструкцию «else if», а также операторы сравнения переменных с предопределенными в шаблоне значениями.



Управление сессиями пришлось также реализовать самостоятельно. Здесь сказалась специфика разрабатываемого сервиса, поскольку сессия в нашем случае хранит довольно много информации, отражающей поведение пользователя в реальном времени. Дело в том, что кроме обработки данных через REST API, простые пользователи часто обращаются к сервису как к справочной службе, например, когда требуется узнать почтовый индекс для заданного адреса. Время от времени среди пользователей появляются такие, которые решают автоматизировать стандартизацию имеющихся у них контактных данных путем разработки веб-бота, имитирующего работу человека в браузере, вместо того, чтобы использовать предназначенный для этого REST API. Такие боты создают бесполезную нагрузку на сервис, что сказывается на работе других пользователей. Для борьбы с ботами сервис в рамках сессий накапливает сведения, отражающие поведение пользователей. Эти сведения впоследствии используются отдельным модулем сервиса, отвечающим за распознавание ботов и их блокировку.



Пожалуй, ключевым стандартом, который нам пришлось реализовать самостоятельно, является JSON. На C++ есть довольно много его открытых реализаций, которые мы анализировали, прежде чем создавать еще одну. Основной причиной создания собственной реализации является использование JSON в связке с нестандартным аллокатором памяти, который использовался на сервере обработки для ускорения операций динамического выделения и высвобождения памяти. Данный аллокатор работает в 2-3 раза быстрее стандартного на массовых операциях выделения/высвобождения блоков небольшого размера. Поскольку работа с JSON укладывается в данный паттерн, мы хотели получить бесплатный прирост производительности на всех операциях, связанных с парсингом и построением JSON-объектов.



Итоговый результат



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







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



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



Согласно диаграмме, приведенной ранее, при переходе на новую архитектуру время отклика сервиса при обработке одиночного запроса должно было сократиться примерно на 40%. Реальные эксперименты показали, что сокращение произошло на 43%. Это можно объяснить тем, что монолитное решение стало более эффективно использовать оперативную память.



Мы также провели нагрузочное тестирование для определения числа пользователей, которых новый сервис может обслуживать при одновременном использовании подсказок, обеспечивая при этом время отклика не выше 150 мс. В таком режиме сервис смог обеспечивать одновременную работу 120 пользователей. Напомню, что для старой реализации это значение составляло 40. В данном случае трехкратный прирост производительности объясняется сокращением общего числа процессов, принимающих участие в обслуживании потока запросов. Раньше запросы обрабатывались несколькими экземплярами приложения (в экспериментах число экземпляров варьировалось от 5 до 20), тогда как в новой версии сервиса все запросы обрабатываются в рамках одного многопоточного процесса. В то время как каждый экземпляр работает с собственной обособленной памятью, все вместе они конкурируют за один процессорный кэш, использование которого становится менее эффективным. В случае одного монолитного процесса такой конкуренции нет.



Заключение



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



Для улучшения производительности нам пришлось объединить сервер приложений и сервер обработки данных в единый монолитный сервер, реализованный на C++. Такое решение уменьшило вдвое время отклика при обработке одиночных запросов, а также увеличило производительность сервиса в три раза при массовом использовании.



Кроме решения основной задачи приятными бонусами к проделанной работе стало упрощение рефакторинга, поскольку строгая типизация позволяет не напрягаться по поводу переименований в коде, т.к. проект просто не соберется в случае ошибок. Также получившийся проект стало легче сопровождать в целом, поскольку мы имеем единственный сервер, у которого бизнес-логика и логика обработки данных написана на одном языке.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304590/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Как повысить конверсию в екоммерс, используя опросы на выходе

Понедельник, 27 Июня 2016 г. 13:47 (ссылка)

image



Если вы владелец бизнеса е-коммерс, и хотите увеличить конверсию и прибыль, то вы пришли по адресу. В этой статье вы узнаете, как увеличить конверсию с помощью проверенного процесса оптимизации под названием «Exit intent technology» или если по русски «Опрос на выходе».





Как увеличить конверсию и продажи



Самый простой способ – это разбить оптимизацию екоммерс на два этапа:



Этап 1: Узнайте, из какого конкретно раздела ваши посетители покидают сайт



Этап 2: Узнайте, почему ваши посетители покидают сайт и измените это



Эти два этапа представляют собой два различных типа данных, которые вы можете собрать и проанализировать, чтобы в дальнейшем, опираясь на них, повысить коэффициент конверсии вашего интернет-магазина.



Этап 1 — это информация о цифрах или, как это формально называется, информация о количественных данных. На что именно люди кликают мышкой, находясь на сайте, на какие страницы они переходят и с каких покидают ваш сайт. В качестве примера источника количественных данных может служить ваш аккаунт в Google Analytics.



Этап 2 — это о поведении посетителей сайта, так называемые, качественные данные. Почему польхователи покидают сайт со страницы корзины, почему они не понимают ваших описаний продукта и так далее. Примеры качественных данных – это тестирование пользователями, интервью с клиентами, опросы клиентов или принудительный опрос на выходе из сайта.



Каким образом опрос на выходе вписывается в полный процесс оптимизации конверсии





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



image



Вот общая картина данного процесса:



Шаг 1: Цели бизнеса



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



Шаг 2: Сбор данных



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



Шаг 3: Анализ данных



Третьим шагом является анализ данных, понимание того, что значат эти данные.



Шаг 4: Проверка гипотезы



Четвертый шаг предлагает идею сопоставить ваш сайт с вашими данными. «Гипотеза» исходит из того, что сопоставление и тестирование это наука, а на самом деле это статистика.



При проверке изменений веб-сайта, которые вы пытаетесь подтвердить свои статистические гипотезы и заработать больше денег.



Шаг 5 и 6: Разработка и построение



Пятый шаг заключается в разработке и кодировании новых изменений веб-сайта, которые вы собираетесь тестировать.



Шаг 7: А/В Тестирование



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



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



Шаг 8: Итерация



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



Теперь давайте погрузимся в то, как использовать информацию по опросам на выход для роста электронной коммерции.



Гид по повышению конверсий в е-коммерс с помощью опросов на выходе



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



Шаг 1: Найти, откуда посетители покидают сайт


Самый простой способ узнать, с каких страниц вашего сайта уходят посетители – это просмотр отчета по страницам выхода в Google Analytics.

Чтобы проиллюстрировать эту технику, мы рассмотрим социологическое исследование для ByCharlotte( ювелирная компания из Австралии).



image



Войдите в ваш аккаунт Google Analytics и перейдите к вкладке: Поведение > Контент сайта> Страница выхода



image



Затем отфильтруйте отчеты и удалите страницы с низким трафиком, без трафика и со слишком высоким трафиком. Подтвердите эти изменения и следуйте отфильтрованным установкам.



image



Затем закажите отчет с колонкой % выходов. Верхние страницы данного отчета – это и есть те страницы, с которых уходят посетители.



image



Шаг 2: Установите принудительный опрос на выход




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



В данном конкретном примере мы используем приложение Hotjar. (Другие приложения — Foresee, Usabilla, Qualaroo). Устанавливаем софт, регистрируемся, входим в личный кабинет устанавливаем код отслеживания на ваш сайт интернет-магазина.



image



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



Если вы используете Shopify, он находится в theme.liquid файле.



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



Перейдите в меню «Опросы» и нажмите на кнопку «Новый опрос».



image



Дайте название вашему опросу и напишите благодарственное сообщение. В нашем примере мы собираемся спросить наших посетителей сайта: Что вас останавливает от сегодняшней покупки?



image



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



image



Кроме того, необходимо установить целевую страницу для опроса, в нашем случае — это страница корзины.



image



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



Что такое опрос на выходе?



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



image



Наконец, переведите опрос в стадию «Активный» и приступайте к сбору данных.



Шаг 3: Проанализируйте данные вашего опроса


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



image



В нашем примере выше опросы на выходе были сосредоточены на доставке.



Второй способ заключается в рассмотрении всех данных и принятии во внимание основных мыслей посетителей. На чем были сосредоточены люди во время опроса – на одном явном большом недостатке или на одной правильной цели? Цель здесь заключается в обобщении каждой точки данных в одно или два предложения.



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



Третий способ — это о количественной оценке ваших качественных данных путем размещения данных по категориям. Это позволяет определить, сколько людей были сосредоточены на крупном недостатке на странице или на верной цели. В нашем случае 21 из 32 посетителей были сосредоточены на доставке.



Шаг 4: A / B тестирование изменений в вашем интернет-магазине




К данному моменту вы уже узнали в каком месте и по какой причине посетители покидают ваш сайт. В нашем примере мы выяснили, что проблемная страница – это корзина. Через опрос на выходе через Hotjar мы узнали, что люди путают расчетное время доставки и стоимость доставки.



Вот первоначальный дизайн странички корзины:



image



И обновленный дизайн страницы:



image



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



Важно проводить A / B тестирования, чтобы убедиться, что ваш новый дизайн действительно улучшает качество обслуживания клиентов и увеличивает прибыль.



Мы добавили новую информацию о доставке, но в то же время мы обновили дизайн темы магазина, поэтому мы не можем приписать подъем конверсии на 20% только к первым изменениям.



На основании всех собранных нами данных, доставка и расчётное время доставки были повторяющимися проблемами во всех источниках данных, поэтому мы уверены, что эти изменения сыграли большую роль в увеличении конверсии на 20%, которого мы добились с момента запуска изменений.



Запустите рост вашего интернет-магазина



Как вы уже увидели в этой статье, оптимизация конверсии электронной коммерции являет собой двухступенчатый процесс. Шаг первый – это понять, где посетители покидают ваш сайт, шаг второй – почему. Теперь вы знаете все о сборе и анализе качественных данных. И этот анализ качественных данных содержит ключ к пониманию ваших клиентов, их поведения и желаний.



Подписывайтесь на наш блог, дальше будет много всего интересного.

Кстати, мы занимаемся комплексным обслуживанием интернет магазинов, может нужно кому? :-)



С уважением команда фулфилмент-оператора «Ямбокс»

(Ямбокс — превращаем ваш интернет магазин в компьютерную игру)




image

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304200/

Комментарии (0)КомментироватьВ цитатник или сообщество
ringing

Seo Solution

Среда, 22 Июня 2016 г. 11:20 (ссылка)

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

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

1.
8 (400x400, 61Kb)

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<оптимизация - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda