.::PhoenikS::.
Новичок
Напиши свои функции для сессий и используй например shm и семафоры, тогда и список будешь иметь, и работать будет быстро (если в сессиии не пихать тонны данных)
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
AD
Guest
neko
Welcome to SySadmin's World!
Если 150 тысяч раз пречитывать........
Застрелят.... Серваки не резиновые..
-~{}~ 21.02.05 18:54:
neko
Кстати тебе сюда
http://phpclub.ru/talk/showthread.php?s=&threadid=50870&highlight=shm
Welcome to SySadmin's World!
Если 150 тысяч раз пречитывать........
Застрелят.... Серваки не резиновые..
-~{}~ 21.02.05 18:54:
neko
Кстати тебе сюда
http://phpclub.ru/talk/showthread.php?s=&threadid=50870&highlight=shm
AD
Guest
.:
hoenikS::.
Мда... как гипотетический вариант можно рассмотреть.
Вопрос в том, что не везде позволят что то в память подвесить (наверное)..
hoenikS::.Мда... как гипотетический вариант можно рассмотреть.
Вопрос в том, что не везде позволят что то в память подвесить (наверное)..
.::PhoenikS::.
Новичок
Кэширует ось(програмно) и контроллеры(аппаратно, если умеют)
Если он говорит про 150 тыс посещений, то это уже на выделенный сервер тянет, а за нормальные деньги, кои тратятся на такое, можно купить и схм и еще чего другое, чего понадобится.
Железо дешевеет, а софт дорожает, так что это уже дело пятое
AD
Guest
neko
Я ж говорю - сходи по ссылке.
Там человека убить пытаются..... За то что он в 1(!) Файл очень много раз пишет!
Даже SSI (если их много) могут здорово нагрузить.
У нас недавно был введен механизм отслеживания скриптов, которые грузят... Таак вот. около 50 SSI было найдено на одной страничке... А юзер плакал, что ему письма приходят о нагрузе на сервер..
-~{}~ 21.02.05 19:00:
.:hoenikS::.
Нет, понятное дело. Если вопрос ставится так что "Позарез". Co-Location поставить не проблема... Вернее не моя проблема...
Я ж говорю - сходи по ссылке.
Там человека убить пытаются..... За то что он в 1(!) Файл очень много раз пишет!
Даже SSI (если их много) могут здорово нагрузить.
У нас недавно был введен механизм отслеживания скриптов, которые грузят... Таак вот. около 50 SSI было найдено на одной страничке... А юзер плакал, что ему письма приходят о нагрузе на сервер..
-~{}~ 21.02.05 19:00:
.:
hoenikS::.Нет, понятное дело. Если вопрос ставится так что "Позарез". Co-Location поставить не проблема... Вернее не моя проблема...
.::PhoenikS::.
Новичок
Оффтоп:
я о том же, есть проблема - есть ваарианты решения, выбирает конечный программист
я о том же, есть проблема - есть ваарианты решения, выбирает конечный программист
AD
Guest
.:hoenikS::.
Ага. Но вопрос изначально ставился обстрактно.
Есть ли в PHP встроенные средства для работы со списком сессий?
Типа там $sessions=session_list();
Ну на нет и суда нет..
hoenikS::.Ага. Но вопрос изначально ставился обстрактно.
Есть ли в PHP встроенные средства для работы со списком сессий?
Типа там $sessions=session_list();
Ну на нет и суда нет..
neko
tеam neko
AD
я непонимаю кого это все волновать должно
ты хоть что-нибудь мерял прежде чем эту всю ерунду писать?
или архитектурные решения для суперпосещаемого сервера выносят на основе малосмысленных постов от неизвесто кого (ой, меня хостер обижает)
я кстати в курсе как работает shm
и поэтому знаю как там расходуется память, поверь любого оголтелого оптимизатора это расстроит
советую и тебе ознакомится
заодно посмотри как работают в пхп сессии
сразу и вопросы про лист отпадут
-~{}~ 21.02.05 19:10:
я кстати не утверждаю, что это будет работать быстро с просмотром файлов
но я в этом очень и очень сильно уверен
и поэтому ваши рассуждения без тест-кейзов не принимаются
причем
для этого прочтивальщика собственный кеш прикрутить
дело в целом плевое
и третье
это все возможно не самый лучший вариант
но так вот с потолка заявлять "это будет медленно"
я бы не стал ни на чьем месте
я непонимаю кого это все волновать должно
ты хоть что-нибудь мерял прежде чем эту всю ерунду писать?
или архитектурные решения для суперпосещаемого сервера выносят на основе малосмысленных постов от неизвесто кого (ой, меня хостер обижает)
я кстати в курсе как работает shm
и поэтому знаю как там расходуется память, поверь любого оголтелого оптимизатора это расстроит
советую и тебе ознакомится
заодно посмотри как работают в пхп сессии
сразу и вопросы про лист отпадут
-~{}~ 21.02.05 19:10:
я кстати не утверждаю, что это будет работать быстро с просмотром файлов
но я в этом очень и очень сильно уверен
и поэтому ваши рассуждения без тест-кейзов не принимаются
причем
для этого прочтивальщика собственный кеш прикрутить
дело в целом плевое
и третье
это все возможно не самый лучший вариант
но так вот с потолка заявлять "это будет медленно"
я бы не стал ни на чьем месте
AD
Guest
neko
А что мне неизвестно про то, как сессии работают?
Я конечно не претендую на статус PHP Guru. Более того, я его только изучаю. Но иного способа получения списка сессий, как чтения каталога session_save_path я не видел. Вот и вопрошаю мнение форума. И дело не в том, какая будет посещаемость. ПРИНЦИП!
Нет встроенных средств - значит нет (странно). Есть - хорошо.
А что мне неизвестно про то, как сессии работают?
Я конечно не претендую на статус PHP Guru. Более того, я его только изучаю. Но иного способа получения списка сессий, как чтения каталога session_save_path я не видел. Вот и вопрошаю мнение форума. И дело не в том, какая будет посещаемость. ПРИНЦИП!
Нет встроенных средств - значит нет (странно). Есть - хорошо.
AD
Guest
neko
И мне надоела. Я узнал, то что хотел....
И на этом достаточно.
Всем спасибо.
И мне надоела. Я узнал, то что хотел....
И на этом достаточно.
Всем спасибо.
SiMM
Новичок
> Но иного способа получения списка сессий, как чтения каталога session_save_path я не видел. Вот и вопрошаю мнение форума. И дело не в том, какая будет посещаемость. ПРИНЦИП!
Интересно, чем же отличается принцип, когда речь идёт о сущностях в файловой системе или в базе данных? Вообще конечно непонятно, почему так агрессивно к БД настроены - можно подумать, что с файловой системой проблем просто никаких не будет и она, в отличии от БД, конечно же с лёгкостью справится с такой нагрузкой (даже не важно, каталог читать или реализовывать самописную БД, в чём смысла мало).
Интересно, чем же отличается принцип, когда речь идёт о сущностях в файловой системе или в базе данных? Вообще конечно непонятно, почему так агрессивно к БД настроены - можно подумать, что с файловой системой проблем просто никаких не будет и она, в отличии от БД, конечно же с лёгкостью справится с такой нагрузкой (даже не важно, каталог читать или реализовывать самописную БД, в чём смысла мало).
AD
Guest
SiMM
Если повнимательнее в читатся в суть вопроса, то я вопрошал по поводу "Есть ли в PHP ВСТРОЕННЫЕ(!) средства для получения списка сессий"
Если повнимательнее в читатся в суть вопроса, то я вопрошал по поводу "Есть ли в PHP ВСТРОЕННЫЕ(!) средства для получения списка сессий"
AD
Guest
Ну а я про что?
Нет - каждому надо высказаться......
Если бы по теме.. а так..
Нет - каждому надо высказаться......
Если бы по теме.. а так..
.::PhoenikS::.
Новичок
В Оффтоп опять же. Хотя не хотелось подымать тему неаргументированных споров и хамства в явном и неявном виде.
НЕКО, вы все время (ну не все, конечно, а процентов 85) занимаетесь тем, что пытаетесь выставить других "ламерами", а себя превознести до "самого гуру".
Теперь в тему.
Мои аргументы.
Про файловую систему (про большое кол-во обращений с большой опять же периодичностью) вы неправы изначально:
посудите сами, для чего нужна RAM?
Если её быстродейсвие было бы ХОТЯ БЫ сопоставимо с файловыми операциями, неужели тогда все ставили на сервера большое её кол-во? Не проще ли купить хард на 76Гб и жить в свопе?
Плюс ко всему, при открытии файла происходит проверка прав, причем каждый раз (на СШМ тоже, если использовать её в чистом виде, а не например с memcached), однако при примерно одинаковых накладных расходах (таблицы доступа кэшируются ОС), позиционирование аппаратное(если точнее, то механическое) гораздо более тяжко для IO-подсистемы. Про запись я думаю и так понятно. Причем это все даже с кэшем контроллеров, если таковой имеется. И вдобавок: нелинейно возрастает нагрузка при линейном росте кол-ва обращений. С семафорами кривая распределения времени отклика значительно менее крутая.
Ещё один аргумент:
если бы все было так гладко с блокированием (что немаловажно) файлов, то почему используются семафоры (к размышлению)?
Про расход памяти согласен - в файлах по байтам меньше, НО данные сессий (если туда онять же не пихать файлы , загруженные пользователем) занимают крайне небольшие объемы. Скажем усредненно, что на 500 сессий пожертвовать 12М памяти не жалко, опять же в пользу быстродействия. Хотя 500 текущих сессий - это оченб немалое кол-во, которое скорее всего перекроет те самы пресловутые 150тыс хитов в сутки.
Давайте привинтим кэш к системе, потом кэш к кэшу и ещё одним кэшэм закроем? Это совсем не выход, т.к. для такой небольшой подсистемы проще и логичнее написать новое програмное решение, а не заниматься родами ежей (иначе не могу назвать). Такое решение будет решать те же самые задачи, но более вероятно, что быстрее, чем то, что будетсобрано из кучи "всего-всего", хотя бы потому, что оно более специализированно (взаимозависимость универсальности и быстродействия известна всем).
НЕКО, вы все время (ну не все, конечно, а процентов 85) занимаетесь тем, что пытаетесь выставить других "ламерами", а себя превознести до "самого гуру".
А почему собственно мы должы вас убеждать? Вы начинали этот трэд? Или вы эдаким контролер, мимо которого ничего не проходит? Или вы считаете, что можете высказать свою точку зрения и заставить верить в нее других? Мне кажется, что вы сами пытаетесь спорить неаргументированно, хотя мы с тем же успехом можем сказать, что " ваши рассуждения без тест-кейзов не принимаются". Причем я более чем уверен, что после этого поста начнутся обычные с вашей стороны реплики из серии: "ну вот, убеждаю ламеров, а они, тупенькие, не верят мне, великому и могучему, поэтому что с ними разговаривать". Так было уже не один раз.
Теперь в тему.
Мои аргументы.
Про файловую систему (про большое кол-во обращений с большой опять же периодичностью) вы неправы изначально:
посудите сами, для чего нужна RAM?
Если её быстродейсвие было бы ХОТЯ БЫ сопоставимо с файловыми операциями, неужели тогда все ставили на сервера большое её кол-во? Не проще ли купить хард на 76Гб и жить в свопе?
Плюс ко всему, при открытии файла происходит проверка прав, причем каждый раз (на СШМ тоже, если использовать её в чистом виде, а не например с memcached), однако при примерно одинаковых накладных расходах (таблицы доступа кэшируются ОС), позиционирование аппаратное(если точнее, то механическое) гораздо более тяжко для IO-подсистемы. Про запись я думаю и так понятно. Причем это все даже с кэшем контроллеров, если таковой имеется. И вдобавок: нелинейно возрастает нагрузка при линейном росте кол-ва обращений. С семафорами кривая распределения времени отклика значительно менее крутая.
Ещё один аргумент:
если бы все было так гладко с блокированием (что немаловажно) файлов, то почему используются семафоры (к размышлению)?
Про расход памяти согласен - в файлах по байтам меньше, НО данные сессий (если туда онять же не пихать файлы , загруженные пользователем) занимают крайне небольшие объемы. Скажем усредненно, что на 500 сессий пожертвовать 12М памяти не жалко, опять же в пользу быстродействия. Хотя 500 текущих сессий - это оченб немалое кол-во, которое скорее всего перекроет те самы пресловутые 150тыс хитов в сутки.
Да это не лучший вариант. Лучших не бывает, бывают максимально адаптированные. И с СИММом я также согласен, почему такое негативное отношение к БД? БД для нагрузок и приспособлены в том числе. Другое дело, что МОЖНО пойти другим путем. В простейшем случае "файловым".
А для чего?
Давайте привинтим кэш к системе, потом кэш к кэшу и ещё одним кэшэм закроем? Это совсем не выход, т.к. для такой небольшой подсистемы проще и логичнее написать новое програмное решение, а не заниматься родами ежей (иначе не могу назвать). Такое решение будет решать те же самые задачи, но более вероятно, что быстрее, чем то, что будетсобрано из кучи "всего-всего", хотя бы потому, что оно более специализированно (взаимозависимость универсальности и быстродействия известна всем).
neko
tеam neko
птица феникс долго пыжилась и снова родила бред
я эту ахинею даже комментировать не буду
а то опять, как в прошлый раз случится истерика
все слова умные какие знал, написал, жаль только смысла ноль да маленько
ну и бог с ним
остальные зрители могут пройти в центр экспозиции, где находится
наш супер-сервер для на котором я планирую срубить кучу бабок (тм)
показывая монику беллуччи своим 150.000 посетителям в день!
апплодисменты, товарищи
итак, шикарная коробка, стоимостью в 250 $
хуже компа у меня просто нету, извнияйте
чуть не забыл:
поехали...
пишем умышленно неоптимальный и кривой код:
роль посетителей играют 7 нормальных машин с ab
одновременно запускаем тесты:
картина на сервере, в среднем такова:
читателю предлагается самостоятельно умножит цифру 186 на кол-во секунд в дне
в том самом дне, в который на наш насчастный целерон с ide диском, должно обрушистся 150к посетителей
(подсказываю, получится 16млн. хитов в сутки)
огромная между прочим цифра
на клиентах:
среднее 0.5 сек. это очень неплохо для моего тупого скрипта.
но по max видно, что в какой-то момент мощностей стало нехватать.
поскольку ab куки не особо стремится принять, на каждый запрос создается сессия.
и следовательно кол-во файлов в /tmp растет с куда большей скоростью, чем это былобы, в реальности, с живыми людьми
я также предполагаю, что в реальных ситуациях
save_handler = files может нас подвести очень сильно
если кто-то это может прокомментировать, мне былобы интересно
что еще можно сказать.
во-первых, это железо, очевидно, на такие нагрузки не рассчитано
правда у автора вопроса их очевидно нет и не предвидется
ос кстати тоже, не сказать чтобы лидер по scalability.
во-вторых возражения по поводу тупизны алгоритма не принимаются
данный код, это иллюстрация очень простой мысли:
если ты не знаешь досконально как работает твоя ос, твой веб-сервер и твой пхп
не надо с умным лицом рассказывать мне про семафоры и shm
надо взять и попробовать.
это первое правило оптимизатора.
в одной руке XSH5, а в другой секундомер и иначе никак.
спец. пояснение для серых, как штаны пожарного:
ТАК ДЕЛАТЬ НЕНАДО
это не руководство к определению списка юзеров онлайн.
я эту ахинею даже комментировать не буду
а то опять, как в прошлый раз случится истерика
все слова умные какие знал, написал, жаль только смысла ноль да маленько
ну и бог с ним
остальные зрители могут пройти в центр экспозиции, где находится
наш супер-сервер для на котором я планирую срубить кучу бабок (тм)
показывая монику беллуччи своим 150.000 посетителям в день!
апплодисменты, товарищи
Код:
NetBSD 2.0 (CATALINA) #0: Sun Feb 20 12:39:39 VLAT 2005
total memory = 238 MB
avail memory = 229 MB
BIOS32 rev. 0 found at 0xf0010
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel Celeron (686-class), 1995.13 MHz, id 0xf29
<...>
wd0 at atabus0 drive 0: <SAMSUNG SP0411N>
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 38204 MB, 77622 cyl, 16 head, 63 sec, 512 bytes/sect x 78242976 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA data transfers)хуже компа у меня просто нету, извнияйте
чуть не забыл:
Код:
/dev/wd0e on /usr type ffs (local)пишем умышленно неоптимальный и кривой код:
PHP:
<?php
$garbage = str_repeat( rand(), rand( 80, 180 ) );
session_start();
$_SESSION['user'] = rand();
$_SESSION['garbage'] = $garbage;
?>
<html>
<body>
<?php
print $garbage . '<br/><br/>';
exec( 'ls /usr/stress/tmp', $list );
$count = count( $list );
print 'Online:<br/>';
for( $n = 0; $n < $count; $n++ )
{
$fn = '/usr/stress/tmp/' . $list[$n];
$stat = stat( $fn );
if( $stat[8] + 10 > time() )
{
list($user) = explode( ';', file_get_contents( $fn ), 2 );
print substr( $user, 7 ) . '<br/>';
}
}
?>
</body>
</html>одновременно запускаем тесты:
Код:
ab -n 10000 -c 50 [url]http://10.0.0.2:7777/session.php[/url]
Код:
CPU Usage: u10.51 s16.09 cu.02 cs.02 - 53.3% CPU load
186 requests/sec - 264.5 kB/second - 1458 B/request
232 requests currently being processed, 23 idle serversв том самом дне, в который на наш насчастный целерон с ide диском, должно обрушистся 150к посетителей
(подсказываю, получится 16млн. хитов в сутки)
огромная между прочим цифра
на клиентах:
Код:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 2.4 0 10
Processing: 0 909 990.8 500 9703
Waiting: 0 893 976.3 490 9673
Total: 0 910 990.8 500 9703но по max видно, что в какой-то момент мощностей стало нехватать.
поскольку ab куки не особо стремится принять, на каждый запрос создается сессия.
и следовательно кол-во файлов в /tmp растет с куда большей скоростью, чем это былобы, в реальности, с живыми людьми
я также предполагаю, что в реальных ситуациях
save_handler = files может нас подвести очень сильно
если кто-то это может прокомментировать, мне былобы интересно
что еще можно сказать.
во-первых, это железо, очевидно, на такие нагрузки не рассчитано
правда у автора вопроса их очевидно нет и не предвидется
ос кстати тоже, не сказать чтобы лидер по scalability.
во-вторых возражения по поводу тупизны алгоритма не принимаются
данный код, это иллюстрация очень простой мысли:
если ты не знаешь досконально как работает твоя ос, твой веб-сервер и твой пхп
не надо с умным лицом рассказывать мне про семафоры и shm
надо взять и попробовать.
это первое правило оптимизатора.
в одной руке XSH5, а в другой секундомер и иначе никак.
спец. пояснение для серых, как штаны пожарного:
ТАК ДЕЛАТЬ НЕНАДО
это не руководство к определению списка юзеров онлайн.