Posts Tagged ‘network’

Cool Tools 26: SpeedTest.net

Saturday, April 20th, 2013

This is more of a consumer-grade type of site that I’d recommend to everyone – including my parents when they complain about the “Interwebs being slow”. But, if your IT shop is promising specific Internet bandwidth for your portal servers, there’s nothing to stop you from RDP’ing into your server and navigating to speedtest.net to get a “second opinion”.

It is pretty laden with ads, but they aren’t too distracting. And it does require that virus called Adobe Flash, which isn’t always (and shouldn’t be!) installed on servers. But, if you’re dealing with performance issues that feel like they’re related to the network, and you’ve tested internal network connections, it can be worth temporarily installing Flash.

For example, I’m pretty sure our cloud hosting provider guarantees 10MBps both ways… so I should get on them with these results!
speedtest

It is worth pointing out that despite the joke about getting on our cloud provider, SpeedTest.net shares your Internet connection with every other connection at any given point in time. So just because the above screen shot shows that this machine is only downloading @ 6.31Mbps, that doesn’t mean that the pipe to the Internet offered by our hosting provider isn’t providing 10Mbps. It’s possible that other machines in our infrastructure are burning bandwidth too. And, since this is a production environment, I would HOPE at any given point in time there is activity on our network as pages are served from the portal.

Give it a shot – even if you’re sitting in front of your work computer at this very moment. You may be surprised about the relative speed differences between your home and office.

One surprising little fact is that I pay about $100/month for about 100MB/s from Comcast. But most commercial hosting providers charge up to 10x the cost for 1/10th the speed. Really – that’s a 1000x markup! The difference, of course, is that Comcast doesn’t GUARANTEE these speeds – or even availability. So you couldn’t run a real production web site off Comcast, since it is occasionally down or under-performing. Still, it’s food for thought: at the very highest service levels, costs increase exponentially. Same thing with the “Five 9′s” mandate – but that’s a blog post for another day…

Cool Tools 25: LAN Speed Test

Saturday, March 30th, 2013

Sometimes the coolest tools are the simplest ones.

Today’s Cool Tool is simply called LAN Speed Test, and the tool pretty much does just that – it tests the speed of various connections in your LAN. It does this by simply writing a 20MB file (configurable) to a file share, reading it back, and timing how long the transfers took.

lan-speed-test

The use case for this was pretty simple: our WCI Portal machine (with an alias of PT-PORTAL) was in a DMZ, and the back-end servers (in this case, PT-INTEGRATION and PT-COLLAB) were on a separate sub-net. The NT Crawler web service was acting very strangely, failing to serve up files through the portal, but serving them up locally just fine.

So, using LAN Speed Test, I was able to confirm (and prove to the network team) that the problem was in the switch/firewall connecting the devices. Notice in the above screen shot how PT-INTEGRATION was able to write and read a 20MB file to PT-COLLAB in about .24s and .28s respectively? And how writing the same data to PT-PORTAL was taking 20.6s and 2.2s, respectively?

Yeah, there’s the smoking gun…

Using Host Files for UNC Paths

Friday, March 15th, 2013

Years ago I strongly advocated the use of host files for “better environment portability and mobility”. Over the years I’ve used this trick to simplify WCI patch installs, database migrations, and server upgrades.

But, one use of host files has always proven a bit troublesome – the UNC path for published content in WebCenter Interaction Publisher:
publisher-unc-path-alias

Specifically, in Windows Explorer, if you’re trying to access a share called “publish” on a machine called PROD-FILESERVER, you can type this in Windows Explorer:

\\PROD-FILESERVER\publish\

If you are back-filling your database from production to a development environment, this name is also synchronized, and you certainly don’t want your Dev environment connecting to your Prod file server. The solution would be to use the host name aliases we’ve already discussed, so you could use a name like this:

\\WCI-NAS\publish\

… and then have WCI-NAS resolve to the respective file server in each environment.

This tweak, though, doesn’t work unless you use the trick found here: Disable Strict Name Checking.

NETBIOS enforces “strict name checking”, so connecting to a machine by name that’s not the actual machine name is prohibited by default. But that’s exactly what we want – our Production, Development, and Staging environments all using \\WCI-NAS\publish\ as the file share. That way, when we sync the database between environments, we don’t have to change the UNC paths all over the place.

In other words, to make this host file aliasing work work with UNC paths, you can just add a DWORD with a value of 1 called DisableStrictNameChecking to HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Services\ LanmanServer\ Parameters.

Configure Publisher To Use A Network Share

Thursday, January 6th, 2011

In many larger Plumtree / WCI Publisher installations, you will have 1 “full” instance of Publisher used for authoring content, and one or more “zombie” (really, that’s what they call it in the configs!) instances serving up that content. 

See Bill Benac’s excellent diagram on this type of configuration.  Often, you’d have the publishing component of Publisher write to a network share, then use the zombie instances to proxy the content itself, or have the zombie instances redirect to a different web server configured to serve up the files.  Why two different approaches?  See this article I wrote back in ’08 for why proxying isn’t always ideal after an upgrade.

Anyway, in some instances, even with just one Publisher instance, you may want to publish to a network share, and don’t want to bother with configuring an additional Web Server to serve up that content.  In those cases, you can easily change Publisher’s own embedded Web Server (technically, it’s JBoss) to serve up this content.  Just perform the following steps:

  1. Set the Publisher Service to run as a user that has full access to the network share.
  2. Update your Publishing and Browsing targets in Publisher Explorer to use the correct paths.
  3. Update the %ALUI_HOME%\ptcs\6.5\container\deploy\jbossweb-tomcat50.sar\server.xml file, specifying your network share here:

That way, when the portal attempts to load published content via http://wci-publisher:7087/publishedcontent/, the portal will be connecting to the JBoss instance running Publisher, but the files will be coming from the network share.

Cool Tools 12: CACE’s WireShark

Saturday, October 30th, 2010

Sometimes tcpTrace just won’t do the trick when you need to monitor network traffic, such as when you need to see what’s going on in the network layer between servers where you can’t control the port used between endpoints.  I recently used today’s Cool Tool when diagnosing an email issue between IIS and a remote SMTP server trying to send mail: I needed to see why emails coming from the WebCenter Interaction Portal weren’t being accepted by the government server being used to route the traffic:

The problem ended up having to do with Reverse DNS lookups, which I’ll write about soon. 

For the purposes of this post, though, the Cool Tool is CACE’s WireShark, the Big Brother (read: later version after a name change) to Ethereal (see this post for a clarification to that comment: “ethereal is still ethereal, but ethereal development has ceased. All the core developers are currently working on wireshark. So do not expect new releases of ethereal any time soon, Wireshark is what’s being developed.”).

WireShark allows you to sniff all traffic going into and out of a network interface, which is hugely valuable (if not a bit more complicated as you get acquained with network protocols and WireShark’s powerful filtering capabilities).  As a portal administrator, you likely won’t need it daily, but when you do, it’s hands-down the best network sniffing tool for the good guys – and potentially dangerous for the bad guys if you haven’t, say, locked down your search server.