About JMeter CLI tests,
If I need only CLI, without any GUI, what minimal files can I use?
Can I keep only bin and lib folders?
Are there jars used only in GUI that can be removed?
Current latest version size is more than 120 MB and I need to lower size to a minimum
If I need only CLI, without any GUI, what minimal files can I use? - depending on what test elements you're using in your test, for example if you're using only HTTP Request samplers you will need ApacheJMeter_http.jar and ApacheJMeter_core.jar (maybe ApacheJMeter_components.jar if you need to use configuration elements, timers, etc.)
So you need to analyze your test and use JMeter Plugins Manager to uninstall the components you don't need, it will reduce space requirements and make your JMeter instance faster.
Can I keep only bin and lib folders? - yes
Are there jars used only in GUI that can be removed? - no, according to TestElement Contract they are not separated
I think the most space consuming is docs folder so if you need offline documentation version you can delete it and JMeter will take twice less disk space
Related
I want to replace the files whenever I deploy. Instead of replacing the existing ones, they just add up to the folder because each filenames are dynamically made.
I came across this "Remove additional files" default false and could be a solution to my problem.
However, while reading the description, the "destination" is kind of vague. Documentation here
When True instructs Web Deploy to delete files from the destination
that aren't in the source package
Is the "destination" pertains to the physical path?
Yes, the destination will be the value of the Physical Path setting.
I think the setting that will be of value to you is the File comparison method. It indicates the algorithm by which comparisons will be made to determine which files, if any, should be updated by the package.
This link is to a blog post in which the Timestamp and Checksum algorithms are discussed. I have included a portion of this post below.
Timestamp instead of checksum
In Octopus 3.0 we decided to make
Checksum the default (and only choice) for syncing files with
WebDeploy. Using checksum we would only deploy files which had
actually changed, without needing any special configuration. This
reduces the time and bandwidth required for subsequent deployments to
the same web app. This works really nicely for moderate sized
applications but, as we discovered, becomes prohibitively slow and
unreliable for large applications.
If you find yourself in this situation you can switch to using
Timestamp for file comparison instead of Checksum using Octopus Deploy
3.3.3 or newer.
Timestamp
If you have any existing Azure Web App steps you will need to update
them to use timestamp and create a new release. Any new Azure Web App
steps you create will use timestamp by default, but you can always
switch to checksum if that suits your needs better.
If you prefer checksum, we are planning to upgrade to
Microsoft.Web.Deployment.3.6.0 which has several bug fixes for
checksum comparisons.
Preserving timestamps
The downside with using timestamps for file
comparison is reliability - you can easily get false-positives -
that's why checksum is so attractive. If you are using NuGet packages
the timestamp of your files will be lost when they are unpacked
meaning every file appears to be newer and will be uploaded regardless
of whether it has changed - more detail. To work around this, consider
using zip packages - we have automated tests proving the timestamps
are preserved end-to-end through your deployments.
Fine uploader is 400kb of javascript code and 140kb minified. Since I am not using the UI and only using the API, I would like to build the library without the integrated interface (and hopefully get a smaller lib consequently). Is this possible?
Could not find this in the downloads section.
I've also setup the build environment and built the package myself, but all the files in the _dist dir seem to be bundled with the UI.
Fine Uploader is only 40 kB gzipped, which is compression that pretty much every web server already utilizes. The build is not currently setup to create a bundle without the UI. If you'd like to create such a build, the modules.js file will need to be modified. One place to start would be with a copy of the fuTraditional module sans the #fuSrcUi module. Then, a corresponding entry would need to be added to the concat.js build file. This doesn't seem worth it to save a few kB in my humble opinion, but it's all very possible.
If you're interested in a much more modular upload library where almost every feature is represented as an optional standalone module, take a look at Modern Uploader, which I am slowly developing as time allows. Feel free to open up issues in the repo if you have any questions regarding the future of that product.
I'm working on existing (not mine) Maven project which generates pretty big .war file ~37MB. More than 20MB is made of ExtJs 4.1 files (.js and .css).
I'm not sure which files are really required and which can be removed. I found out that I can remove unnecessary files with Sencha CMD but I'm not sure if it is compatibile with ExtJs 4.1. However, I tried to run it, but it always says Command must be run from an app or package folder.
Here is structure of my project: http://prntscr.com/4o97zy
Any help is apperciated!
In production you can just ext-all.* and remove rest of them which reduces size application size by 10MB. Here is the bare minimum structure that you can have in production. If you use any additional plugins include them as well. I would suggest to keep ext-all-debug.js/css as well, use maven profiles to take care of copying ext-all.* or ext-all-debug*.
The above structure is of size 2.5MB, more or less that will almost be sufficient. You can miniify these files and put it into your war. There are multiple ways of doing it. You can use ycompressor to compress and put it in your webapp or from server side you can compress files whenever user requests(Google-web utilities).
What is the difference between using ext-all.js and ext-all-debug.js?
Does changing to ext-all.js from debug.js improve performance?
Can I assume that switching from debug to normal file will not have any other impacts on the application?
Also, can any one suggest what ext-base.js do?
Ext-all is basically the minified verion of the debug one. The gain is that it greatly reduces the files size so that clients have to download less. Ext-base are the core functions of ext. If you only use those you could just include that file instead of the huge complete set in ext-all.
On the ext site there used to be a custom js builder where you would pick just the functions you need and it would create a custom js for you with just those modules
Ext-all-debug is provided so that you can debug through the extjs code. It performs extactly the same operations that ext-all.js does. Using ext-all.js will improve performance since the size of the file is much smaller, hence clients can download and access them faster.
Same is the case with ext-base-debug and ext-base.js. These contain the operations on which ext-all.js depends on, for example Ajax operations. Interchanging these files will not have any effect on your application.
Use the ext-all-debug and ext-base-debug during development. Switch to ext-all.js and ext-base.js when in production.
THIS INFORMATION HAS CHANGED FOR THOSE USING ExtJS4.1.
After implementing and optimizing an application, I like many, was confused with which process was optimal for 'production implementation'.
This most current documentation for this turned out to be this document on Sencha:
http://docs.sencha.com/ext-js/4-1/#!/guide/getting_started
It was difficult to identify, but the key for me was step #3. Deploying Application.
For which these four steps are conducted:
cd to root
sencha create jsb - this creates a manifest of classes used.
- it can also be modified prior to build, in case it is needed.
sencha build - creates two files(all-classes.js, app-all.js)
- all-classes.js is non min for review.
- app-all.js is the production ready file
Setup for prod - these are the remaining includes needed in your production file:
ext-all.css //minified-css, concatenated and dusted is optimal.
ext/ext.js //non-debug
app-all.js //minified, concatenated, app + framework files (only classes used).
Hope this helps someone. : )
differences between "ext.js" and "ext-debug.js" are:
"ext-debug" is not compressed (or "minified").
"ext-debug" is not run through the Cmd optimizer.
These files otherwise contain exactly the same code. Further, both flavors download required classes from the "src" folder. In short, both of these files are intended to support debugging.
In order to improve the performance,To reduce the downloads to as few files as possible you can use Sencha Cmd. some thing like this
sencha fs minify -yui -from=ext-debug.js -to=ext.js
For Cmd topics ext 4.2.2 doc set is the more current and you can access the dec here
hope this may help you.
How do patches or service packs work? I don't know how to explain my question but I will give a try
Take Windows for example. It has files which altogether consume 100s of MB. Now a single service pack (may be 300 MB file) updates the whole windows OS.
Similarly I have seen updates happening for softwares like adobe reader etc. In all these cases the main exe is much larger compared to the update. How does the process work? If the main file refers any dependancy files and if the update change the version or size. Will it not affect the exe?
Patches and service packs usually only need to update core shared libraries of the system. These libraries are replaced or patched from a compressed archive, hence their size. Once the libraries are updated the rest of the software of the OS can continue using the new versions.
Applications nowadays are designed to be modular and to use external libraries which can be updated easily. Sometimes the main application or any media used does not need to be replaced, only the library that's changed.
To complement earlier answers, back in the day, when file size really mattered, some patches were delivered as binary diffs, meaning, the patch itself was an executable that knew what files needed to be changed, and how, and it actually changed only a certain part of the files' zeroes and ones, locally, instead of replacing the files entirely.
Following URL may be of interest to you in knowing architecture.
http://msdn.microsoft.com/en-us/library/aa387291(VS.85).aspx
Patches (also called deltas) are only the differences between two files. If only few bytes of 1GB file change, patch will have only few bytes of size. For text files diff is used, for binary files xdelta or similar. Service packs are collections of patches.