kuronen
Visitor.
834 views

iManager load times comparison

As mentioned before I am trying to work remotely with bad connections and I managed to find some help from iManager local frontend / caching. It seems that the latest iManager is quite a bit slower in this so I decided to time it out.

Here are times from clicking "Identity Manager Overview" to driver set overview with visible driver icons - using Apache ajp front end locally with and without caching, two different iManager (and Tomcat) versions.

iManager 2.7.5 / tomcat 5
-------------------------

without caching
0:21 (21 seconds)

with caching
1st time 0:21
2nd time 0:14

Latest iManager 3 with Tomcat 8
-------------------------------

without caching
1:30 (one minute and 30 seconds)

with caching
1st time 1:32
2nd time 1:26

Sadly to my surprise the speed gain is nullified with the iManager 3. Something more is communicated between front end and tomcat application with version 3 and perhaps the nocache headers in the later versions as mentioned in the earlier thread? Some Apache header modifications may help but there must be a reason why content is marked as not cacheable?
Labels (1)
0 Likes
5 Replies
Knowledge Partner
Knowledge Partner

Re: iManager load times comparison

Let's go a step further; I have not tested the following with iManager 3.x
yet, but with iManager 2.7 SP7 Patch 10 it does wonderful things,
decreasing 716874 bytes down to 2753 bytes of actual content sent on the
wire, which is a decent improvement (99% and some, really) after the
browser initially sets up the cache, which mostly happens the first time
iManager's login page is loaded. Those numbers of bytes are from an
actual login (same user, same tree, etc.) before and after implementing a
tiny change in Apache Tomcat.

To implement, go to your web.xml file for Tomcat, which is at
/var/opt/novell/tomcat7/conf/web.xml for my 2.7 SP7 Patch 10 isntance. In
here, go to the end and before the closing web-app tag, add the following:


<filter>
<filter-name>ExpiresFilter</filter-name>
<filter-class>org.apache.catalina.filters.ExpiresFilter</filter-class>
<init-param>
<param-name>ExpiresDefault</param-name>
<param-value>access plus 7 days</param-value>
</init-param>
<init-param>
<param-name>ExpiresExcludedResponseStatusCodes</param-name>
<param-value></param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>ExpiresFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>



This basically tells Tomcat to, if no other expiration information is set
on the content, to set an Expires header for seven days, which is probably
pretty conservative considering that most content will not change for
months at least. Looking at the headers I also see the browser is
verifying the content each time with a tiny HTTP headers like
If-Modified-Since and If-None-Match so even if the server side changes the
browser should pick that up immediately (untested by me so far).

After doing this, save the file and restart Tomcat:


/etc/init.d/novell-tomcat7 restart


Take out your Apache httpd piece and test before/after that change and see
how things feel. The caching is now on the server side, but he amount of
content going back and forth should be tiny by comparison.

Next, try this with iManager 3.x (probably Tomcat 8, so different paths to
files) and see if it helps.

Please post back your results, which so far have been great and easy to
understand. Hopefully between the two of us we can come up with something
that Micro Focus can just drop in from now on to help everybody with
response times; there's no reason for browser to reload the same content
over and over after all.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
kuronen
Visitor.

Re: iManager load times comparison

Ok you made it too easy so I could not pass it. I tried adding filter configuration to iManager and here are the results.

iManager 3 / tomcat8
--------------------

289 requests, 4550kb transferred, mostly .js, less than 10% cached
1st access after cleaning cache 1:59
2nd access 1:35
3rd access 1:36


iManager 2.7.5 / tomcat5
------------------------

313 requests, [forgot kb transferred], mostly .js, ~80% cached
Filters not supported in tomcat 5 so cannot test with it.


The amount of cached content is very different with the versions. I could not find any header data to prevent caching. I also added .js files cache to 7 days age in Apache mod_cache to store them in the frontend but it seems not to help.

One curious thing:

When I use the same Apache frontend first with the older iManager and then switch tunnel connection to the new iManager I can access the new one in record time of 51 seconds. So the old one must cache something to the Apache or web browser that the new one does not wipe away. But may not be safe.
0 Likes
Knowledge Partner
Knowledge Partner

Re: iManager load times comparison

I would guess some of the JS files are the same regardless, which may
explain some things, but today I setup an iManager 3.0 SP3 instance and
the caching would seem to help there too. I need a slower connection to
test something more like yours, but my tow-second login (originally)
dropped to one second at the most with caching enabled. I'm using the
exact same settings I sent you, on SLES with the iManager-installed Tomcat
8, and things seem better. Looking at headers (courtesy of the Firefox
plugin) I see significantly fewer actual files going across when using the
ExpiresFilter stuff, which means it should help. I never, ever, saw 4+
MBs of data flowing across the connection, which makes me wonder if that
may be because of plugins you have installed or something (I have only
worked with iManager out of the box so far).

It seems strange to me that you have different results. Could you use
something like Firefox's Live HTTP Headers plugin to see how things
compare with and without the change? Admittedly you need at least a valid
version of Tomcat or else no worky at all as you pointed out.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: iManager load times comparison

I did some comparisons of Firefox and Google Chrome to see how they
compared in terms of packets sent for a variety of actions. The first
number is the total packets to that point, and the number in parentheses
is the count of packets for that operation (current total packets minus
previous total packets):

Google Chrome

Login page: 481
Login: 931 (450)
Logout: 976 (45)

Login: 1343 (367)
Click Roles/Tasks (reload): 1461 (138)
Click Roles/Tasks (reload): 1579 (118)
Logout: 1624 (45)

Login: 1990 (366)
Click Roles/Tasks (reload): 2107 (117)



Firefox
Login page: 398
Login: 776 (378)
Logout: 825 (49)

Login: 1028 (203)
Click Roles/Tasks (reload): 1164 (136)
Click Roles/Tasks (reload): 1298 (134)
Logout: 1349 (51)

Login: 1533 (184)
Click Roles/Tasks (reload): 1663 (130)



It seems that Login events, in particular, have significantly fewer
packets on the wire in Firefox. The total size of the Google Chrome
capture was 1.3 MiB, and for Firefox it was just 1 MiB; not a huge
difference, but I guess it could matter, particularly during a login.

I may need to find some fresh browsers for testing to make sure
plugins/extensions/add-ons are not impacting results, but I still think
that I'm seeing better results now than I was without caching. Better,
and more, testing is still needed.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: iManager load times comparison

Bug# 1038086 reported after talking with Product Management for a while;
regardless of the fix (ExpiresFilter or not) the static content should not
be marked as not-able-to-be-cached so hopefully that is resolved at least.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.