alexeyymanikin

Рейтинг
131
Регистрация
20.09.2008

Пожалуй я еще раз скопирую сообщение сюда:

-------------------------------

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

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

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

Ниже ссылки на которых можно прочесть о проблеме:

https://dev.1c-bitrix.ru/learning/co...LESSON_ID=2687

https://beget.com/ru/articles/redis_session

http://php.net/manual/ru/session.examples.basic.php

https://habrahabr.ru/company/bitrix/blog/179803/

Если Bitrix пишет о проблеме на habre - почему бы нам не уведомить клиентов о том, что такая проблема есть и не решить ее ? Наверное это вопрос из серии - зачем предупреждать пользователей о вирусах на их сайте ? Или о том, что запросы к БД блокируют друг друга и сайт открывается по 10 секунд ?

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

Бегет, а много на Сёрче у вас левых аккаунтов? Чего в подписи не написали - Beget Support?

Хорошая позиция, после единственного ответа от человека который имеет отношение к Beget - тишина... Хоть прокомментируйте может мы что-то можем сделать лучше ?

MorganSalevan:
Бегет, а много на Сёрче у вас левых аккаунтов? Чего в подписи не написали - Beget Support?

Дочитал до 4 страницы - дальше, особого смысла читать нету. Я являюсь соучредителем Beget, раньше писал на этом форуме, потом мои посты удалили с обоснованием, что по правилам надо писать в отдельной теме, последние полгода сюда не заглядывал.

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

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

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

Ниже ссылки на которых можно прочесть о проблеме:

https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=38&LESSON_ID=2687

https://beget.com/ru/articles/redis_session

http://php.net/manual/ru/session.examples.basic.php

https://habrahabr.ru/company/bitrix/blog/179803/

Если Bitrix пишет о проблеме на habre - почему бы нам не уведомить клиентов о том, что такая проблема есть и не решить ее ? Наверное это вопрос из серии - зачем предупреждать пользователей о вирусах на их сайте ? Или о том что запросы к БД блокируют друг друга и сайт открывается по 10 секунд ?

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

Если подвести итог: лучше пускай про нас напишет один 1 из 250000 клиентов, что мы разводим "маркейтинговую хренотень" чем у 1000 клиентов сайт будет работать медленнее и они напишут нам в техническую поддержку... Я приношу извинения если данное сообщение доставило неудобство - напишите мне (alexey песик beget.ru) Ваш логин и больше не какие уведомления подобного рода Вас беспокоить не будут.

---------- Добавлено 28.09.2017 в 23:51 ----------

devilstar:
Тему прочитал по диагонали, однако свое мнение касательно beget и ему аналогичных - есть.

Любой хостер, который оперирует абстрактными CP - мышеловка.

Просто пример, это когда тот же бегет не смог мне объяснить, а что собственно означает 1cp :D
Я задал примерно такой вопрос - "Вот, скажем, ваша панель показывает, что я потребляю 50cp. Что это означает в более понятных цифрах? Скрипты жрут оперативку? Скрипты долго работают? Медленные запросы к бд? Большой поток данных на запись/чтение?" Техподдержка хостера не знает ответа на этот вопрос.

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

Опять же не могу не прокомментировать...


doom2 : ~ [0] # sa -m
54921 4087.27re 106.96cp 0avio 2672083k
xxxxx1 1526 102.17re 19.21cp 0avio 6822458k
root 23519 3048.00re 17.11cp 0avio 230460k
xxxxx2 2811 79.44re 7.63cp 0avio 6818816k
xxxxx3 10 6.71re 6.04cp 0avio 3684966k
xxxxx4 38 5.26re 4.54cp 0avio 3694107k

cp - это как раз 3 столбец в выводе этой команды, что бы более подробно разобраться читаем инструкцию https://www.opennet.ru/man.shtml?topic=sa&category=8&russian=2.

Опция -m


-m, --user-summary
Print the number of processes and number of CPU minutes on a per-user basis.

Если дать точно определение из инструкции "sum of system and user time in cpu seconds " - суммарное потраченное время процессора user и kernel space на обработку процессов пользователя, получаемая стандартными средствами ядра linux.

Но наверное, многие читатели этого форума спросят - почему же этого попугая (CP) называю абстрактным. Ответ на этот вопрос достаточно простой - если у Вас сервер на базе процессора Xeon 5520 с hdd и 12 гигабайтами оперативной памяти - cp будет больше, чем когда у Вас Xeon E5-2699v4 с 8 SSD Intel 37XX и 512 гигабайтами памяти. Это время учитывает операции ввода/вывода - и на медленных системах это может быть существенно. Так же нужно понимать что чистота, архитектура у процессоров разная и сравнивать данного попугая можно только с аналогичным оборудованием.

Наверное я бы еще рассказал про то какое оборудование мы ставим, но боюсь что опять все мои сообщения удалят =)

