avm, в вас говорит юношеская самоуверенность, возникшая на почве незнания и как вы говорите "узкого кругозора". Со временем вы поймёте, что сравнивать эти две технологи также некорректно, как сравнивать например личное общение и общение по телефону. И то и то необходимо и незаменимо для решения своих задач. К тому же вы из-за недостаточного воображения похоже не способны догадаться, что с технической точки зрения, нет никаких ограничений, которые бы не позволяли реализовать такую же как в IRC функциональность с использованием стандартных возможностей современных браузеров. В этой области, на данный момент есть лиш одна не решенная проблема, современные браузеры не умеют освобождать выделенную память, что приводит к её нехватке через несколько дней "непрерывного" общения в чате. ПС. Я не уверен, что вы уже знали, что такое IRC, когда я для себя уже "закрыл" этот инструмент общения, как отвлекающий и мешающий сосредоточиться. Впрочем это относится и к ICQ и к вэб чатам.
avm — специалист достаточно высокого уровня. Я кстати, подпишусь под всеми его словами в этой теме. А вот вы — неправы.
ну тогда по всей видимости с вами это произошло еще до 1992 года, когда мне приходилось писать tcp и udp клиенты под msdos на библиотеке waterloo-tcp. сначала я неверно подумал что вы о javascript и ajax, но потом понял что о irc vs web-чат... Я не только их не сравнивал, я даже утверждал, что irc - специализированное протокольное решение для он-лайн общения большого кол-ва людей, а http - вообще для этого не предназначен! про это - ржунимагу. это вы чем определили? командой top? броузер использует столько сколько требуется для рендера страницы (конечно, все много сложнее, но в общем принцип именно таков). и если кто-то не удосужился очистить старые сообщения, то ессно никакого озу не хватит, но только это не от того что броузеры не научились освобождать память...
avm 1. Ну что же, я ошибся, иногда такое случается , но я лишь высказал своё впечатление, основанное на вашем поведении. 2. С точки зрения "предназначенности", изначально HTTP разрабатывался для другого, что конечно создаёт свои сложности и увеличивает траффик из-за размера пакетов с данными в направлении клиент -> сервер. 3. Вы рженемогёте по причине того, что не владеете ситуацией. Перед разработчиками браузеров никогда не стояла задача экономить на оперативной памяти, как результат все браузеры в разной степени и с разными повадками с удовольствием забирают необходимые объёмы памяти, а вот расставаться с ними не считают нужным, другими словами они просто текут. Это не имеет значения при стандартной манере использования браузера, т.к. вся память освобождается при закрытии окна/уничтожении главного процесса.
я готов с вами согласиться, если вы мне объясните следующий феномен происходящий на моем компе: Код (Text): USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND avm@avm-desktop:~/Projects/ocms/lib$ ps aux | grep -E "(firefox|opera)" avm 30297 1.4 3.6 82636 36880 ? S 22:59 0:07 /home/avm/lib/opera/9.02-20060919.5/opera avm 30354 5.1 4.2 141340 42800 ? Sl 23:00 0:24 /opt/firefox/firefox-bin -browser -P avm avm@avm-desktop:~/Projects/ocms/lib$ ps aux | grep -E "(firefox|opera)" avm 30297 1.2 3.6 82760 37036 ? S 22:59 0:08 /home/avm/lib/opera/9.02-20060919.5/opera avm 30354 4.4 4.5 136456 46108 ? Sl 23:00 0:27 /opt/firefox/firefox-bin -browser -P avm вам видно, что firefox освободил память? уверяю вас, что я не останавливал firefox и продолжал им пользоваться переходя по разным страничкам... А пока что ваши слова: можно считать необоснованными. Неужели вы и в прямь думаете, что в Mozilla Foundation или Opera Software народ так глуп, что не написал корректный менеджер памяти? еще один перл... хватит трындеть! вы несете чушь пытаясь завуалировать ее в наукообразные формы.
1. Все перечисленные браузеры (IE FF Opera) освобождают память, но не всю, не всегда и при определённых условиях (FF отдаёт часть памяти при загрузке/перезагрузке новой страницы) 2. Чтобы назвать чьи либо слова враньём надо иметь на серьёзные основания, вы же отвечаете за свои слова? 3. Слово глуп, здесь также неуместно как и многие другие слова из вашего словарного запаса. Народ пишет то, что необходимо и достаточно для решения поставленных задач. 4. Вашу фразу могу лиш обернуть против вас, если вы чего-то не понимаете, то либо спросите, либо молчите. Чтобы окончательно прояснить для некоторых вопрос работы браузеров с памятью, я написал примитивный тест, создающий и уничтожающий 1000 простейших объектов. Выводы из его исследования простые: 1. IE работает быстро, памяти жрёт мало, память частично освобождает, не освобождённый кусок памяти использует повторно. 2. FF крайне медленно генерирует объекты, жрёт много памяти (IE * 3) практически её не высвобождает (только при перезагрузке страницы и даже при ней высвобождает не полностью), имеет склонность к выделению новой памяти вместо использования имеющейся (прямая утечка). 3. Opera Быстро генерирует объекты, очень быстро уничтожает, мало жрёт памяти, освобождает до половины памяти, но также имеет утечку памяти. 4. Ни один из перечисленных браузеров не освобождает больше 60% от выделенной памяти. Вот код теста: Код (Text): <html> <body> <script language='JavaScript'><!-- function create_div(id,x,y){ oDiv = document.createElement('DIV'); oDiv.id = id; oDiv.style.width = 40; oDiv.style.height = 80; oDiv.style.position = 'absolute'; oDiv.style.overflow = 'auto'; oDiv.style.left = 50 + x; oDiv.style.top = 50 + y; oDiv.style.backgroundColor = 'EEEEEE'; oDiv.style.fontSize = '16px'; document.body.appendChild(oDiv); //oDiv.innerHTML = '<div align="center" onclick="document.body.removeChild(this.parentNode);" style="font-size:16px;background-color:FFFF55;cursor:pointer">Close</div>'; } function create_divs(){ for(i=0;i<iObjects;i++){ create_div(i,100* (1 + i/300),i%300); } } function drop_divs(){ for(i=0;i<iObjects;i++){ document.body.removeChild(document.getElementById(i)); } } var iObjects = 1000; //--> </script><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br> <div onclick="create_divs();" style="font-size:16px;background-color:ffff55;cursor:pointer;display:inline">Сгенерировать объекты</div> <div onclick="drop_divs();" style="font-size:16px;background-color:ffff55;cursor:pointer;display:inline">Уничтожить объекты</div> </body> <html>
на что я показал, что умеют! к чему этот нелепый тест? показать что броузер не освобождает память мгновенно и всю? так и нужно было сразу говорить... Как именно броузер освобождает память, сколько, почему, каков период освобождения, и т.д. - это предмет разговора в отдельной теме (уж точно не про web-чат). Ваша позиция изначально была в том, что http (а соответственно и броузер) наилучшее средство для реализации чата. Вы все еще на своей позиции? (и что же такое "непрерывный коннект" - keep-alive?)
http и браузер _на сегодня_ лучшее решение для веб-чата (ибо лучшее решение рассматривается не только с технической, но и еще с кучи сторон, начиная с маркетинговой). Если для какой-то локальной сети можно позволить себе построить общение на IRC благодаря "замкнутой системе", то для веб-проектов решение "сказать пользователю скачать программу, поставить ее и использовать" равноценно огромной потери этих самых посетителей, которые не хотят ничего ставить, запускать и вообще хотят все иметь на своем любимом сайте. Что до нагрузки, несоменно варианта развития два - или наращивание серверного кластера и написание сего на интерпретируемых языках или изначально разработка ядра чата на компилируемом языке. Грамотное исполнение в последнем случае даст нагрузку сопоставимую с IRC, что позволит использовать потоковые технологии, а не рефреш/псевдорефреш. Что до трафика, несомненно он будет выше... но об этим все реже и реже можно испугать, а клиентские ресурсы, о которых тут шла так же речь - это тоже сомнительная проблема, ибо мало кто будет сидеть в веб-чате сутками (хотя для таких маньяков потом можно будет подумать о разработке клиентской части.. хотя бы и на основе того же IRC протокола).
Кстати кому интересно как я планировал делать рефреш могут глянуть http://dkflbk.nm.ru/cht_wd_001.zip думаю не трудно понять что к чему... (очень остроумное решение а главное ОЧЕНЬ кросс-браузерное, однако на практике оно так и не увидело свет)
avm, я ещё раз повторяю, вы не в курсе обсуждаемой проблемы, есть факт, браузеры плохо работают с памятью, в результате чего, если их принудительно не закрывать её просто не становится. Приведённый мною "нелепый тест" это пример правильной работы с объектами HTML документа, позволяющий создавать и полностью удалять сущности чата (сообщения, пользователи, кнопки, формы и тд и тп), фактически это упрощённый, но корректный тест имитирующий работу такого чата с рассматриваемой точки зрения. 2. Вы можете ждать сколько угодно освобождения памяти, этого просто не произойдёт, и вообще эта ваша фраза просто попытка спрыгнуть с затронутой вами же темы... Что вы там про враньё говорили?, а уже подтёрли лишнее... 3. Вы умеете читать? Покажите, где я употреблял выражение "наилучшее средство для реализации чата"? Ничего даже близкого по смыслу я в своих сообщениях не использовал, (я их не редактировал). Всё, о чём я говорил, это оценки эффективности различных технологий создания вэб чатов. 4. Вот вы даже этого не знаете, а при этом лезете вставлять своё важное мнение куда попало ). keep-alive тут не причём. Речь идёт об удержании соединения между браузером клиента и сервером чата (протокол HTTP 1/0) в направлении сервер -> клиент, через которое в браузер поступают новые данные. Это позволяет сократить ~95% HTTP запросов. Фактически остаются лишь запросы на проверку таймаута соединения (которые тоже можно оптимизировать), на добавление новых сообщения и запросы на выполнение команд. Соответственно пиковая производительность такого чата в 20 (и более) раз выше, а генерируемый исходящий трафик 20 – 100 раз меньше чем у чатов основанных на регулярном обновлении данных (refresh метод) или на регулярном запросе новых данных (голый AJAX).
MiksIr, а я вот рискнул , какраз неделю назад закончил работу над последней версией серверного демона. На счёт 2000 я ничего сказать не могу, но по моим тестам и оценкам, приличного однопроцессорного сервера должно с запасом хватить на 500 среднестатистических клиентов чата (суммарно по всем "комнатам" до 5 сообщений в секунду).
Для поддержания постоянных соединений потребуется N копий постоянно живых серверных процессов. Понятно, что apache не подходит, значит пишем свою серверную часть. Для клиентской части броузер (не говорим о applet'ах, flash, и т.д.) тоже плохо подходит, если не убивать его периодически. Но мы упорно закрываем глаза на непригодность броузеров для этих целей в угоду каких-то субъективных (или как тут было сказано - маркетинговых ) причин. Ведь нам же "чат" не нужен, а нужен нам именно "веб-чат"! Т.е. идея в том чтобы симулировать то что давным давно делает irc протокол только для того чтобы клиент остался на сайте, не смотря на кучу связанных с этим неудобств. мной затронутая??? :lol: а давайте ка пройдемся по хронологии сообщений? - ONK: [1] "на данный момент есть лиш одна не решенная проблема, современные браузеры не умеют освобождать выделенную память" - avm: [2] "броузер использует столько сколько требуется" - ONK: [ur=http://php.ru/forum/viewtopic.php?p=28494#28494][3][/url] "Перед разработчиками браузеров никогда не стояла задача экономить на оперативной памяти, как результат все браузеры в разной степени и с разными повадками с удовольствием забирают необходимые объёмы памяти, а вот расставаться с ними не считают нужным" - avm: [4] "firefox освободил память" - ONK: [5] "Чтобы окончательно прояснить для некоторых вопрос работы браузеров с памятью" - avm: [6] "не освобождает память мгновенно и всю? так и нужно было сразу говорить... " Вы уж определитесь о чем вообще пытаетесь сказать? Что - броузер плохой вариант, или что - других решений все равно не бывает? Или вам просто хочется чего-то доказать споря со мной, от того что в одном из своих постов я сравнил вас с пионером? Я готов перед вами извиниться - ВЫ НЕ ПИОНЕР! А вам ли делать заключения о том что я знаю и умею? с чего бы это? с того что я с вами не согласен по поводу того, что для чата лучше использовать протокол для это предназначенный? разберитесь-ка в себе для начала...
Ну тут не в процессоре дело то, а в памяти. По сути, кол-во людей при потоковой схеме можно приближенно оценить по формуле "свободная_память/(пхп_процесс - скока_шарится)". Учитывая, что ПХП любит много кушать, получается не очень дешевое решение. По моим оценкам каждый пользователь съест ~8мб. Т.е. каждые 500 человек будут обходится ~ 1.5к$. Конечно, не страшные суммы, пока не прикинешь... 2к человек... может обойтись или в 6к$ .... или в (1.0-1.5 к на разработку демона на С + ~ 0.5-0.7к$ память) ~= 2к$. Ощутимая разница, не правда ли? =)
Вообще, (имхо) лучший вариант реализации таких проектов (с такой нагрузкой) - это Java Servlets. Именно при реализации на CGI сценариях идет вызов отдельного процесса для каждого вызова этого самого сценария. В случае с Java Servlet, этот самый сервлет загружается в память всего лишь один раз и работает с последующими вызовами уже из памяти, тем самым экономит процессорное время, на вызов отдельного процесса, и память, т.к. в ней находится единственный экземпляр сервлета, работающий со всеми запросами к нему. На счет памяти потребляемой браузером могу сказать то, что это проблема разработчиков того самого браузера. Именно по этому данная проблема полностью перекладывается с плеч разработчиков сайтов на плечи пользователей браузеров...
avm, речь идёт о вполне конкретной нише, о вэб чатах для сайтов. Я рассматриваю исключительно эту нишу и про преймущества / недостатки других реализаций чатов я ничего не говорил. Заблуждаетесь. 1. Для поддержания множества клиентских соединений достаточно одного процесса. С точки зрения процесса не имеет никакого значения как он запущен, из под апача или как отдельный сервис операционной системы. Другое дело, что с точки зрения здравого смысла, сервер чата лучше запускать как отдельный сервис. К тому-же апач имеет привычку прибивать своих потомков, поэтому непрерывную работу сервера чата из под апача гарантировать невозможно (правда у меня на этот случай предусмотрен прозрачный реконнект к вновь запущенному процессу). По поводу непригодности браузеров я ничего не говорил. Современные браузеры позволяют делать в них всё что угодно, практически ничем не уступая самописным GUI приложениям. Единственная не решённая проблема на данный момент это браузерные утечки оперативной памяти, да и то это скорее проблемы клиентов а не наши проблемы. При грамотной реализации вэб чата клиент не будет испытывать никаких неудобств, про неудобства связанные с разработкой такой системы упоминать не стоит, т.к. это однократно решаемая техническая задача. MiksIr, моя реализация чат сервера имеет немного другу формулу потребления оперативной памяти -) : 5мб (пхп экзекутор с запущенным скриптом) + [4мб (процесс апача) если из под апача] + n*7кб где n - количество подключённых клиентов. Так что сервер чата с 500 соединениями в самом худшем случае сожрет 13мб оперативной памяти сервера. Так что дело именно в процессоре, точнее в их количестве для обработке поступающих от клиентов команд и сообщений. Масштабируемость такой системы в достаточно широких пределах практически прямопропорциональна к вычислительной мощности сервера.
Может поделитесь тогда, как это сделано ядро? Я не ас в ПХП, но почему-то понятие потоков и неблокирующих соединений в контексте с ПХП вызывает недоверие =)
для этого этот сервис должен сам терминировать tcp соединения. Зачем тогда вообще apache? и какое отношение все это имеет к http? и чем же оно принципиально отличается от другой реализации концепции протокола irc ?
MiksIr, я юзаю вот этот экстеншен http://ru.php.net/sockets А недоверие постепенно рассеивается при испытании готово работающего кода. Мне бы ещё на реальной нагрузке его протестировать, но нет таких возможностей. avm, выше приведённое расширение ПХП имеет все необходимые для этого инструменты. Для работы самого чат сервера апач не нужен никак, я об этом уже писал. К HTTP протоколу это имеет прямое отношение, т.к. браузеры у нас работают именно с этим протоколом, а не с IRC, и сервер чата должен уметь парсить заголовки этого протокола и отдавать документы в соответствие с ним же. Принципиально отличается именно поддерживаемым протоколом HTTP против IRC + потенциальной возможностью работать с любым браузером. Сама концепция HTTP чатов принципиально уступает IRC чатам только тем, что на данный момент нет возможность удержания постоянного соединения c передачей данных в направлении клиент->сервер. Если бы такая возможность была, HTTP чаты ничем бы не уступали в производительности своим IRC собратьям.
Могу ли я узнать, каким образом это "спокойно" реализуется на PHP? С помощью изменения исходников интерпретатора, или написания собственного сервера?
MiksIr, если вы читали ONK, то заметили бы что он сказал о том что он реализовал постоянный коннект клиента и собственный демон держащий массив дескрипторов tcp-сокетов который постоянно шлет данные клиенту без запросов. Правда, из последнего сообщения ONK я что-то не понял - реализовал он это или только теоритизировал на эту тему... Так вот - это не имеет отношения к HTTP. При такой схеме нет вообще надобности в http заголовках. За то, подобная реализация повторяла бы концепцию IRC (ну или если хотите - ssh, telnet, imap, и т.д.) разве что можно было обойтись без описания самого IRC протокола (коли уж изобретать велосипед, чтож не изобрести попутно и протокол свой? и пусть он будет хоть бинарным...)