Доброго времени суток.

Решил перейти к ajax и вот пытаюсь что-то сделать.
Имею 4 файла (если нужно выложу, но там все крайне просто) :

1. html страница просмотра
2. php обработчик ajax запроса страницы № 1
3. html страница изменения
4. php обработчик ajax запроса страницы № 2

На данном этапе на html страницах имею кнопку, по нажатию на которую javascript отправляет запрос (кстати еще и с помощью jquery) и обновляет информацию.

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

Нашел информацию о использовании ajax для этих целей (поэтому и начал интересоваться), прочитал, что long polling, длинные опросы или висящие запросы, но не смог понять как их реализовывать.
Мне не нужно делать чат, конференцию и т.п., мне нужно только в режиме онлайн обновлять информацию на нескольких страничках (не более 100), как только информация изменяется в базе.

Подскажите как переделать html страницу просмотра (выкладываю ниже), чтобы информация обновлялась автоматически?

Для long polling простого php-скрипта не достаточно. Раз вы читали, то в курсе, что сервер ожидает до появления данных (ну или любого другого требуемого события) и после этого отдает соответствующий ответ. У вас подобный функционал реализован на уровне сервера?

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

Если long polling на сервере не реализован, то можно просто поставить некий таймаут в разумных пределах:
В таком случае серверный скрипт может быть самым обычным. отдающим нужные данные по запросу.

Встречал, название технологии comet, websocket, signalr - это именно то? Дело в том, что у меня сейчас стоит 5 сек обновление, правда полностью странички, конечно с ajax смотреться будет лучше. Но у меня минимальное событие длительностью 5 сек...возможно можно обойтись и без серверной части - убедил = ) обойдусь без нее.

Но все же хочется знать и уметь, вдруг припрет!
Реально ли пару ссылочек из серии для чайников, т.е. я уже несколько учебников по ajax смотрел, но все равно не понял. Там разные технологии, все в кучу, короче пример бы простенький и пояснение, буду очень благодарен.

Comet - это модель, это название идеи, концепции. Просто термин, введенный для взаимопонимания. Вы бы могли назвать тему "Comet с помощью AJAX" и все бы тоже поняли, что вы хотите.
WebSocket - это технология, а точнее протокол. Это что-то вроде AJAX. Это способ соединения сервера с клиентом. Она относительно новая и еще не во всех браузерах есть по умолчанию. Но WebSocket - это именно то, что станет заменой всяким long polling. Если так можно выразится, то WebSocket - это чистая, не косвенная, реализация Comet-модели, с настоящим постоянным соединением. Кстати, WebSocket используется через JS, принцип работы с ним почти ничем не отличается от AJAX.
signalr - это просто серверная реализация long polling с использованием AJAX для ASP.NET.

Почитайте еще про Server-Sent Events (в гугле полно ссылок). Это что-то вроде WebSocket, но есть большой плюс - работает на HTTP (да, для WebSocket нужен отдельный протокол и много возни с сервером). Кроме того работает почти везде (кроме злополучного IE =) 

Как я говорил, основная часть серверная. Поэтому, вероятно, в учебниках по AJAX способы ее реализации не описаны. У клиента все сводится к циклу/рекурсии одного запроса, что довольно тривиально.

Для чего-то сложного обойтись одним php-скриптом не получится. События надо реализовать общими для всего сервера, всех пользователей. Обычно для подобных целей создают постоянно работающий демон. В идеале это должно быть неким целостным клиент-серверным приложением.
Иначе ежесекундные проверки просто перетекают от пользователя к серверу. Ведь сделать информацию  общей между скриптами можно либо файлами, либо через БД. А это потребует постоянных проверок наличия новой информации в этих источниках.
Хотя, в принципе, можно завязать все на кеше. Он ведь общий, да и чтение с ОЗУ намного быстрее.

Если хотите найти примеры серверной реализации, то ищите long polling в сочетании с языком, например "long polling php". Например, http://habrahabr.ru/post/128535/

Классно, остался 1 вопрос:

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

а long polling для изучения я выбрал потому что это кросс-браузерное решение. А если силшком сильная нагрузка на сервер вообще предлагают делать постоянно подгружаемый iframe, остальные предложения, как говорят, не во всех браузерах работают.

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

Постоянно запущенный не означает постоянно что-то делающий. Загляните у себя на компьютере в диспетчере задач во вкладку процессов...

Суть в том, что события (например, новое письмо на email), обычно, возникают намного реже, чем постоянные запросы, умноженные на количество подключенных пользователей.
Если 100 пользователей каждые 5 секунд проверяют наличие обновлений, то это 20 запросов каждую секунду. Припустим, каждый пользователь раз в минуту создает событие (например, добавляет картинку). Если сделать обновление на long polling, то это, припустим, по 2 запроса в минуту (серверный таймаут обычно 30 сек.) плюс еще один запрос при событии. Итого 2-3 запроса в минуту против 20 в секунду. Если демон и требует ресурсов, то намного меньше сэкономленных от веб-сервера. Потому что в любом случае при long polling ресурсы тратятся почти только на события, то есть коэффициент полезного действия куда выше.

Следует заметить, что существуют варианты, когда события возникают намного чаще, чем альтернативные еще-N-секундные запросы. Например, если это чат с парой сотен посетителей, то новые сообщения могут возникать по несколько в секунду. Поэтому, намного выгоднее обновлять даже просто каждую секунду.

В целом, правило простое: если за некий отрезок времени количество событий намного меньше, чем количество возможных запросов обновления, то выгоднее использовать long polling, и наоборот.