вполне распространенный вариант
думаю что связано с тем, что в выходные/праздничные запросто может не быть нужного размера, а списать деньги а потом отправить клиента за возвратом как-то не очень
1. да FB не для веба, если веб на PHP
2. про тупиковую не согласен
3. зачем используете классик если у вас коротко живущие коннекты?
4. тестировали ли FB 3?
зы
про 400 пользователей: что за железо?
есть БД ежедневно 3k+ подключений, проблемы начинаются ближе к 4к
причем есть основания полагать, что истинный корень проблемы в количестве соединений а в неправильной работе с транзакциями в некоторых АРМах
По умолчанию расширение Firebird/Interbase автоматически подтверждает транзакцию после выполнения каждого SQL запроса
это не так, транзакция по умолчанию подтверждается только при закрытии соединения/завершении скрипта либо явно при вызове ibase_commit($dbh)
ibase_execute($sth, $user[0], $user[1]);
// Если произошла ошибка, бросаем исключение
$err_msg = ibase_errmsg();
if ($err_msg)
throw new \Exception($err_msg);
функции сообщают об ошибке возвращаемым значением, его и надо анализировать для проверки, а не дергать ibase_errmsg()
Главное проклятие драйверописателей для FB/interbase (не только в PHP) — понимание специфики транзакций и работа с ними.
Умолчательные параметры транзакции подходят для большинства случаев, и менять их параметры требуется очень редко. Дело в том что соединение с базой данных, как и все связанные с ним ресурсы существуют максимум до конца работы PHP скрипта. Даже если вы используете постоянные соединения, то все связанные ресурсы будут освобождены после вызова функции ibase_close.
Имхо, лучше использовать подходящие параметры для каждого случая (чтение данных, изменение данных, построение отчетов), а не использовать параметры по умолчанию. Да это проще, но это плохо. Чем плохо давно разжевано на том же ibase.ru
crm была в облаке (sfdc), в ней таких вещей не сделаешь, поэтому решение должно было хоститься на своих мощностях. По этой причине было больше свободы в выборе инструментов. PHP не рассматривали по вышеописанной причине, хотя 2 из 3х разработчиков пхппешники, третий — perl. Прототип на perl пхпешникам не вкатил )), попробовали на nodejs — покатило, даже без экспертных знаний в JS
Несколько лет назад подобную задачу решали на nodejs. Не знаю как сейчас, но в тот момент экосистема nodejs для подобных сервисов была предпочтительнее.
Нагрузка определяется не столько количеством соединений, сколько количеством сообщений. При асинхронной работе с соединениями держать большое кол-во открытых неактивных соединений не затратно. Все зависит от приложения, периодические сообщения по некоторым соединениям это одно, постоянный поток сообщений по всем или значительной части соединений это другое.
WS хорош, но сложен в реализации.
используйте готовое решение, вся сложность спрятана внутри.
По поводу long-polling vs websocket: если только https — можно смело использовать websocket, иначе long-polling либо гибридные решения типа socket.io. В ws есть бинарные сообщения, в некоторых ситуациях это очень полезно.
Есть опыт по транспорту котировок в браузер и моб.приложение. Каждому клиенту раз в секунду отправляется информация по изменившимся котировкам (до 50 штук). Первый прототип на node.js+socket.io на 2 тыс соединений на 100% грузил ядро. Были подозрения на избыточность протокола socket.io, раскопки показали что избыточность есть, но не такая значительная. Основной затык был в сжатии ws-фреймов, которое включено по умолчанию и через параметры socket.io не конфигурируется. В принципе хорошее решение для не интенсивного трафика.
Второй и рабочий вариант сделали на чистых вебсокетах, сжатие отключено, данные пересылаются в бинарном виде (protobuf). За счет использования бинарного формата даже при отключенном сжатии удалось выиграть в объеме. Так же бинарный протокол позволил избежать повторного кодирования одних и тех же данных для разных клиентов, пакет собирается из готовых бинарных кусков. Результаты тестов: 5 тыс активных соединений при 25% загрузке ядра, трафик 75Mbps.
Зачем придумывать и героически преодолевать трудности? Да на php можно написать http-сервер, websocket-сервер. Но зачем? Когда есть готовые решения? пусть и на других платформах. Например, nodejs — event loop и http из коробки, реализации ws на выбор, и все это отлично работает + язык знакомый для вебразработчика. Или, например, go — тоже все есть, да, может язык и незнакомый, но эффективнее по по процессору и памяти.
Спасибо за внимание, используйте на здоровье весь приведенный выше код (разумеется, я советую завернуть его в нормальные объекты, тут всё упрощено исключительно для понимания. Особенно callback на пришедший от пользователя frame советую сделать по-нормальному). Если вы будете использовать этот код, напишите пожалуйста где-то в коде «Спасибо Anlide и PhpDeamon».
Ну так оформите нормально, опубликуйте код и документацию, поддерживайте, тогда вам скажут спасибо.
А так — мыши и кактус
но, при определенных условиях это не так
шо, опять? ©
вполне распространенный вариант
думаю что связано с тем, что в выходные/праздничные запросто может не быть нужного размера, а списать деньги а потом отправить клиента за возвратом как-то не очень
2. про тупиковую не согласен
3. зачем используете классик если у вас коротко живущие коннекты?
4. тестировали ли FB 3?
зы
про 400 пользователей: что за железо?
есть БД ежедневно 3k+ подключений, проблемы начинаются ближе к 4к
причем есть основания полагать, что истинный корень проблемы в количестве соединений а в неправильной работе с транзакциями в некоторых АРМах
это не так, транзакция по умолчанию подтверждается только при закрытии соединения/завершении скрипта либо явно при вызове ibase_commit($dbh)
функции сообщают об ошибке возвращаемым значением, его и надо анализировать для проверки, а не дергать ibase_errmsg()
Главное проклятие драйверописателей для FB/interbase (не только в PHP) — понимание специфики транзакций и работа с ними.
Имхо, лучше использовать подходящие параметры для каждого случая (чтение данных, изменение данных, построение отчетов), а не использовать параметры по умолчанию. Да это проще, но это плохо. Чем плохо давно разжевано на том же ibase.ru
зы
сейчас бы сделал на GO
skynet?
Супер!
результаты больших выборок обрабатывать массивом неоптимально, а порой невозможно
есть опыт работы с FB на PHP, было бы интересно почитать соответствующую статью
а зря
говорите как будто это бяка какая-то ))
весьма полезная штука
автора за подобный код осуждаю
возможно, что там значение из предопределенного списка констант, и тем не менее
вы уверены что символ вопроса внутри строки будет воспринят как плейсхолдер?
используйте готовое решение, вся сложность спрятана внутри.
По поводу long-polling vs websocket: если только https — можно смело использовать websocket, иначе long-polling либо гибридные решения типа socket.io. В ws есть бинарные сообщения, в некоторых ситуациях это очень полезно.
Есть опыт по транспорту котировок в браузер и моб.приложение. Каждому клиенту раз в секунду отправляется информация по изменившимся котировкам (до 50 штук). Первый прототип на node.js+socket.io на 2 тыс соединений на 100% грузил ядро. Были подозрения на избыточность протокола socket.io, раскопки показали что избыточность есть, но не такая значительная. Основной затык был в сжатии ws-фреймов, которое включено по умолчанию и через параметры socket.io не конфигурируется. В принципе хорошее решение для не интенсивного трафика.
Второй и рабочий вариант сделали на чистых вебсокетах, сжатие отключено, данные пересылаются в бинарном виде (protobuf). За счет использования бинарного формата даже при отключенном сжатии удалось выиграть в объеме. Так же бинарный протокол позволил избежать повторного кодирования одних и тех же данных для разных клиентов, пакет собирается из готовых бинарных кусков. Результаты тестов: 5 тыс активных соединений при 25% загрузке ядра, трафик 75Mbps.
Зачем придумывать и героически преодолевать трудности? Да на php можно написать http-сервер, websocket-сервер. Но зачем? Когда есть готовые решения? пусть и на других платформах. Например, nodejs — event loop и http из коробки, реализации ws на выбор, и все это отлично работает + язык знакомый для вебразработчика. Или, например, go — тоже все есть, да, может язык и незнакомый, но эффективнее по по процессору и памяти.
Ну так оформите нормально, опубликуйте код и документацию, поддерживайте, тогда вам скажут спасибо.
А так — мыши и кактус