Ben J. Christensen

inQuireServer Tests

A test was done using JMeter using an inQuire Client accessing an inQuire server running on the same local machine.

This is done over JINI using JERI.

Configuration was:
- Catalog: AIDC
- Server Heap: 1GB
- Client Heap: 512MB
- Server JVM: 1.5
- Client JVM: 1.5
- inQuire Build: 4th Jan 07
- Client side caching turned on: Yes

The following image shows the results (times in ms):

First Test – DC, Keyword and Complex

The T1000 performs very poorly when the thread count is low.

Interestingly however, even though it’s gap with the X4200 does reduce, it never gets better, or even close to as good as the X4200.

And surprisingly, it crashes and burns when we try and hit 5000 threads — a level that is ridiculously slow on the X4200, but at least it runs.

Second Test – DC Only

The second round of tests showed an interesting result — that the T1000 performs MUCH better when IO intensive tasks are avoided — such as keyword search which hits the filesystem.

It’s still not as good as the X4200 at low thread counts, but much more reasonable — and does end up scaling better than the X4200.

However, in my opinion, the scale it shows is not nearly superior enough to the X4200 to sacrifice the performance at low or single thread counts, and especially not the lack of Filesystem IO.

inQuireWeb Tests

The next round of testing as against Tomcat running inQuireWeb backed by inQuireServer instances as already tested above.

Client side caching was enabled in inQuireWeb so as to reduce hits to the servers and test Tomcat specifically.

The following image shows how if Tomcat and the inQuireServer were on the same machine, the X4200 was superior, while if Tomcat was on the T1000, and inQuireServer on the X4200, then the T1000 came out on top when it started to scale.

So the conclusion from these tests are that the T1000 does indeed have certain niches where it can perform and scale better than the Opteron based X4200 — but they are hard to find, and if you don’t fit that exact niche, a huge performance hit will be incurred.

At this point, databases and the inQuireServer are out of the questions for the T1000 — relegating it to a glorifed webserver … able to host Apache and/or Tomat, as long as the heavy lifting of searches and IO are done elsewhere — such as on the X4200.

Ben

Filed under: Performance

Testing the Sun T1000 and Sun X4200 continues …

… with the databases loaded, I’m now starting the inQuire Server with various types of configuration involving indexing in MEMORY, FILESYSTEM or DATABASE.

I understand that these processes are still primarily single-threaded … but I’m so far not very impressed by the T1000.

If it takes 7+ times longer to initialize a process before I can even get to a point where parallel processing can occur, it’s questionable if it’s worth it.

And … the inQuire Keyword FILESYSTEM implementation is really slow and needs to be replaced.

Filed under: Performance

Here are some numbers showing performance of our inQuire Importer against a MySQL 5.x database using our IT North American catalog with 500k+ products.

Basically it seems the T1000 is HORRIBLE for this type of application.

Of it’s 32 available CPU cores, generally only 1 of them is being used during these processes — when multiprocessing maybe 4 or 5 of them.

The X4200 basically ends up being 7x faster than the T1000.

Next tests are using Tomcat on the T1000 to try it’s multiprocessing.

Filed under: Performance

Web Service tests performed against Netli and Akamai.

First column is origin, second is Netli, third is Akamai.

Each test executed the same request/response 25 times and gave the average.

It alternated between each of the 3 sources, doing 1 request at a time, so a total of 75 in a single test.

NOTE: Servers are located in Los Angeles — so the times for the client also being in Los Angeles are deceiving.

November Web Service Tests

Dec 5/6 Web Service Tests

Filed under: Performance