AJAX / PHP Почему HTTP-опрос так запаздывает? - PullRequest
3 голосов
/ 16 июня 2011

Почему HTTP-опрос такой медленный?

У меня есть кнопка, и всякий раз, когда пользователь нажимает на нее, поле базы данных MySQL обновляется, и значение отображается для пользователя. Я опрашиваю каждые 800 миллисекунд, и это очень медленно / глючно. Иногда при нажатии на кнопку она не регистрируется. И мне действительно нужно опрашивать чуть чаще, чем каждые 800 миллисекунд.

Это также только с 1 пользователем на веб-сайте за раз ... Когда, в конце концов, будет много одновременно.

Ответы [ 5 ]

2 голосов
/ 16 июня 2011

HTTP-потоковая передача / длинный опрос / веб-сокеты вместо опроса

Когда вам нужна информация в реальном времени, вам следует избегать опроса (часто).Ниже я бы попытался объяснить, почему это не так.Вы могли бы сравнить это с ребенком в задней части вашего автомобиля, который каждую секунду кричал «мы еще здесь», а вы отвечаете «мы еще не здесь» все время.

Вместо этого вы хотели бы что-то иметьнапример, длинный опрос / HTTP-поток или веб-сокеты.Вы можете сравнить это с ребенком на заднем сиденье вашего автомобиля, который скажет вам сообщить ему, когда «мы там», вместо того, чтобы спрашивать нас каждую секунду.Вы можете представить, что это намного эффективнее, чем в предыдущем примере.

Если честно, я не думаю, что PHP является подходящим инструментом для такого рода приложений (пока).Доступны следующие варианты:

размещенные решения:

  • http://pusherapp.com:

    Pusher является хостомAPI для быстрого, простого и безопасного добавления масштабируемой функциональности в реальном времени с помощью WebSockets к веб-приложениям и мобильным приложениям.


    Наш бесплатный тарифный план Sandbox включает до 20 подключений и 100 000 сообщений в день.Просто перейдите на платный тарифный план, когда будете готовы.

  • http://beaconpush.com/

    Beaconpush - это push-сервис для создания веб-сайтов в реальном времениприложения, использующие HTML5 WebSockets и Comet.

хост для себя:

  • http://socket.io:

    Socket.IO стремится сделать приложения реального времени возможными в каждом браузере и мобильном устройстве, стирая различия между различными транспортными механизмами

Становясь оченьВ общем, решение "сам себе" обойдется дешевле, но, с другой стороны, использование чего-то вроде pusherapp поможет вам легче начать (дружественный API), а также не так уж и дорого.Например, «Bootstrap» от pusherapp может иметь 100 одновременных подключений и 200 000 сообщений в день по 19 долларов в месяц (но когда небольшой beaconpush дешевле => делайте математику :)).В качестве дополнительного примечания этот план не включает SSL, поэтому его нельзя использовать для конфиденциальных данных.Я полагаю, что выделенный компьютер (VPS) обойдется вам примерно в ту же сумму денег (для простого веб-сайта), и вам также придется самостоятельно управлять потоковым решением, но при его увеличении это, вероятно, намного привлекательнее.


Память вместо диска

всякий раз, когда пользователь щелкает по нему, поле базы данных MySQL обновляется и значение отображается для пользователя

При сравнении дискаВвод / вывод (MySQL в стандартном режиме) в память крайне медленный.Вы должны использовать базу данных в памяти, например, redis (также имеет постоянные снимки) или memcached (полностью в памяти), чтобы ускорить процесс.Я сам очень люблю redis за его безумную скорость, простоту и постоянные снимки.http://redistogo.com/ предлагает бесплатный тариф с 5 МБ памяти, который, вероятно, покроет ваши потребности.Если нет, то мини-план в 5 долларов в месяц, вероятно, покроет вас, но при увеличении VPS будет дешевле, и, на мой взгляд, предпочтительное решение.


Лучшее решение

Лучшее решение (особенно если вы становитесь большим) - это самостоятельно разместить socket.io/redis с помощью VPS (стоит денег).Если бы я был действительно маленьким, я бы использовал Redistogo, если бы я не был хозяином сам.Я также начал бы использовать что-то вроде beaconpush / pusherapp из-за его простоты (начав немедленно).Хостинг socket.io (совет поиграть с ним на собственной машине, когда вы становитесь большим) довольно прост, но, на мой взгляд, сложнее, чем beaconpush / pusherapp.

1 голос
/ 16 июня 2011

лаг / Glitchy? Похоже, проблема на стороне клиента. Как и кнопка вещь. Сначала я приведу в порядок ваш JavaScript.

Что касается опроса, 0,8 звучит немного критично ко времени. Я не знаю о большинстве стран, но здесь, в третьем мире, простые сетевые пакеты могут задерживаться на несколько секунд. (Не говоря уже о потере соединения, потере пакетов и скорости света.) Готово ли ваше приложение справиться со всем этим?

Что касается альтернативного подхода, я согласен с @Vern в том, что управляемый прерываниями будет намного лучше. В терминах HTTP это преобразуется в длительный HTTP-запрос, который не получает ответ до тех пор, пока на сервере не будет данных для отправки, что минимизирует задержку и пропускную способность. (AFAIK) это более старая техника, чем AJAX, хотя она была названа совсем недавно. Ищите «COMET», и вы получите библиотеки как на стороне клиента, так и на стороне сервера.

0 голосов
/ 16 июня 2011

Хорошее место для начала было бы использовать такой инструмент, как Firebug в Mozilla Firefox, который позволит вам просматривать запросы, отправляемые на сервер, и искать узкие места.

Firebug будет разбивать каждую часть запроса, чтобы вы могли увидеть, есть ли у вас проблемы с общением с сервером или просто требуется много времени для получения ответа.

0 голосов
/ 16 июня 2011

Наряду с ответом @ Верна я бы также сказал, что, если это вообще возможно, сервер будет кешировать данные заблаговременно, и тогда все клиенты будут извлекать данные из этого же кеша и не будут нуждаться в отдельных вызовах MySQL для достижения того же самого данные для каждого обновления. Затем ваш PHP обновляет кэш всякий раз, когда изменяются фактические данные БД.

Под кешем я подразумеваю запись php в файл на стороне сервера, и тогда клиенты будут просто просматривать содержимое этого одного файла, чтобы увидеть самую последнюю информацию. Возможно, есть лучшие способы кеширования, но, учитывая то, что я никогда не делал этого лично, это первое решение, которое пришло мне в голову.

0 голосов
/ 16 июня 2011

Есть много вещей, которые могут вызвать отставание, которое вы испытываете. Ваш сервер может обрабатывать запросы достаточно быстро, но если соединение между вашим клиентом и сервером медленное, вы увидите очевидное отставание.

Первое, что вы должны попробовать - это проверить связь с сервером и посмотреть, какое время отклика вы получаете.

Во-вторых, вместо опроса вы можете рассмотреть подход, основанный на прерываниях. Это означает, что только когда ваш сервер ответит, вы отправите свой следующий запрос. Это имеет смысл, так что многие клиенты не будут загружать сервер запросами до тех пор, пока сервер не справится. Это особенно верно, тогда RTT (Round-Trip-Time) вашего запроса довольно длинный.

Надеюсь, это поможет. Ура!

...