1. Про PreparedStatment знаю
2. Не коммитить каждую запись тоже

Вопрос в следующем:
никто не занимался наталкиванием во множестве потоков данных в одну таблицу. Есть верные сведения что для M$ SQL это помогает причем народ извращается аж до 60ти коннектов-потоков.

так вот если кто то таким же сталкивался для FireBird, то до скольки потоков и соответсвенно соединений имеет смысл доводить, прежде чем начнется обратный эффект ? Ваш опыт по этому поводу.

Интересно для классика, хотя и про супера тож.

я пока делал в 2 потока получил 60% прирост по сравнению со 1 потоком.

вариант с внешним файлом не подходит.

Весь прикол в том что на 1 процессорном ;)))))))

там устанешь искать .... я не нашел - конфа уже просто гигантская

Это биллинг - табличка предварительной информации которая потом хранимками рассчитывается и удаляется.

Лана буду экспериментировать - потом выложу отчет.

Отчет.

Все что описано касается FireBird Classic на Linux в сочетании с JayBird.
CPU - 1x и 2х 1Ггц Athlon ThunderBird, сеть 100Base-T. Память 512 метров в обоих конфигурациях.

1. Если приложение работает на сервере имеет смысл увеличивать число коннектов до чиcла процессоров. Условие 1 коннект - 1 процессор дает примерно 80ти процентный прирост на каждый процессор. 20% судя по всему теряются в базе на блокировки (чистое предположение). При увеличении коннектов прирост не наблюдается но и явного падения производительности тоже почти не заметно. При числе коннектов более 15ти на 1 процессор начинается падение скорости наталкивания.

2. Приложение работает через сеть. Самое интересное - можно доводить число коннектов до 3х на один процессор - прирост такой конфикурации где-то на 70-75% быстрее по сравнению с одним потоком на 1 процессор. Но число коннектов должно быть не более 8ми потому как начинает проседать сеть (хотя если у вас GigabitEthernet все может быть ;) ). Превышение данного количества ведет к снижению скорости судя по всему именно из-за сети.

Вот такие дела.

2 Gold

) результаты оччень противоречивые :) сам удивлен