ой ё… Я как чувствовал что без асинхронных запросов тут не обошлось… И советовать рефакторить, чтобы не было инициализации сессии без необходимости конечно же неуместно? Или реально?
Пробуйте неблокирующие транзакции.
Может таки совет выше с закрытием при r/o поможет.
Над балансировщиком крепко подумайте.
Вообще чую у вас файловая система перестраховывается, и не дает другому ip открыть файл когда он уже открыт одним ip, а в рамках одного ip она позволяет открыть несколько раз для чтения…
Я тоже понимаю, что раз один сервер прекрасно работает, то сессии освобождаются, но мы имеем дело с необычным поведением, и значит ошибка где-то перед носом. Так что не стоит полагаться на логику — сразу ведите логи. Попробуйте сохранить один лог открытия/закрытия сессий в одном файлике с обоих серверов, с сохранением времени в микросекундах, номера сервера и запрошенного урл. Создайте два лога — с одним сервером и с двумя. Высокая вероятность что такие логи покажут проблему.
И еще — вы никак не обосновали необходимость принятия запросов от одного пользователя на разные сервера. 100% это разрешит проблему — так или иначе. И я реально не могу придумать сценарий при котором ipvs был бы нежелательным. Для живучести сессий при потере одного из серверов (корзина там, или процесс прохождения теста, не важно) и/или смене ip пользователя в принципе должна сохраняться за счет общего файлового хранилища. Просто настройте ttl для ipvs достаточно маленьким…
Интересная идея.
Не подскажете как вы это сейчас анализируете?
У меня было пару мыслей, хотелось посмотреть на некоторые спектры, и немного с ними поиграться, но я как-то не сообразил как мне увидеть этот самый скользящий спектр и фазу.
преобразование Фурье и вейвлеты помню, но чего-то мне не хватает. Какого-то понимания, чтобы картинка стала на место.
Подскажите с чего начать?
ПЫСЫ: контекст — есть гипотеза, что если заменить звуковой канал визуальным, то при удачном визуальном кодировании глухие смогут не только слышать, но и даже разговаривать. Ведь для глухого проблемы с речью связаны с отсутствием обратной связи — известно, что если человек потерял слух умея разговаривать, то его речь начинает ухудшаться и быстро превращается в непонятную. В общем направление мысли думаю понятное, но с какой стороны к нему подойти, да как создать такие чудо-очки — не понятно. Не понятно даже насколько это реально.
Да я то везде закрываю. Это мне еще в школьные годы привили.
Останавливает не от того, чтобы закрывать а от того чтобы искать где оно не закрыто.
Останавливает потому что версия хостера кажется неправдоподобной. Я потрачу два дня времени, чтобы убедится что ничего не нашел.
Ведь незакрытие файлов это должна быть жестокая бага со стороны апача/пхп.
т.е. вы утверждаете что таки будет такая утечка ресурсов? а пруф на это можете дать?
В моих скриптах оно врядли, но может что-то из того, что у меня стоит не совсем экологично.
Добавление поля в боевую таблицу с кучей данных да еще и в неприспособленных для этого базах (mongo тот же даже не понял бы проблемы) конечно же делать не стоит. Но в таких ситуациях когда это может занять часы это продумывается заранее…
Ваши утверждения про noSQL имеют очень небольшую долю здравого смысла, и очень много иллюзий, потому что мало знакомы с их идеологией. Я раньше почти так-же рассуждал. Ну только без крайностей конечно… Но познакомившись с идеологией понял что оно того стоит.
Ну у меня есть схема в скрипте, но она чуть более гибкая…
Меня интересует именно этап установки. Идея в том, чтобы оставлять структуру там, где ей и место, т.е. в каждом конкретном модуле и т.п… Чисто необходимость создавать структуру заранее вызывает необходимость держать структуру в одном и том же месте… плюс как-то отмечать какое из описаний приоритетнее (в некоторых модулях одно и тоже поле может быть скажем строка, а в другом месте это поле с фиксированными вариантами выбора, случай редкий но возможный).
А так — в момент обращения уже известна структура. Да и модули которые реально не используются — не будут плодить под себя таблицы… Альтернативный, более правильный вариант — проверять наличие нужных таблиц и их структуру ДО запроса…
Такое решение было бы хорошим для питона, ибо там скрипт запускается целиком, а не для каждой страницы, но неприемлемо для пхп, где каждый запрос отдельно обрабатывается… нет, можно сохранять состояния, но где? На диске? Лишние права, лишние риски… В сессии? Тоже криво… вот и думаю. Самому не нравится идея использования ошибок не по назначению, но… Сейчас склоняюсь к компромису — первым запросом делать список таблиц у базы, и уже исходя из него делать создание или несоздание структуры базы при записи или возврат пустого ответа при чтении… А уже несоответствие структуры отрабатывать как workarraund. По идее таких случаев быть не должно или быть очень редко, и тут уже исключение/ошибка уместны…
Это проблема популярности скрипта в первую очередь.
Скрипты которые слишком требовательны — не слишком популярны.
Если писать что оптимально такое-то окружение, но мы стерпим и такое, то это уже получше…
В принципе согласен, хотел написать тоже самое… но согласитесь есть большая разница в скорости доставки.
Когда знаешь что твое сообщение прочитают через сутки, и ответят тебе через двое думаешь над каждой фразой втрое больше…
Ну и принцип того что каждый сисоп знал своего поинта, и в той или иной степени отвечал за него тоже многое меняло… и личные связи всех узлов в сети тоже не на последнем месте были… все иначе было. И не в форме подачи информации, это мелочи… а именно на уровне психологии.
Даже вот такие мелочи… Меня как-то мой знакомый модератор (по сегодняшнему администратор) забанил в одной эхе (типа форума). Так сообщения распространялись так медленно, что я успел и сам на своей ноде (узел доступа, типа минипровайдера) его забанить и всех аплинков обзвонить чтобы его забанили, и на другие ноды позвонил через которые он мог выйти… и это все через домашний телефон, мобилок почти ни у кого не было еще… И сообщение не дошло, и бан не сработал. И пришлось ему со мной договариваться… но то другая история… я просто про динамику говорю, сейчас всё так бешенно, что даже представить себе сложно такие приколы…
Контент тоже был не такой разбавленный как сейчас, с миллионами перепостов фекалий…
Join это чтение.
Если нехватает, то и фиг с ним… грубо говоря NULL.
А при записи все равно будет так или иначе указано в какую таблицу писать. Там и поймаем.
Недостатки Вашего решения:
1 — мы палим злоумышленнку какие у нас есть файлы. К примеру какие установлены плагины а какие нет.
2 — некоторые php-файлы лучше не вызывать напрямую. Особенно если это фреймворк и ты не знаешь какой кодер что впихнул в тот или иной файл.
====
ПЫСЫ: Я вообще еще не решился оставлять этот виндоус-like вариант или роутить «всё кроме....»
