я думаю что тормозит не потому что такой способ извлечения данных, гхм, применен
вообще в современных проектах очень мало кому (даже совсем некомпетентным людям) удается задействовать хотя бы один CPU на 100%. обычно проект тормозит гораздо раньше чем CPU доходит до 100% и тормозит по совсем другим причинам.
Типа написать "ORM", который при каждом обращении к объекту тянет его ВЕСЬ из БД (как следствие, апач с картинками и статикой отдает на два порядка меньше, чем БД)
Админ, которого позвали разрулить это (я типа "долго возился") выставил myql'ю больше памяти, чем ОС могла выделить одному процессу (i386, естественно), рестартовал mysql и ушел, не проверив, что mysql не поднялся.
"На потолке, в уголке, висит сито, не руками свито" (отгадка: мелкий-мелкий домовый провайдер)
Объект BSON парзится в вариантный тип, который, к сожалению, имеет метод Dump, дампящий содержимое в разные форматы, в том числе - и в JSON. Почему "к сожалению"? Потому, что программист дампит объект в строку JSON, а потом делает по строке find и вставляет все то , что идет после имени поля и до следующей запятой. А как надо было? Правильно ли я понял, что надо было делать не одну строку, а каждое поле отдельно, и лучше всего - в хэш-таблицу?
на сервере 384 Гб оперативки и 24 процессора Это что за сервер такой? Фотку дадите?
Однако, работает не то чтобы быстро - один запрос в 1.7 секунды. Утром программист обнаруживает факт невысокой скорости работы ПО. Так как вы думаете, что он делает? Я думал - он смотрит, какая из операций занимает столько времени.
Кстати, если надо один раз конвертировать одну таблицу в другую - можно и потерпеть. а вот если это боевой сервер, обслуживающий внешние запросы...
Идет к системному архитектору и рассказывает, что сервер слабоват, надо бы ресурсов побольше, и неплохо бы еще донастроить СУБД, куда
( ... )
Comments 19
Reply
Reply
вообще в современных проектах очень мало кому (даже совсем некомпетентным людям) удается задействовать хотя бы один CPU на 100%.
обычно проект тормозит гораздо раньше чем CPU доходит до 100% и тормозит по совсем другим причинам.
Reply
Потому что им SQL в руки не дают. Им можно что угодно нагрузить, умеючи.
Reply
Типа написать "ORM", который при каждом обращении к объекту тянет его ВЕСЬ из БД (как следствие, апач с картинками и статикой отдает на два порядка меньше, чем БД)
Админ, которого позвали разрулить это (я типа "долго возился") выставил myql'ю больше памяти, чем ОС могла выделить одному процессу (i386, естественно), рестартовал mysql и ушел, не проверив, что mysql не поднялся.
"На потолке, в уголке, висит сито, не руками свито" (отгадка: мелкий-мелкий домовый провайдер)
Reply
Слева сидит оракловый дба, неделю назад слушали вой, какой у нас поганый сервер...уже даже не смешно.
Reply
(The comment has been removed)
Reply
А как надо было? Правильно ли я понял, что надо было делать не одну строку, а каждое поле отдельно, и лучше всего - в хэш-таблицу?
на сервере 384 Гб оперативки и 24 процессора
Это что за сервер такой? Фотку дадите?
Однако, работает не то чтобы быстро - один запрос в 1.7 секунды.
Утром программист обнаруживает факт невысокой скорости работы ПО. Так как вы думаете, что он делает?
Я думал - он смотрит, какая из операций занимает столько времени.
Кстати, если надо один раз конвертировать одну таблицу в другую - можно и потерпеть. а вот если это боевой сервер, обслуживающий внешние запросы...
Идет к системному архитектору и рассказывает, что сервер слабоват, надо бы ресурсов побольше, и неплохо бы еще донастроить СУБД, куда ( ... )
Reply
>>Объект BSON парзится в вариантный тип
у объекта этого уже есть свойство с нужным значением, только в запрос для БД осталось вставить
Reply
Leave a comment