Камышев Александр

Пользователи
  • Публикации

    223
  • Зарегистрирован

  • Посещение

  • Days Won

    8

Камышев Александр last won the day on 14 ноября 2016

Камышев Александр had the most liked content!

О Камышев Александр

  • Звание
    Продвинутый пользователь
  • День рождения 02.12.1978

Информация

  • Пол
    Мужчина
  • Город
    Москва, Троицк

Посетители профиля

537 просмотров профиля
  1. while(1) Sleep(INT_MAX) - это грубо, но можно еще брутальней: while(1){} если так принципиально, для успокоения, можно создать еще поток, передать ему ссылку на event, добавить код event->SetEvent() и не запуская на выполнение уйти в WaitFor, тогда все в порядке: два потока, оба ждут.
  2. мдя согласен, счетчик только увеличивается тогда еще проще: TSimpleEvent *event = new TSimpleEvent(NULL); event->WaitFor( INFINITE ); замри
  3. по разному... как обезьяна с гранатой, куда швырнет, варианты от ничего и вплоть до краша
  4. deadlock? - легко: TCriticalSection *cs = new TCriticalSection(); cs->Enter(); cs->Enter();
  5. Unix то да, только до сих пор это были java приложения для виртуальной машины, теперь можно создавать исполняемые ELF файлы консольных приложений и библиотеки под unix. выше было видео, создание Apache dynamic link module, вот здесь c 45 минуты:
  6. The RAD Studio IDE now includes its first LLVM based Linux compiler for Enterprise development, enabling Delphi developers to target 64-bit Intel Linux servers and devices. The Linux compiler is certified for Ubuntu Server (LTS 16.04) and RedHat Enterprise (V7) and is built on top of the LLVM engine Они что, правда сделали компилятор под unix исходников на паскале? Или еще один переход си <-> паскаль? Насколько мне известно, модули для apache до сих пор собирали и устанавливали с помощью apxs / apxs2, apxs в свою очередь работает с исходниками на Си, объектными файлами *.o и статическими библиотеками *.a. И как все это хозяйство привязали к паскалю? Что-то, воля ваша, недоброе таится© в написании кода на си, который использует компоненты написанные на паскале, которые собираются компилятором(написанным видимо на си) в объектники и библиотеки, которые затем будут собраны в модули для демона написанного на си..., доколе? При этом, нет поддержки линукс-сервер для borland си... все, абзац.
  7. Полная ерунда - весомый довод... Сохранить то utf-8 можно, компилер среды BCCAARM.EXE, the C++ Compiler for Android все равно будет с ними работать как с asci, и также не поймет кириллицу, если ему, как писали выше, если не указать принудительно. А вот BCC32, the C++ Command-Line Compiler все считает корректно.
  8. Это все делает TLang стандартный, зачем переписывать доступные стандартные компоненты?
  9. Если строки в языковых файлах - зачем RTTI, что к чему безопасно runtime приводить? Почему бы Embarcadero не работать сразу с unicode, стандартно UTF-8(16)? RAD Studio работает с исходниками на Ansi, а компилятор не распознает кириллицу в этих исходных файлах, приведение: case 0: return (AnsiString)"Ожидание"; сделано как попытка объяснить компилятору, что это кириллица. Правильный подход (имхо опять же) - среде нужно сразу работать с unicode, и не извращаться потом с приведением типов.
  10. На Seattle это работает, не знаю уж как там преобразование в Android API, в Berlin уже нет. Приложение под Андроид оставил в Seattle и больше не заморачивался пока. Сейчас пишу демон TCP сервера на с++ под CentOs в среде NetBeans, там строки языка Ansi С и стандартные строки std::string из C++. Отображение строк только в логах либо в браузере и проблем с кириллицей нет.
  11. Некорректно выразился, на андроид не работает связка FireDac + MySQL, т.к. используется libmysql.dll, с sqLite все вроде ок.
  12. мдя, чудес не бывает, в базе и близко нет 3к записей в секунду, из-за ошибки с флагом наложение данных и до записи доходит процентов 10-20, потому и ресурсов мало потребляет.
  13. статистика: запросов задач в сек. 3000 подтверждений в сек. 0 параметры файлов в сек. 0 запросов данных в сек. 0 запросов клиента в сек. 0 время запроса, мсек. 156 активных соединений с бд 10 из 10 запросов в бд в сек. 3000 размер очереди в бд 1365 из 5000 время запроса к бд, мсек. 31 устройства 2490 профили 139 задачи 51 файлов доступно 11 db_client 0 запросов в сек. 300 db_client 1 запросов в сек. 302 db_client 2 запросов в сек. 300 db_client 3 запросов в сек. 300 db_client 4 запросов в сек. 301 db_client 5 запросов в сек. 300 db_client 6 запросов в сек. 300 db_client 7 запросов в сек. 298 db_client 8 запросов в сек. 299 db_client 9 запросов в сек. 300
  14. При запросе оборудование сообщает серверу свои параметры, сервер записывает их в базу, всего три записи в три таблицы, два целых числа и одна строка плюс ключевые поля. Selectы сервер делает периодически, через 5 минут, обновление кэша. Практически идет только запись. На пакет http ответ уходит сразу, без подтверждения записи в бд. Если ждать подтверждение скорость резко падает, и больше 600-800 http запросов служба затыкается, краш где-то получается. Всего удалось получить больше 3000 тысяч запросов т.е. 3000 * 3 = 9к в секунду, движок СУБД при этом занимает 10-15% загрузки. MySql с максимальными настройками, измерял время потраченное на три запроса - поднималось в пике до 50мс. Десять коннектов держали по 300 таких пакетов запросов, т.е. среднее время должно было быть ~3 мс на запрос. Как-то не сходится... буду дальше копать
  15. В продолжение темы. С асинхронным режимом amAsync в FD все плохо, нет колбэков - полбеды, на 1200-1500 крашится все сразу, на нескольких сотнях запросов умирает медленно и мучительно. Завершение работы через раз с крашем. Режим amNonBlocking ненамного лучше, те же яйца только в профиль, годится только для клиентского интерфейса работы с БД. Перемудрили что-то разработчики там с потоками. Остался режим amBlocking + TTrhead. Класс для простоты общения со средом: //--------------------------------------------------------------------------- class TMyDBConnThread : public TThread { private: TInterlocked *Interlocked; TNotifyEvent FOnExecute; TNotifyEvent FOnReady; void __fastcall SyncReady(){ FOnReady(this); } protected: void __fastcall Execute(); public: __fastcall TMyDBConnThread(bool CreateSuspended); __property TNotifyEvent OnExecute = { read = FOnExecute, write = FOnExecute }; __property TNotifyEvent OnReady = { read = FOnReady, write = FOnReady }; TFDConnection *connection; TFDQuery *query; TSimpleEvent *event; int buzy; }; //--------------------------------------------------------------------------- //--------------------------------------------------------------------------- void __fastcall TMyDBConnThread::Execute() { Interlocked = new TInterlocked; while ( !Terminated ) { event->WaitFor( INFINITE ); if ( Terminated ) break; Interlocked->Exchange( buzy, 1 ); FOnExecute(this); Interlocked->Exchange( buzy, 0 ); event->ResetEvent(); Synchronize( SyncReady ); } delete Interlocked; delete event; } //--------------------------------------------------------------------------- Вся работа с бд в FOnExecute и потокозащищенный колбэк FOnReady. Далее удивление: устойчивая работа, отсутствие ошибок, 9000+ запросов в БД в секунду и при этом 20-30% загрузки, в асинхронном режиме для сравнения 1500 запросов под 60%. Все зависит от степени кривизны рук, однако...