Блог. Технологии создания и продвижение сайта | ХитМедиа
0
single,single-post,postid-5,single-format-standard,ajax_fade,page_not_loaded,,side_area_uncovered_from_content,qode-theme-ver-7.7,wpb-js-composer js-comp-ver-4.3.5,vc_responsive

Блог. Технологии создания и продвижение сайта

Restful code или упращение кода Java 

Перешёл из Tomcat в Tomee. Читается как Томми. Первое впечататление - работает быстрее. Особенно быстро  на программном обеспечении Dynamic PSP. 
Второе впечатление сложилось после изучения injections code и Restful в Java. 
Важно понимать, что любое упрощение кода для написания почти всегда ведёт к его замедлению. Посмотрим и дам вам знать. Пока можно отметить, что деплоймент кода в Tomee идёт быстро, запуск тоже. Несколько изменилась структура настройки соединений к базам. 
И то ещё радует, что Tomcat жив и развивается, родив Tomee заточенную под JavaEE. 
Хотите проект на Java Restful, пишите. 
  
qode interactive strata

Google принял решение ранжировать выше сайты с https протоколом

С 17 декабря Google принял решение ранжировать выше индекс сайтов с https протоколом.  
Это означает дополнительные затраты для владельцев сайтов на повышение безопасности контента и взаимодействия с клиентом. 
Вот ссылка
 
Сертификат, который потребуется для https стоит от 50 до 250$ в год. 
qode interactive strata

Как увеличить скорость загрузки сайта с помощью Golang

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

Современные сети проглотят ваш сайт и даже не заметят. Скорость мобильного трафика постоянно растёт и будет расти в будущем.
Поэтому скорость загрузки сайта зависит только от того, как ваш сайт организован на хостинге и ни более того.
Первое, что мы определяем это какая скорость вашего сайта на текущий момент.
Типичная скорость ответа сайта сделанного на Wordpress составляет 4 запроса в секунду.
Далее идут реальные цифры на нашем виртуальном сервере с 16 ядер и 16 Гб Ram.
Running 5s test @ http://lrancho.ru 
10 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.77s 205.95ms 1.99s 66.67%
Req/Sec 0.00 0.00 0.00 100.00%
18 requests in 5.10s, 0.86MB read
Socket errors: connect 0, read 0, write 0, timeout 12
Requests/sec: 3.53
Transfer/sec: 173.16KB

Здесь видно, что обработано 18 запроса за 5 секунд, при этом ещё 12 запросов ушли в таймаут.
Что с этим делать? Одним из первых вариантов явилось решение поставить плагин для Wordpress, который отвечает за кэширование сайта на уровне таблиц. Пробудем это решение. Результат уже лучше, но ещё недостаточно, чтобы обработать скорость выдачи 10 тысяч в минуту.
По процессам, происходящие в системы можно легко определить, что основанным тормозом системы является выполнение php кода, а существующие плагины все равно используют php.
Здесь приходит мысль использовать Java для решения вопроса выдачи. Хорошо это решение мы уже давно и с успехом используем для решения с базами данных типа Oracle в реализации интерфейса JOPA.
Running 5s test @ http://hitmedia.ru 
10 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 353.13ms 68.73ms 572.59ms 73.72%
Req/Sec 2.57 0.81 5.00 89.78%
137 requests in 5.01s, 1.01MB read
Requests/sec: 27.34
Transfer/sec: 205.73KB

Уже 27 запросов в секунду. Отлично. Но все равно это очень мало для решения наших задач.
Сравнение скоростей загрузки позволяет определить, что состояние уже лучше, однако, все ещё недостаточно для решения всплесков трафика.
Тратим немного времени на освоения нового скриптового языка, который придумал Google с названием Golang. Здесь можно пропустить пару недель освоения нового синтаксиса, понимание процессов параллельной работы и мультипотоковости и сразу перейти к результату нашего исследования современных системы обработки высокоскростных запросов.
Running 5s test @ http://trendglow.com 
50 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 577.03ms 170.77ms 987.85ms 62.59%
Req/Sec 1.50 0.70 4.00 88.75%
409 requests in 5.10s, 3.34MB read
Requests/sec: 80.21
Transfer/sec: 671.27KB

Хорошо и уже лучше, 80 запросов в секунду, но все еще недостаточно. Давайте попробуем применять мультипотоковость при решении этой задачи, то есть включим всю силу GoLang.
Running 5s test @ http://www.imenno.ru 
10 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 19.52ms 17.05ms 157.49ms 90.24%
Req/Sec 59.87 22.27 131.00 75.25%
2973 requests in 5.04s, 371.56MB read
Requests/sec: 590.05
Transfer/sec: 73.74MB

590 запросов в секунд - это уже результат вызывающий оптимизм, а значит запасы еще не исчерпаны.
Дописываем режим кэширования во внутренней памяти и смотрим результат.
Running 5s test @ http://hitmedia.ru 
10 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 18.90ms 19.14ms 146.24ms 87.94%
Req/Sec 67.49 34.74 181.00 61.79%
3372 requests in 5.10s, 111.46MB read
Requests/sec: 661.42
Transfer/sec: 21.86MB

Уже достаточно, некоторые сайты за сутки не имеют такого трафика.
А текущие цифры решения проблемы скорости отображения сайта вот такие:
Running 5s test @ http://hitmedia.ru 
50 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 16.37ms 8.41ms 83.21ms 75.37%
Req/Sec 62.18 14.99 131.00 72.00%
15742 requests in 5.10s, 520.09MB read
Requests/sec: 3085.58
Transfer/sec: 101.94MB

Running 5s test @ http://imenno.ru 
10 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 9.22ms 17.24ms 180.91ms 88.28%
Req/Sec 1.09k 1.25k 7.31k 85.22%
53754 requests in 5.11s, 15.48MB read
Requests/sec: 10519.48
Transfer/sec: 3.03MB

Вывод: Для решения задач скорости выдачи сайта лучше не использовать PHP, в нем нет мультипотокости процессов, все работает очень медленно.
Golang работает очень быстро. Мы смогли увеличить скорость сайта на любой платформе. Размер страницы не имеет значения. Значение имеет только как реализован ваш сервер. На обычном дешевом хостинге реализовать скорость выдачи практически не реально. Когда вы говорите, что нам это не надо посмотрите сколько ушло от вас, по причине, что ваш сайт тормозит.

В следующий раз попробую Node.js