Важно. Не рекомендуется провайдерам

Skip to end of metadata
Go to start of metadata

Настоятельно Не рекомендуется провайдерам и не гарантируется работа

1. Использовать proxy

2. Бюджетные встроенные сетевые карты

3. Контентный фильтр

4. Пользовательский firewall

5. ftp, почта, антивирус, нестандартный веб сайт или форум

6. Слишком сложные ступенчатые тарифы

7. Тарифы с разной скоростью на разные подсети

8. Использовать частое изменение поля limit

9. Слишком часто использовать ручное блокирование пользователей(это должно работать автоматически)

10. Категорически не рекомендуем использовать одновременно несколько шейперов для 1 пользователя на разные сети. Например локалка 4096кбит, а внешка 1024кбит. Использование нескольких шейперов одновременно приводит к крайне высокой нагрузке. Ограничивайте шейпером только внешку, а локалку и внутригород через меню оптимизация по сессиям и/или через системный firewall суммарно для всех.  http://asrdoc.ideco-software.ru/pages/viewpage.action?pageId=15073283

11. Нельзя выполнять периодические запросы к БД из своих программ не согласовав предварительно sql запросы, тк это может разрушить БД

12. Не рекомендуется использовать веб-авторизацию при одновременном колве пользователей более 200
      Мы не можем гарантировать качественную работу этих подсистем при большом количестве пользователей.

13. Нельзя использовать легкие модемы и маршрутизаторы d-link и тп soho. Они не могут держать много соединений и нормально натить не смогут.
     У них будет переполнен контрак и будут отрубаться по рандому все сессии. Используйте прямое подключение к провайдеру(оператору) по ethernet.


Пояснение к работе с БД из внешних программ. Позже будет перенесено в раздел FAQ этой документации

 1. Выполнение запроса более 15 секунд крайне не рекомендуется. Избегайте join лучше использовать left outer join или where exists 

 2. Обязательно после выполнения любых sql команд нужно всю информацию сохранить в массив или в файл и сразу закрывать транзакцию, или закрывать подключение к БД.

Пример можно найти в файле /var/www/local/include/database.php

Примерная последовательность.

conn_id = @ibase_connect($this->host.':'.$this->database, $this->user, $this->password, $this->charset, 0, 3, $this->role);

if !ibase_errmsg() exit

query = @ibase_prepare($conn_id, $sql_query)

if !ibase_errmsg() exit

store_res = @ibase_query($conn_id, $sql_query);

$object = @ibase_fetch_row($sql_res); или ibase_fetch_object

ibase_free_result($sql_res);

ibase_free_query($query)

ibase_commit($conn_id)

@ibase_close($conn_id)

Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.
  1. ноя 09, 2010

    Анонимный говорит:

    > Нельзя выполнять периодические запросы к БД из своих программ не согласовав...

    > Нельзя выполнять периодические запросы к БД из своих программ не согласовав предварительно sql запросы, тк это может разрушить БД

    это что имеется в виду ? --Марк

    1. ноя 12, 2010

      Анонимный говорит:

      Тоже очень интересно. У меня отчеты через php в Excel формируются, соответственн...

      Тоже очень интересно. У меня отчеты через php в Excel формируются, соответственно куча запросов происходит разом. Как их согласовывать?

  2. ноя 12, 2010

    osv говорит:

    Вам необходимо согласовать как вы работаете с БД и sql запросы которые вы делает...

    Вам необходимо согласовать как вы работаете с БД и sql запросы которые вы делаете и частоту вызова, мы вышлем в ответ рекомендации по исправлению или подтверждение, что все правильно.

    Можно по почте asr@ideco-software.ru

    Иначе БД может быть разрушена, даже если это просто некорректные select, тк они могут затормозить работу или привести к повисшим транзакциям.