Если вы изучите документацию JMeter , у вас будет четкое представление о том, что JMeter - это инструмент тестирования производительности, а не инструмент автоматизации пользовательского интерфейса. Поддерживает множество протоколов. Из документации -
Возможность загрузки и тестирования производительности множества различных приложений / серверов / типов протоколов:
blockquote>
- Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP .NET,…)
- Веб-сервисы SOAP / REST
- FTP
- База данных через JDBC
- LDAP
- Промежуточное программное обеспечение, ориентированное на сообщения (MOM) ) через JMS
- Собственные команды или сценарии оболочки
- TCP
- Объекты Java
Это, как говорится, поддерживает много различные протоколы, он может использоваться для имитации действий браузера конечных пользователей, которые происходят по протоколу HTTP [из многих других вещей]. Но помните, что документ также ясно показывает, что, как показано ниже
JMeter не является браузером, он работает на уровне протокола. Что касается веб-сервисов и удаленных сервисов, JMeter выглядит как браузер (точнее, несколько браузеров); однако JMeter не выполняет все действия, поддерживаемые браузерами. В частности, JMeter не выполняет Javascript, найденный на страницах HTML. Он также не отображает HTML-страницы так, как это делает браузер (можно просмотреть ответ в виде HTML и т. Д., Но время не включено ни в какие примеры, и одновременно отображается только один образец в одном потоке). [1115 ] blockquote>
TL; DR - Короче говоря, JMeter не вызывает браузер по умолчанию, но имитирует действие, записанное вами с использованием HTTP-сэмплера.
Если вы хотите выполнять запись и воспроизведение для простых действий пользователя, которые фактически вызывают браузеры вместо того, чтобы имитировать, вам следует взглянуть на Selenium IDE Если вы нужно вызвать браузер с помощью JMeter, а затем взглянуть на WebDriver Sampler
Вы должны рассказать нам больше об оборудовании и операционной системе, а также о конкретной версии Java. Как вы измеряете эту пропускную способность?
Вы правы, что принудительная синхронизация должна принудительно передавать данные на физический носитель.
Вот необработанная версия копии. Скомпилированный с gcc 4.0 на Intel Mac, должен быть чистым.
/* rawcopy -- pure C, system calls only, copy argv[1] to argv[2] */
/* This is a test program which simply copies from file to file using
* only system calls (section 2 of the manual.)
*
* Compile:
*
* gcc -Wall -DBUFSIZ=1024 -o rawcopy rawcopy.c
*
* If DIRTY is defined, then errors are interpreted with perror(3).
* This is ifdef'd so that the CLEAN version is free of stdio. For
* convenience I'm using BUFSIZ from stdio.h; to compile CLEAN just
* use the value from your stdio.h in place of 1024 above.
*
* Compile DIRTY:
*
* gcc -DDIRTY -Wall -o rawcopy rawcopy.c
*
*/
#include <fcntl.h>
#include <sys/types.h>
#include <sys/uio.h>
#include <stdlib.h>
#include <unistd.h>
#if defined(DIRTY)
# if defined(BUFSIZ)
# error "Don't define your own BUFSIZ when DIRTY"
# endif
# include <stdio.h>
# define PERROR perror(argv[0])
#else
# define CLEAN
# define PERROR
# if ! defined(BUFSIZ)
# error "You must define your own BUFSIZ with -DBUFSIZ=<number>"
# endif
#endif
char * buffer[BUFSIZ]; /* by definition stdio BUFSIZ should
be optimal size for read/write */
extern int errno ; /* I/O errors */
int main(int argc, char * argv[]) {
int fdi, fdo ; /* Input/output file descriptors */
ssize_t len ; /* length to read/write */
if(argc != 3){
PERROR;
exit(errno);
}
/* Open the files, returning perror errno as the exit value if fails. */
if((fdi = open(argv[1],O_RDONLY)) == -1){
PERROR;
exit(errno);
}
if((fdo = open(argv[2], O_WRONLY|O_CREAT)) == -1){
PERROR;
exit(errno);
}
/* copy BUFSIZ bytes (or total read on last block) fast as you
can. */
while((len = read(fdi, (void *) buffer, BUFSIZ)) > -1){
if(len == -1){
PERROR;
exit(errno);
}
if(write(fdo, (void*)buffer, len) == -1){
PERROR;
exit(errno);
}
}
/* close and fsync the files */
if(fsync(fdo) ==-1){
PERROR;
exit(errno);
}
if(close(fdo) == -1){
PERROR;
exit(errno);
}
if(close(fdi) == -1){
PERROR;
exit(errno);
}
/* if it survived to here, all worked. */
exit(0);
}
На самом деле, в C вы хотите просто вызвать fsync ()
для одного файлового дескриптора, не sync ()
(или команда «sync»), которая сигнализирует ядру о сбрасывать
все буферы на диск всей системы.
Если вы strace
(здесь речь идет о Linux), JVM, которую вы должны наблюдать за системным вызовом fsync ()
или fdatasync ()
в вашем выходном файле. Это было бы тем, что я ожидал бы сделать из вызова getFD ()
. sync ()
. Я предполагаю, что c.force (true)
просто указывает NIO, что fsync ()
следует вызывать после каждой записи. Возможно, просто то, что используемая вами JVM на самом деле не реализует вызов sync ()
?
Я не уверен, почему вы не ' Не вижу никакой разницы при вызове «sync» как команды: но очевидно, что после первого вызова sync последующие обычно намного быстрее. Опять же, я был бы склонен выделить strace
(ферму на Solaris) как «что на самом деле здесь происходит?» инструментом.
Код на C может быть неоптимальным, поскольку он использует stdio, а не raw OS write (). Но тогда java может быть более оптимальным, поскольку он выделяет большие буферы?
В любом случае, вы можете доверять только APIDOC. Остальное не входит в ваши обязанности.