Как найти производительность контейнера

Тест производительности контейнеров и указателей на объекты

Время на прочтение
5 мин

Количество просмотров 4.2K

Вступление

В данной статье рассмотрен тест производительности заполнения (push_back) контейнеров объектами, содержащими разные типы указателей на разные типы данных. Тест комплексный, сочетающий в себе типичные задачи создания указателя на объект, копирование объекта, заполнение контейнера, освобождение выделенной под объект памяти средствами умного указателя и стандартным оператором delete. Будут протестированы три контейнера стандартной библиотеки шаблонов – vector, list, deque, три вида указателей – std::shared_ptr, std::auto_ptr и простой указатель. В качестве испытуемых типов данных (на которые будут создаваться указатели) использованы long, std::string, char, произвольный класс.

Описание теста

Исходный код написан в среде MS Visual Studio 2010, и требует от компилятора поддержку лямбда функций.
Пусть некоторый класс содержит описание указателя T на тип данных Type. Конструктор будет создавать объект, и инициализировать переданным параметром. Конструктор копирования будет копировать значение, находящееся по адресу указанного объекта, а также его имя и требование выводить в консоль сообщения о жизни объекта.

template< class T, typename Type >
class test_type_and_smart_pointer
{
public:
test_type_and_smart_pointer( std::string const& val, bool msg, Type type_val )
	: _msg( msg ), _name( val )
{
	if( _msg )
		std::cout << "created " << _name << std::endl; 
	x.reset( new Type );
	*x = type_val;
}
~test_type_and_smart_pointer()
{
	if( _msg )
		std::cout << "deleted " << _name << std::endl; 

}
test_type_and_smart_pointer(const test_type_and_smart_pointer & W)
{
	if( W._msg )
		std::cout << "copied " << W._name << std::endl; 
	this->x.reset( new Type );
	*(this->x) = *(W.x);
	this->_name = W._name;
	this->_msg = W._msg;
}
private:
T x;
bool _msg;
std::string _name;
};

Параметры шаблона:

  • class T – подразумеваемый класс умного указателя,
  • typename Type – тип данных создаваемого объекта.

Члены класса test_type_and_smart_pointer:

  • T x — непосредственно сам указатель на объект,
  • bool _msg — флаг вывода информационных сообщений,
  • std::string _name – имя созданного объекта.

Создадим подобный класс для случая, если указатель T на тип Type будет стандартным.

template< class T, typename Type >
class test_type_and_simple_pointer
{
public:
test_type_and_simple_pointer( std::string const& val, bool msg, Type type_val )
	: _msg( msg ), _name( val )
{
	if( _msg )
		std::cout << "created " << _name << std::endl; 
	x = new Type;
	*x = type_val;
}
~test_type_and_simple_pointer()
{
	delete x;
	if( _msg )
		std::cout << "deleted " << _name << std::endl; 

}
test_type_and_simple_pointer(const test_type_and_simple_pointer & W)
{
	if( W._msg )
		std::cout << "copied " << W._name << std::endl; 
	this->x = new Type( *(W.x) );
	this->_name = W._name;
	this->_msg = W._msg;
}
private:
T x;
bool _msg;
std::string _name;
};

Теперь нужны функции, создающие выше описанные объекты:

template< typename _Ptr, typename T, typename Container, bool msg >
void test_smart_ptr( bool big_data, T val )
{
using namespace std;
test_type_and_smart_pointer< _Ptr, T > x( "a001", msg, val );
test_type_and_smart_pointer< _Ptr, T > x2( x );
Container cnt;
cnt.push_back( x );
cnt.push_back( x2 );
if( big_data )
	for( int i = 0; i <= 100; i++ )
	{
		test_type_and_smart_pointer< _Ptr, T > xx( "a002", msg, val );
		test_type_and_smart_pointer< _Ptr, T > xx2( xx );
		cnt.push_back( xx );
		cnt.push_back( xx2 );
	}

	cnt.clear();
}

