Уже так же сделал. Пока писал коммент к первому ответу до самого дошло)
Если не сложно, скиньте пример обработчика, например для тытуба, проверить себя. Можно сюда или на мыльник woodfox@mail.ru
Ах, ну да, вот что меня смутило - проверка на оффлайн есть, но каунтер все равно увеличивается - если "сессию" не убить, время онлайна вечное будет.
Как я понимаю, надо $counter = $period;
Вроде все правильно. if($online_time < $period+$delay){ - это проверка на оффлайн, прально? Сбивает с толку delay=1))
Я бы еще убрал лишние вызовы time(), все равно есть переменная.
@sim3x Увы, не могу сказать - я старался не напрягать доски и sleep(1) между запросами) Но на обработку объявлений с трех-четырех регионов хватало пяти минут между запусками. @spatNeHochu Я сча далеко от компа, могу порыться в понедельник, постучитесь тут с моим ником.
Добавлю что, если мне не изменяет память, к спискам можно применять псевдоклассы из разряда class:last-of-type и подобных, а так же связанные с ними функции jQuery/других библиотек.
Не согласен. Как вы будете настраивать "стили в зависимости от последовательности"? Вложенные списки, как в ответе @GingerbreadMSK, дают гораздо больше плюшек CSS, чем фактически никак не взаимосвязанные дивы...
@Rsa97 и тут я заплакал)))
Поддерживаю. Уже давно на всех проектах отправка форм только аяксом. На фэйк-линках висят соответствующие действию ссылки, но все, как одна сообщают о необходимости включить JS.
Аналитика упрямо утверждает, что "отказов" по этим линкам нет.
А если добавить еще один сервер-обработчик (читай, вэб-сервер)? Сессии отпадают. Хранить в куках - не забывайте про то, что они отправляются при каждом запросе к серверу... По моему, вариант с БД предпочтительнее.
В общем, можно по разному)) Как я и отметил все очень зависит от ситуации, лонг-пулл запросы не всегда правильно считать онлайном пользователя. Хранить эти данные можно в памяти, так как онлайн кончится когда сервер упадет)))
Если бы аппликэйшн жил на одной ноде - да. А их базово будет 4 (NLB), а значит необходимо синхронизировать текущую пишушую ноду кластера, иметь отдельные чекеры на всех нодах и далее по списку.
Зы, по времени не пугайтесь - большая ферма на слабом хосте развернута + 100 одновременных коннектов. На реальном железе разница еще ощутимее будет. Железки не приехали еще))
Собственно, аппликаэйшн в процессе разработки и не проблема порезать порты для чтения/записи. Так же это дает возможность читать авторизационные данные только с текущей пишущей ноды и избежать ансинка по важным данным.
Текущая конфига:
Ноды на рилсерверах зависят от ноды балансировщика, естественно.
Время записи 10 строк в индексированную таблицу (2кк+ записей) с новыми коннектами упало с 0,7-1,0 до 0,15-0,4, что весьма ощутимо. Чтение упало еще сильнее.
@opium спасибо за советы. Удалось поднять все это на mysql_proxy, но решено от него отказаться - слишком тяжелый. Реализация на keepalived в 2+ раза быстрее.
Отлично. А теперь скажите, вам необходимо что сделать? Вывести все данные одним запросом, сложить все в одну таблицу (новую), собирать данные из таблиц в центровую (это та, что schedule?) или разбивать центровую по мелким?
Если не сложно, скиньте пример обработчика, например для тытуба, проверить себя. Можно сюда или на мыльник woodfox@mail.ru