i.imgur.com/3bgALml.jpg — это сайт в пассивном режиме. Процесс со всеми потоками съедает 1% оперативы и 5% процессора.
В час пик может доходить до 20% оперативы и 15% процессора
смысл в рациональном использовании ресурсов, и выборе техноголий. Идея возникла после того как мне напомнили про книгу «совершенный код» и факт про nginx, который изначально писался вообще для своих целей, а в результате оказался очень востребованным.
Вот это и настораживает, не будет ли это то же самое, что и постоянный вызов скрипта php. С другой стороны, скрипт можно запустить в infinity, но такая реализация мне не нравится.
Спасибо, для nginx модуль действительно стоящий. А по поводу PHP — сама его идеология не подходит. Я когда-то пытался писать драйвера на Delphi и получалось, но он для этого не предназначен
не буду спорить относительно качества :) С PHP достаточно долго и реализовывал достаточно сложные вещи, да и перечитал много литературы чтобы правильно выбрать логику.
А вот к стати, цитата партнера, может просто нагрузка была больше 1000:
привет чат не упал я выключил его временно, у тебя на сайте онлайн вырос, было 300000 соеденений одновременных, так что ширины канала просто не хватило, не знаю даже что тут можно сделать, убери пока код с сайта
1 — да, поддержка браузеров
2 — сервер не выделен полностью для чата. Стоит nginx+apache+php и было рискованно ставить вебсокеты и догружать его
Но в случае с отдельным серваком — да, я бы скорее всего выбрал вебсокеты.
Синтаксис не впечатлил :) Да и не сильно копался в нем, может в этом и есть моя ошибка :). А чат хотел сделать кроссплатформенным, потому остановился на лазаре.
тем более, как сказали выше 1000 — не такая уж и большая нагрузка
Это то что я смотрел в реалтайме, по факту точное количество сказать не могу. Но вот смущает то, что партнер отказался от предоставления своего чата — сказал слишком много соединений из-за чего его сервер падал. На чем он построил свой чат я не знаю, но использовал он nodeJS.
Да, так и планировал сделать изначально. Но, к сожалению, не было достаточно времени для переработки компонента FPHTTPServer. Весь смысл сводился к ручному управлению потоками, но до перепила исходников я так и не добрался.
Да, согласен. Но статьей я хотел больше доказать, что любой человек, который знает какой-нибудь язык программирования (не PHP) сможет написать свое highload-приложение. За Центрифугу спасибо :) Если будет возможность — попробую. Тем не менее, выше я упомянул, что вебсокеты как вариант отпали.
В час пик может доходить до 20% оперативы и 15% процессора
Вот это и настораживает, не будет ли это то же самое, что и постоянный вызов скрипта php. С другой стороны, скрипт можно запустить в infinity, но такая реализация мне не нравится.
А вот к стати, цитата партнера, может просто нагрузка была больше 1000:
Еще раз дико извиняюсь :)
1 — да, поддержка браузеров
2 — сервер не выделен полностью для чата. Стоит nginx+apache+php и было рискованно ставить вебсокеты и догружать его
Но в случае с отдельным серваком — да, я бы скорее всего выбрал вебсокеты.
Оу, про это не в курсе. Сори, видимо недогуглил.
Это то что я смотрел в реалтайме, по факту точное количество сказать не могу. Но вот смущает то, что партнер отказался от предоставления своего чата — сказал слишком много соединений из-за чего его сервер падал. На чем он построил свой чат я не знаю, но использовал он nodeJS.