template< typename T, typename Container, bool msg >
void test_simple_ptr( bool big_data, T val )
{
using namespace std;
test_type_and_simple_pointer< T*, T> x( "b001", msg, val );
test_type_and_simple_pointer< T*, T> x2( x );
Container cnt;
cnt.push_back( x );
cnt.push_back( x2 );
if( big_data )
	for( int i = 0; i <= 100; i++ )
	{
		test_type_and_simple_pointer< T*, T> xx( "b002", msg, val );
		test_type_and_simple_pointer< T*, T> xx2( xx );
		cnt.push_back( xx );
		cnt.push_back( xx2 );
	}
	cnt.clear();
}

Например, эти функции будут работать в двух режимах: создание пары указателей на объекты и размещение их в контейнере, и циклическое создание указателей на объекты и заполнение контейнера.
Время, затраченное на исполнение функций test_smart_ptr и test_simple_ptr будет измерять _time_test:

double _time_test(  std::function< void() > test_func, unsigned int times )
{
using namespace std;
double start = 0, end = 0;
start = GetTickCount();
for( unsigned int i = 0; i < times; i++ )
{
	test_func();
}
end = GetTickCount() - start;
//cout << "Elapsed ms: " << end <<
//	" for " << times << " times " << endl;
return end;
}

Необходимые заголовочные файлы:


#include "iostream"
#include "string"
#include "vector"
#include "list"
#include "deque "

#include <Windows.h>
#include "functional" 

В качестве объекта произвольного типа использован простейший класс без динамических выделений памяти.


class some_obj
{
public:
	some_obj()
	{
		i = 90000;
		s = "1231231231231231231232";
		d = 39482.27392;
	}
	~some_obj()
	{
	}
private:
	int i;
	std::string s;
	double d;
};

Итак, как проводился тест. Описаны 72 лямбда функции, каждая из которых при завершении приводит кучу в исходное состояние.


int main()
{
using namespace std;

const long long_val = 900000000;
const char ch = 'a';
const string str = "abc";
	///////////////////////////////////////////////////////////////////////////////////////////////////////

auto f_01 = [&]() -> void
{ test_smart_ptr< shared_ptr< long >, long, vector< test_type_and_smart_pointer< shared_ptr< long >, long > >, false >( false, long_val ); };
auto f_02 = [&]() -> void
{ test_smart_ptr< shared_ptr< char >, char, vector< test_type_and_smart_pointer< shared_ptr< char >, char > >, false >( false, ch ); };
auto f_03 = [&]() -> void
{ test_smart_ptr< shared_ptr< string >, string, vector< test_type_and_smart_pointer< shared_ptr< string >, string > >, false >( false, str ); };
auto f_04 = [&]() -> void
{ 
some_obj x;
test_smart_ptr< shared_ptr< some_obj >, some_obj, vector< test_type_and_smart_pointer< shared_ptr< some_obj >, some_obj > >, false >( false, x ); 
};

...
_time_test( f_01, 100000 );
_time_test( f_02, 100000 );
_time_test( f_03, 100000 );
_time_test( f_04, 100000 );

...

return 0;
}

Полный код функции main не приведен, ввиду громоздкости, но по первому блоку лямбда функций для указателя shared_ptr общая тенденция комбинаций параметров шаблонов видна.

Каждая функция f_nn выполнялась 15 раз и результат измерения усреднен (запуск был в релизном режиме не из под студии). За единицу принято самое малое затраченное время, т.е. остальные значения приведены в пропорции.

Результаты теста

Цветом обозначен наиболее быстрый тип данных по каждому типу указателя среди всех контейнеров:

Наиболее быстрые типы данных по каждому контейнеру среди всех типов указателей:

Наиболее быстрый контейнер при заполнении по всем типам данных и по всем указателям:

Что полезное можно извлечь?

Во-первых, по результатам теста видно, какой контейнер заполняется быстрее.
Во-вторых, понятно как в пропорциональном соотношении по скорости работают указатели на типичных задачах.

На чтение 2 мин Опубликовано 06.04.2020

Я запускаю несколько Docker-контейнеров на одном сервере CentOS с ограниченным объемом памяти.

(Я только недавно увеличил его с 0,5 до 1 гигабайта!)

Прежде чем вывести еще один контейнер в Интернет, я хотел бы проверить, сколько у меня места.

Поскольку последние версии Docker уже недоступны для CentOS 6, я использую древнюю версию 1.7 или около того.

В новых версиях Docker запуск docker stats вернет статистику обо всех работающих контейнерах, но в старых версиях вы должны передать docker идентификатор контейнера.

Вот быстрый однострочник, который отображает статистику всех ваших работающих контейнеров для старых версий.

$ docker ps -q | xargs  docker stats --no-stream
CONTAINER           CPU %               MEM USAGE/LIMIT     MEM %               NET I/O
31636c70b372        0.07%               130.8 MB/1.041 GB   12.57%              269.7 kB/262.8 kB
8d184dfbeeaf        0.00%               112.8 MB/1.041 GB   10.84%              45.24 MB/32.66 MB
a63b24fe6099        0.45%               50.09 MB/1.041 GB   4.81%               1.279 GB/1.947 GB
fd1339522e04        0.01%               108.2 MB/1.041 GB   10.40%              8.262 MB/23.36 MB

docker ps -q возвращает список запущенных идентификаторов контейнеров, который мы затем передаем через xargs в docker stats.

Добавление –no-stream дает нам только первый результат вместо постоянного обновления статистики, но без него это также работает прекрасно.

Это аккуратный маленький трюк.

Если кто-то знает, как сделать вывод имен контейнеров вместо идентификаторов, пожалуйста, прокомментируйте ниже.

Опять же, это не нужно для новейших версий.

Просто запустите docker stats, и вы получите почти идентичный вывод.

Пожалуйста, не спамьте и никого не оскорбляйте.

Это поле для комментариев, а не спамбокс.

Рекламные ссылки не индексируются!

Хотя Docker намного легче традиционных виртуальных машин, слишком большое количество контейнеров может быстро потреблять ресурсы вашего хоста. Вот как можно проверить использование оборудования и отслеживать количество процессов внутри ваших контейнеров.

Команда Docker Stats

Встроенный механизм Docker для просмотра потребления ресурсов — это статистика Docker. Эта команда дает вам табличное представление ваших контейнеров. Каждый контейнер отображает в реальном времени свои критические показатели.

Выходные данные команды включают потребление ЦП и показатель использования сети и хранилища каждого контейнера в течение его жизненного цикла. Столбец Память показывает использование оперативной памяти, а также ограничение памяти, настроенное для контейнера. Если ограничение не установлено, вы увидите объем оперативной памяти, доступной на вашем хосте. Последний столбец, PIDS, представляет собой количество процессов, запущенных контейнером.

Остановленные контейнеры по умолчанию исключаются. Вы можете добавить их в таблицу, передав команде флаг -a (—all). Использование ЦП и памяти будет недоступно, но вы сможете увидеть показатели, агрегированные за время существования контейнера, такие как сетевая активность.

Вы можете просматривать статистику одного и нескольких контейнеров так же, как и другие распространенные команды CLI Docker. Передайте список идентификаторов или имен контейнеров, разделенных пробелами. На выходе будут показаны метрики для указанных контейнеров, все остальное будет удалено.

Docker stats первый контейнер второй контейнер

docker stats поддерживает настраиваемое форматирование, поэтому вы можете выбрать только нужные столбцы. Флаг —format принимает Go строка-заполнитель что позволяет создавать пользовательские визуализации данных.

Вот как показать имена контейнеров с метриками использования ЦП и памяти:

docker stats —format «table {{.Name}} t {{. CPUPerc}} t {{. MemUsage}}»

Тип форматирования таблицы добавляет заголовки столбцов к выводу. Опустите это, если вам нужны необработанные данные без табуляции. Если вы регулярно используете одну и ту же строку форматирования, рассмотрите возможность добавления ее в качестве псевдонима оболочки для облегчения доступа.

Получение дополнительной информации

Более подробную информацию об использовании ресурсов контейнера можно получить по проверка своей контрольной группы (cgroup). Этот механизм ядра отслеживает потребление группой процессов, отображая собранные метрики в псевдофайловой системе.

Доступны две версии системы cgroup. v2 поддерживается только в Docker 20.10 или новее с ядром Linux v4.15. В более старых выпусках будет использоваться версия v1. Документация по v2 еще не завершена, поэтому с v1 будет проще работать.

Чтобы найти контрольную группу контейнера, вам необходимо определить, какая версия активна, и знать полный идентификатор контейнера. Это должна быть полная версия, а не усеченная форма, показанная в выводе docker ps и docker stats. Вы можете найти его, запустив docker ps —no-trunc.

Объедините идентификатор контейнера с путем к каталогу групп управления вашей системы. Пути для v1 и v2 задокументированы от Docker. Затем вы можете проверить псевдофайловую систему, чтобы найти подробную статистику ресурсов. Вот путь для определения использования памяти контейнером при использовании cgroups v1:

cat / sys / fs / cgroup / memory / docker / <полный идентификатор контейнера> /memory.stat

В файл памяти предоставляет подробную информацию о потреблении, ограничениях, подкачке и использовании подкачки.

Поиск метрик ресурсов с помощью Docker API

Более простой способ получить доступ к этой информации — через Docker API. Это включено по умолчанию через сокет Unix демона Docker. Конечная точка / container / {id} / stats предоставляет подробные сведения об использовании ресурсов. Замените {id} идентификатором вашего контейнера.

curl —unix-socket /var/run/docker.sock «http: //localhost/v1.41/containers/ {id} / stats» | jq

В этом примере мы используем curl. Он проинструктирован использовать сокет демона Docker с помощью флага —unix-socket. Docker API вернет данные в формате JSON; это передается в jq, чтобы сделать его более читаемым в терминале.

Каждый Ответ API содержит подробную информацию о текущем и прошлом использовании ресурсов контейнера. Это числовые данные, предназначенные для использования станками. Значения представлены «в сыром виде» и не могут быть сразу понятны без дальнейшей обработки или ввода в инструментальную панель.

Просмотр запущенных процессов

Отдельная команда docker top позволяет увидеть текущий список процессов указанного контейнера:

докер верхний мой-контейнер

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

Вы также можете получить эту информацию из API. Используйте тот же подход, что и описанный выше, заменив конечную точку / container / {id} / stats на / container / {id} / top.

Docker не предоставляет интегрированного способа просмотра использования ресурсов для каждого процесса. Если вам нужна эта информация, лучше всего прикрепить к контейнеру и установить сверху или htop. Эти инструменты дадут вам более глубокое представление об активности контейнера.

docker exec -it my-container sh # замените команды диспетчера пакетов apt update && apt install htop -y htop

Резюме

Демон Docker собирает и предоставляет в реальном времени и историческую статистику потребления ресурсов для ваших контейнеров. Вы можете получить доступ к базовому графическому представлению данных с помощью статистики Docker, но для более сложных считываний требуется Docker API или проверка группы ручного управления.

Вы также можете перечислить запущенные процессы контейнера, но команда docker top не показывает никаких показателей ресурсов. Это означает, что его использование при проверке ограничено. Зачем в контейнере слишком много ЦП или памяти. Вам нужно будет прикрепиться к нему вручную и осмотреть изнутри.

Инструменты Docker нацелены на общий мониторинг и наблюдаемость, а не на детальную проверку для облегчения решения проблем. В большинстве случаев они вполне адекватны, но хорошо знакомы с более широкими инструментами мониторинга Linux, которые работают. внутри контейнеры будут более эффективными при решении проблем.

I’d like to comprehensively understand the run-time performance cost of a Docker container. I’ve found references to networking anecdotally being ~100µs slower.

I’ve also found references to the run-time cost being “negligible” and “close to zero” but I’d like to know more precisely what those costs are. Ideally I’d like to know what Docker is abstracting with a performance cost and things that are abstracted without a performance cost. Networking, CPU, memory, etc.

Furthermore, if there are abstraction costs, are there ways to get around the abstraction cost. For example, perhaps I can mount a disk directly vs. virtually in Docker.

noɥʇʎԀʎzɐɹƆ's user avatar

noɥʇʎԀʎzɐɹƆ

9,7492 gold badges47 silver badges66 bronze badges

asked Feb 19, 2014 at 18:19

Luke Hoersten's user avatar

Luke HoerstenLuke Hoersten

8,2753 gold badges21 silver badges18 bronze badges

7

An excellent 2014 IBM research paper “An Updated Performance Comparison of Virtual Machines and Linux Containers” by Felter et al. provides a comparison between bare metal, KVM, and Docker containers. The general result is: Docker is nearly identical to native performance and faster than KVM in every category.

The exception to this is Docker’s NAT — if you use port mapping (e.g., docker run -p 8080:8080), then you can expect a minor hit in latency, as shown below. However, you can now use the host network stack (e.g., docker run --net=host) when launching a Docker container, which will perform identically to the Native column (as shown in the Redis latency results lower down).

Docker NAT overhead

They also ran latency tests on a few specific services, such as Redis. You can see that above 20 client threads, highest latency overhead goes Docker NAT, then KVM, then a rough tie between Docker host/native.

Docker Redis Latency Overhead

Just because it’s a really useful paper, here are some other figures. Please download it for full access.

Taking a look at Disk I/O:

Docker vs. KVM vs. Native I/O Performance

Now looking at CPU overhead:

Docker CPU Overhead

Now some examples of memory (read the paper for details, memory can be extra tricky):

Docker Memory Comparison

ib.'s user avatar

ib.

27.6k10 gold badges79 silver badges100 bronze badges

answered Oct 1, 2014 at 20:26

Hamy's user avatar

20

Docker isn’t virtualization, as such — instead, it’s an abstraction on top of the kernel’s support for different process namespaces, device namespaces, etc.; one namespace isn’t inherently more expensive or inefficient than another, so what actually makes Docker have a performance impact is a matter of what’s actually in those namespaces.


Docker’s choices in terms of how it configures namespaces for its containers have costs, but those costs are all directly associated with benefits — you can give them up, but in doing so you also give up the associated benefit:

  • Layered filesystems are expensive — exactly what the costs are vary with each one (and Docker supports multiple backends), and with your usage patterns (merging multiple large directories, or merging a very deep set of filesystems will be particularly expensive), but they’re not free. On the other hand, a great deal of Docker’s functionality — being able to build guests off other guests in a copy-on-write manner, and getting the storage advantages implicit in same — ride on paying this cost.
  • DNAT gets expensive at scale — but gives you the benefit of being able to configure your guest’s networking independently of your host’s and have a convenient interface for forwarding only the ports you want between them. You can replace this with a bridge to a physical interface, but again, lose the benefit.
  • Being able to run each software stack with its dependencies installed in the most convenient manner — independent of the host’s distro, libc, and other library versions — is a great benefit, but needing to load shared libraries more than once (when their versions differ) has the cost you’d expect.

And so forth. How much these costs actually impact you in your environment — with your network access patterns, your memory constraints, etc — is an item for which it’s difficult to provide a generic answer.

answered Sep 26, 2014 at 21:18

Charles Duffy's user avatar

Charles DuffyCharles Duffy

276k43 gold badges379 silver badges434 bronze badges

5

Here’s some more benchmarks for Docker based memcached server versus host native memcached server using Twemperf benchmark tool https://github.com/twitter/twemperf with 5000 connections and 20k connection rate

Connect time overhead for docker based memcached seems to agree with above whitepaper at roughly twice native speed.

Twemperf Docker Memcached

Connection rate: 9817.9 conn/s
Connection time [ms]: avg 341.1 min 73.7 max 396.2 stddev 52.11
Connect time [ms]: avg 55.0 min 1.1 max 103.1 stddev 28.14
Request rate: 83942.7 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 83942.7 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 28.6 min 1.2 max 65.0 stddev 0.01
Response time [ms]: p25 24.0 p50 27.0 p75 29.0
Response time [ms]: p95 58.0 p99 62.0 p999 65.0

Twemperf Centmin Mod Memcached

Connection rate: 11419.3 conn/s
Connection time [ms]: avg 200.5 min 0.6 max 263.2 stddev 73.85
Connect time [ms]: avg 26.2 min 0.0 max 53.5 stddev 14.59
Request rate: 114192.6 req/s (0.0 ms/req)
Request size [B]: avg 129.0 min 129.0 max 129.0 stddev 0.00
Response rate: 114192.6 rsp/s (0.0 ms/rsp)
Response size [B]: avg 8.0 min 8.0 max 8.0 stddev 0.00
Response time [ms]: avg 17.4 min 0.0 max 28.8 stddev 0.01
Response time [ms]: p25 12.0 p50 20.0 p75 23.0
Response time [ms]: p95 28.0 p99 28.0 p999 29.0

Here’s bencmarks using memtier benchmark tool

memtier_benchmark docker Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       16821.99          ---          ---      1.12600      2271.79
Gets      168035.07    159636.00      8399.07      1.12000     23884.00
Totals    184857.06    159636.00      8399.07      1.12100     26155.79

memtier_benchmark Centmin Mod Memcached

4         Threads
50        Connections per thread
10000     Requests per thread
Type        Ops/sec     Hits/sec   Misses/sec      Latency       KB/sec
------------------------------------------------------------------------
Sets       28468.13          ---          ---      0.62300      3844.59
Gets      284368.51    266547.14     17821.36      0.62200     39964.31
Totals    312836.64    266547.14     17821.36      0.62200     43808.90

answered Apr 19, 2015 at 20:31

p4guru's user avatar

p4gurup4guru

1,3902 gold badges18 silver badges25 bronze badges

3

Runtime Librairies Comparison

I’m going to approach the question about runtime performance cost of a container in respect to runtime libraries.

Speed: Musl vs. glibc

In Apline Linux containers, the runtime libraries are provided by Musl in lieu of glibc, and according to the below link, there can be a performance difference between the two:

https://www.etalabs.net/compare_libcs.html

I’ve read various opinions researching this topic that being both tiny & significantly more modern, Musl also confers some degree of greater security over glibc. Haven’t been able to locate any data to support these views however.

Compatibility

Even were Musl faster & more secure, it can however present compatibility issues because Musl is materially different than glibc. I find though if I’m creating a docker image using apk to pull in my packages, of course there’s no capability issues.

Conclusion

If performance matters, cut (2) containers one Alpine Linux with Musl and another using a distro that uses glibc and benchmark them. And of course post your results in the comments!!!!

answered Oct 8, 2022 at 16:03

F1Linux's user avatar

F1LinuxF1Linux

3,4223 gold badges22 silver badges22 bronze badges

В
зарубежной литературе логистическая
система

определяется как процесс «планирования
и координации всех аспектов физического
движения материалов, компонентов и
готовой продукции для минимизации общих
затрат и обеспечения желаемого уровня
сервиса»
.
Цели и результаты функционирования
логистических контейнерных систем
описываются соответствующими
экономическими показателями. Основными
показателями функционирования
контейнерной системы, характеризующими
плановое задание и зависящую от нее
степень достижения глобальной цели
обслуживаемой системы, являются плановый
Qпл
и фактический Qфак
объемы контейнеризируемого груза,
доставляемого потребителю в течение
планового договорного (контрактного)
периода Т.

Объемные
Qпл(Т),
Qфак(Т)
показатели характеризуют в натуральном
выражении плановый и фактический объем
доставляемого потребителю груза. Так
как физические величины объемов
поставляемого продукта не учитывают
повторяемость некоторых дополнительных
технологических и коммерческих операций
и даже этапов функциональных процессов
доставки продукта, то фактический объем
работы, выполненной контейнерной
системой, может охарактеризоваться
показателями:

Кпл.р
плановый коэффициент дополнительной
работы, являющийся отношением планируемого,
с учетом необходимого набора дополнительных
операций доставки, объема перемещенного
груза
к планируемому физическому объемугруза, доставляемого конечному
потребителю:


(10.1)


коэффициент, характеризующий набор
дополнительных операций при транспортировке
груза;

Кфак.р.
фактический коэффициент дополнительной
работы, являющийся отношением фактического,
с учетом реально сложившегося набора
операций доставки, объема перемещенного
груза
к фактическому физическому объемугруза, доставленного конечному
потребителю:

(10.2)

Сопоставление
Кфак.р
и Кпл.р
позволит охарактеризовать степень
организованности контейнерной системы.
Технологические операции доставки,
обусловленные хозяйственными связями,
могут осуществляться в сроки, превышающие
нормативные и с использованием смежных
элементов (складов, транспорта, средств
механизации грузовых работ и др.),
отличающиеся от планово-расчетных.

В
соответствии с этим используются
показатели количественно и качественно
характеризующие работу контейнерного
парка, которые могут быть сформированы
в следующие основные группы:

Показатели,
характеризующие структуру и размер
контейнерного парка.

Под
структурой контейнерного парка
рассматривается доля определенного
набора средств контейнеризации и
пакетирования, предназначенных для
доставки грузов различной номенклатуры
в соответствующих
производственно-транспортно-складских
процессах.