er-ka:
Вы пингонули мою VPS на которой крутится сайт http://er-ka.ru
вот один изактуальных серверов хостинга: 62.79.26.191 думаю будет информативней.

Странно, я думал пингую сайт хостинга "ping h4s.ru", а оказалось Вашу VPS =).

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

Топик достаточно приятный.

Пожалуй, прокомментирую последнее сообщение =)))

kondr : ~ [0] # ping h4s.ru
PING h4s.ru (185.62.103.33) 56(84) bytes of data.
64 bytes from ka.user.skyvps.ru (185.62.103.33): icmp_req=1 ttl=61 time=8.40 ms
64 bytes from ka.user.skyvps.ru (185.62.103.33): icmp_req=2 ttl=61 time=8.28 ms
^C
--- h4s.ru ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1113ms
rtt min/avg/max/mdev = 8.281/8.343/8.406/0.110 ms
kondr : ~ [0] # whois h4s.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain: H4S.RU
nserver: achinsk.ens.mail.ru.
nserver: yakutsk.ens.mail.ru.
state: REGISTERED, DELEGATED, UNVERIFIED
person: Private Person
registrar: REGTIME-RU
admin-contact: https://whois.webnames.ru
created: 2015-04-20T20:01:04Z
paid-till: 2018-04-20T20:01:04Z
free-date: 2018-05-21
source: TCI

kondr : ~ [0] # ping rus-beauty.com
PING rus-beauty.com (185.62.103.33) 56(84) bytes of data.
64 bytes from ka.user.skyvps.ru (185.62.103.33): icmp_req=1 ttl=61 time=8.50 ms
64 bytes from ka.user.skyvps.ru (185.62.103.33): icmp_req=2 ttl=61 time=8.47 ms
^C
--- rus-beauty.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 8.474/8.489/8.504/0.015 ms
kondr : ~ [0] # ping er-ka.ru
PING er-ka.ru (185.62.103.33) 56(84) bytes of data.
64 bytes from ka.user.skyvps.ru (185.62.103.33): icmp_req=1 ttl=61 time=8.57 ms
^C
--- er-ka.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 8.575/8.575/8.575/0.000 ms

Я думаю этот разговор не имеет смысла, как минимум из-за разницы в знаниях.

Но я все таки этот идиотизм прокомментирую: формулировка сама по себе - "пробежался по серверам". Отлично и на глаз вы заметите блокировку от 0.1 до 2 секунд ? (Даже top медленней обновляется). Вот если Вы добавите в php логирование и уже потом посмотрите логи - можно будет продолжить разговор.

LineHost:
А вот об этом зря написали. Это огромнейший минус для клиента. Простой сайта - петеря шанса.

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

https://beget.com/ru/articles/redis_session

Например блокировка на ajax запрос в 0,2 секунды - вроде не критична, но не приятна. А если таких запросов 10000 ?

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

количество времени, которое сайты на нашем хостинге были заблокированы из-за сессий в PHP

01.04 - 2233 часов

02.04 - 1232 часа

03.04 - 1332 часа

04.04 - 1672 часа

05.04 - 1740 часов

06.04 - 1514 часов

07.04 - 1453 часа

08.04 - 1598 часов

09.04 - 1289 часов

10.04 - 1517 часов

В среднем сайты не отвечали 1562 часа в день.

Максимальное суммарное время блокировки для одного ресурса составило 2468 часов за 3 дня (к сожалению, название ресурса привести не можем). 2468 часов сайт не отвечал за 3 дня Карл =) !!!

Количество доменов с блокировками за последние три дня 4358.



---------- Добавлено 11.04.2017 в 19:02 ----------

пс. кто нибудь знает как указать размер изображения ? =)

LineHost:
Никакой пошлости. Идея хорошая для большой компании, для таких как я это не имеет смысла. У меня чуть другие проблемы.


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

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

Замечу, что первые попытки/мысли сделать подобную систему появились в 2011 году, когда у нас и 5000 клиентов не было.

LineHost:
Я понимаю пользу такого решения, в данный момент это будет пользоватся спросом, так как экономическая ситуация заставляет вебмастеров экономить. У них множество сайтов и само собой дырявые скрипты. Но изоляция не решает всех проблем, так как зараженные сайты генерируют огромные нагрузки и опасны другим серверам. То есть чистить всё равно надо.
Неизвестна остальная часть системы, по этому сложно что то понять.
По сути, всё это можно рещить с помошью mod_privileges.

нет не заменит, mod_privileges это как mod_itk (https://httpd.apache.org/docs/trunk/mod/mod_privileges.html, http://mpm-itk.sesse.net/) Это просто, если говорить грубо суид процесса в нужного пользователя. Проблему изоляции сайтов в рамках одного аккаунта не решает. Только если в рамках разных пользователей.

По поводу, автоматический (полуавтоматической) чистки от вирусов - ждите новостей и подписывайтесь на нашу группу в https://vk.com/begetru, https://www.facebook.com/LTDBeGet =) будет интересно.

Всего: 143