This is a discussion on [Samba] SaMBa raises 10x the traffic but only when _executing_, within the Samba forums, part of the Networking and Network Related category; Customer is running a Delphi app talking to an MS-SQL-Server through Microsoft ADO. The SQL stuff is reasonably ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Customer is running a Delphi app talking to an MS-SQL-Server through
Microsoft ADO. The SQL stuff is reasonably chatty but not a problem. Whenever the program is run or a significant feature is used, it generates much SMB traffic -- roughly 10x as much from a SaMBa (3.1 or 3.0) server as from a W2k or w2k3 server. As you might imagine, this makes the app run very slowly. This happens with one user or with many. The ?mbd processes aren't raising a sweat, a few % of CPU at most. Samba delivers (and accepts) data at up 9.8MB/s sustained to smbclient over a 100Mb/s link, and delivers 2MB images to XP in an eyeblink, so it's not a fundamental networking failure. There is no perceptible speed difference serving from a muscly hardware-RAIDed-SCSI dual-CPU gig-of-RAM server or my el-crappo AOpen laptop. This DID NOT HAPPEN with their old Novell file server using Novell's networking protocols. The application provider also has another site running the app on a Citrix server but from a separate file server, with no speed problems. That makes it look very much like a cacheing or similar issue. The amount of SMB traffic involved is roughly 4x the size of the application. I've tried with and without oplocks, with different levels of buffering, different OS levels, all sorts of config performance tweaks and they make no perceptible difference vs minimalist changes OOtB. It's interesting that despite delivering only 10%-ish as much traffic, responsiveness from the w2k3 server is only about 20% better than from any Samba server. The app is blindingly fast in comparison if run from the local disk, but the customer doesn't want to have to maintain 40-odd local copies of the app, and the basic problem would still lurk. Initially, we tested with a version of the app which was compressed (12MB => 4MB) with BlinkInc's Shrinker, but later testing involved an uncompressed version. That did run perceptibly faster, but it was an incremental improvement, not the revolution that we need. There is a an Ethereal capture up at http://samba.cyberknights.com.au/ if you're interested in seeing for yourself. This is taken from an XP workstation (*.158) talking to a 2k3 server (*.4) and them my laptop running Samba (*.108). The traffic to *.100 is the SQL server and everything else is pretty much irrelevant. The capture shows the workstation starting the app, making an initial query, then doing a find on a product number, then closing down. This is done first to the 2k3 server then Samba. Trimming the requests down from ~50MB to ~5MB would probably make the app "fast enough" but there's extra brownie points (and a meal at your local Sizzlers or near equivalent, maybe a couple of pizzas) for enough clues to make it all run like a greased otter. (-: Cheers; Leon -- http://cyberknights.com.au/ Modern tools; traditional dedication http://plug.linux.org.au/ Member, Perth Linux User Group http://slpwa.asn.au/ Member, Linux Professionals WA http://osia.net.au/ Member, Open Source Industry Australia http://linux.org.au/ Member, Linux Australia -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba |