|
|
|
|
|
для: SHAman
(29.06.2011 в 14:26)
| | Вы походу совсем меня не слышите....
читайте внимательнее Дмитрия
__
складывается впечатление что Ваш аккаунт выкрал sim5, только с ним можно было спорить говоря об одном и том же | |
|
|
|
|
|
|
|
для: Valick
(29.06.2011 в 13:06)
| | А вот это совсем не обязательно. Мы можем посадить скрипт-обработчик аки свой сервер, который будет принимать ВСЕ запросы и отдавать их на обработку своим дочерним процессам (форк или тред). Дочерние процессы стартуют куда быстрее чем новый процесс (интерпретатор-то уже запущен и среда подготовлена) и умирают тоже резво, освобождая память как только отработали. Получается некий веер. Один скрипт, который в вечном цикле слушает клиентов и раздает обработку их задач деткам. | |
|
|
|
|
|
|
|
для: SHAman
(29.06.2011 в 13:03)
| | потому что каждый запрос создает копию скрипта обработчика | |
|
|
|
|
|
|
|
для: Valick
(29.06.2011 в 12:13)
| | А почему вы решили что висит 2000 копий серверного скрипта? 0_о | |
|
|
|
|
|
|
|
для: SHAman
(29.06.2011 в 12:00)
| | что Вы к этому это CGI докопались? еще остались такие хостеры?
1% оперативки это Вы каким это фигом прикинули? 2000 копий скрипта = 1%? где Вы видели чат в котором сидят 2000 человек??? пусть даже с вашим Кометом а ну как 2000 человек отправят сообщение одномоментно? катаклизм?
еще раз повторяю, я НЕ ПРОТИВ постоянных соединений и в частности Комета, но это уже далеко не обычный http
цитата из вики..
Благодаря comet-приложениям клиент в режиме реального времени может взаимодействовать с сервером, опираясь на постоянное (или там, где не представляется возможным, длительное (long polling)) соединение HTTP. Поскольку браузеры и веб-серверы работают по протоколу HTTP, который на подобные соединения не рассчитан, разработчики используют различные реализации. Каждая из них имеет свои достоинства и недостатки.
___
кстати идея Dklab Realplexor - это практически то же самое как я описал чуть выше
дклаб:
Сервер может в любой момент записать сообщение в один из таких каналов, и оно будет моментально передано всем подписчикам (хоть одному, хоть тысяче), в режиме реального времени
я:
а вторая отвечает на запрос конкретного клиента и сводиться исключительно к выводу заранее подготовленной информации | |
|
|
|
|
|
|
|
для: Дмитрий Смаль
(28.06.2011 в 18:06)
| | http://softtime.ru/forum/read.php?id_forum=4&id_theme=81198&page=1
Вот эта тема вас заинтересует.
upd: упс, меня опередили) | |
|
|
|
|
|
|
|
для: Valick
(29.06.2011 в 11:34)
| | Можно спросить об этом самого хостера. Имхо, применение комет на простом хостинге вообще не очень правильная затея. Но, кстати, есть подозрение, что хостер лучше пожертвует 1% оперативки на перманентную загрузку, чем будет обрабатывать 2000 запросов в секунду (клиент-то не один), причем в холостую. ну и опять же, если это CGI - на запуск интерпретатора потребуется больше оперативки, чем на поддержание его работы. Получится всплескообразная нагрузка с эффектом DDOS. А при лонг-полинг будет просто перманентная низкая нагрузка. | |
|
|
|
|
|
|
|
для: SHAman
(29.06.2011 в 11:21)
| | Отнюдь. Это тормоза и огромное количество запросов. Если использовать Comet запрос будет один и держаться он будет довольно долго. Все это время он будет работать. Скорость будет поразительная, так как нет накладных расходов на установку соединения, обработку запроса сервером.
зато есть накладные расходы на оперативную память... о ней как всегда хрен кто беспокоется кроме хостера...
я не против постоянных соединений, но это другое дело совсем
вы прочтите о чем пишет Дмитрий, он хочет заставить сервер циклить один запрос до того как появиться что-то что можно отдать браузеру... и все это время копия скрипта будет висеть в оперативке сервера
по мне так лучше запрос каждую секунду, но скрипт обработки должен быть максимально оптимизирован, и может быть даже разделен на две функциональных части, одна из которых запускается по крону общая для всех, а вторая отвечает на запрос конкретного клиента и сводиться исключительно к выводу заранее подготовленной информации | |
|
|
|
|
|
|
|
для: Valick
(28.06.2011 в 19:42)
| | Отнюдь. Это тормоза и огромное количество запросов. Если использовать Comet запрос будет один и держаться он будет довольно долго. Все это время он будет работать. Скорость будет поразительная, так как нет накладных расходов на установку соединения, обработку запроса сервером. Если серверный скрипт выполняется как CGI, а не как модуль сервера, то сам запуск этого скрипта уже будет жрать тучу ресурсов и времени. Скажем, если у меня картинка отдается с сервера CGI-скриптом на Perl, то каждый раз при запросе этой картинки у меня будет запускаться интерпретатор Perl. | |
|
|
|
|
|
|
|
для: Дмитрий Смаль
(28.06.2011 в 18:06)
| | Есть технологии. Long polling, Comet.
Вот можно почитать. Там же увидите и пример и вообще все.
Суть в том, что открывается соединение и не закрывается, а периодические проверки происходят на сервере. Если на сервере что-то происходит - он отсылает данные в открытое соединение с клиентом. Клиенту нужно только следить чтобы соединение всегда было установлено.
Есть еще перспективная технология NodeJS. Это серверный JavaScript. Как и клиентский, он событийно-ориентирован и асинхронен. Тоже позволяет делать системы реального времени. | |
|
|
|
|