Размер
контейнерного парка характеризуется
в натуральных показателях и денежном
выражении. К натуральным показателям
относятся: общее количество единиц
контейнеров в парке, количество единиц
контейнеров по каждому типоразмеру,
количество условных единиц контейнеров
и количество контейнеро-тонн.

В
натуральном выражении размер контейнерного
парка характеризуется следующими
показателями:

-инвентарный
парк контейнеров, включающий находящихся
в работе на различных этапах процесса
доставки груза и возврата порожних
контейнеров, а также в резерве, ремонте
и техническом обслуживании;

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

Степень
изменения структуры контейнерного
парка в результате выбытия и технического
прогресса оценивается:

-коэффициентом
выбытия, являющимся отношением суммы
затрат на приобретение выбывших
контейнеров Квыб.
к общей сумме затрат на приобретение
всего парка контейнеров ΣК:

(10.3)

-коэффициентом
обновления контейнерного парка,
являющимся отношением суммы затрат на
приобретение новых типоразмеров
контейнеров Кввод.
к общей сумме затрат на приобретение
всего парка контейнеров ΣК:

(10.4)

Показатели,
характеризующие использование
контейнерного парка

Основным
результативным показателем степени
использования контейнерного парка
является производительность Ппр.
средств контейнеризации, определяемая
как отношение суммарного объема груза
,
доставленного контейнером за плановый
период Тпл
всем i-тым
потребителям к величине планового
периода Тпл.:


(10.5)

Важным
показателем, характеризующим использование
парка контейнеров и учитывающим
расстояние транспортирования грузов,
является объем поставляемого груза,
приходящийся на единицу расстояния
транспортирования:

(10.6)

где
ΣL(Т)

суммарное расстояние, на которое
транспортируются грузы в течение
планового периода.

Для
оценки степени использования
грузоподъемности контейнера применяется
коэффициент использования грузоподъемности
kгр.,
определяемый отношением фактического
объема
Qфак
,
доставленного в контейнерах груза к
нормативному объему груза Qнорм.,
который можно было доставить при полном
использовании грузоподъемности
контейнера:

(10.7)

Основным
показателем, характеризующим степень
использования контейнера во времени,
является время полного оборота контейнера
Тоб.
В общем виде время полного оборота
контейнера включает время на выполнение
всех технологических и коммерческих
операций процесса доставки продуктов
в контейнерах от начала его формирования
(загрузки) у отправителя до окончательной
разгрузки у потребителя, а также процесса
возврата порожних контейнеров до момента
его последующего формирования. В
соответствии с этим
Тоб.
определяется:

(10.8)

где
tгр.

время на выполнение грузовых
(погрузочно-разгрузочных,
подъемно-транспортных) операций процесса
доставки груженых и порожних контейнеров);

Rпор.i
(i=1,
2,
3,…, n)

грузовые операции с порожними контейнерами;

Rгр.i
(i=1,
2, 3,…,
n)

грузовые операции с гружеными контейнерами;

tскл.

время нахождения сформированных
контейнеров на этапах складирования;

—время
нахождения порожних контейнеров на
этапах складирования;

tком.оп.
— время на выполнение коммерческих
операций процесса доставки сформированных
и порожних контейнеров;

Cфор.j
(j=1,
2, 3,…, m)
— коммерческие операции с сформированными
контейнерами;

Cпор.j
(j=1,
2, 3,…, m)
— коммерческие операции с порожними
контейнерами;

tтран
— время на выполнение транспортных
операций процесса доставки сформированных
и порожних контейнеров;

Mфор.l
(l=1,
2,…, p)
— транспортные операции с сформированными
контейнерами;

Mпор.l
(l=1,
2,…, p)
— транспортные операции с порожними
контейнерами.

От
величины оборота контейнера Тоб.
в значительной мере зависит число
оборотов Nо6..
контейнеров за плановый период, которое
определяется по формуле:


(10.9)

здесь
Трт

время нахождения контейнера в плановых
ремонтах и техническом обслуживании.

С
целью общего анализа степени использования
контейнеров целесообразно определять
коэффициент использования числа оборотов
контейнера kоб.,
который является отношением фактического
числа оборотов Nфакт.
к расчетному
Nрасч.:

(10.10)

Соседние файлы в папке Экономика жд

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

Добавить комментарий