это ошибка. исходить надо из задачи, сроков, общего быстродействия, клиентов и прочей мутотени, которая окружает заказ. А не из того, что быстрее а что элегантнее =)
да мне похую на твой опыт, если ты брат элементарно считать не умеешь =) ты потратил в 780 раз времени чем должен был =) это пирова победа, проснись. ты сделал код который на глаз работает с такой же скоростью, и который надо проверять. и вместо одной секунды ты потратил 780. и гордишься этим. капец. что ты скажешь доставщику пиццы, который принесет твой заказ за твои же деньги через 780 часов? "зато я сделал это красиво"
titch если я вижу более тонкое решение, которое будет работать быстрее если что-то меня заставляет оптимизировать js-код, так это то, что на моем нетбуке статистика за месяц при отображении каждого посетителя начинает тормозить при использовании эффектов плавного раскрытия блоков. Если отрубить плавное раскрытие - все пашет на ура =)
слово "плюсы" != слово "быстрее" мне кажется, что ты устал)) и видишь больше, чем написано) плюсы - это плюсы. то, что ты описал - это и есть плюсы
Villan И как ни оптимизируй - получаются мегабайты. ну минифайнутая жукьювери вестит 200 с килобайт кажется. если каждый такой умник будет писать свою функцию прохода по дому еще и с пробелами =) тот вот он уже и мегабайт. не от хорошей жизни это. что делать.
я рад что все тут пообщались.... но кто-то единственный толковый вывод сделает ? P.S. а каждую секунду обновлять не напряжно для сервака, базы ?
раз в секунду - это ерунда. даже тысяча запросов в секунду - это ерунда, если вы с умом отдаете ответы пользователю. например, он вам запрос с номером последнего сообщения и ключом аутентификации. а вы ему обратно только новые сообщения или пустой ответ. сколько это будет обрабатываться на стороне клиента для вас - дело второе. в первую очередь вам нужно минимизировать вычисления на стороне сервера. если у вас очень медленно работают sql запросы, тогда их нужно оптимизировать. может даже есть смысл еще раз подумать над архитектурой
Прошло уже несколько месяцев. Уважаемый bitrop, на каком варианте вы остановились? Если я правильно все понял из вышеобсуждаемого, то выигрыша в скорости при использовании сокетов нет - только лишняя морока по их организации. И в любом случая без AJAXа не обойтись (читать как периодичное JS простукивание в сторону сервера). А так же узнал про WebSocets, которые еще рано использовать в виду незавершенности (несовершенства). Но больше всего меня интересует вопрос, который здесь упоминался вскользь - это серверная память. Если я правильно понимаю, то каждый запрос в сторону сервера - это отдельное соединение. И это минимум 4Мб оперативной памяти. Так? И в этом свете использование сокетов кажется вполне интересным решением - у нас есть один запущенный процесс, под который уже выделено 4 или чуть больше метров памяти. К тому же, он может хранить уже запрошенное, без необходимости каждый раз дергать базу. Например, мы можем спросить у демона информацию о пользователе, о котором интересовался другой клиент секундой ранее. И мы не дергаем базу для получения этой информации, а просто забираем из массива уже имеющуюся инфу. И, кстати, за одно можем посмотреть, сколько у нас пользователей в этом массиве - читать как пользователей онлайн. Естественно, возникнуть трудности с организацией чистки отвалившихся пользователей. Но это, скорее, дело техники и не является сложным вопросом. Что скажете?
У вас какая задача и какие ресурсы и какая квалификация разработчиков? Только исходя из этих ответов можно посоветовать какие-то решения. Технология одна, а вот решений - очень много.
MiksIr, советов я уже много в теме прочел) И про квалификацию лишний раз говорить не буду - а) не относится к вопросу и не влияет на решение, которое вы считаете лучшим б) опять говносрач разведете. Увольте)) Так все же, конретно по вопросу - ?
Ок, вам нужно разработать на C мультиплексирующий сервер, используя epoll или kqueue методы обработки соединений. А если конкретно по вопросу - пойти в гугл и прочесть подробно что же такое "сокеты".