Three additional suggestions you might want to investigate further:
1. On your database server, assuming "disk1" is where the database
physically resides, consider using multiple smaller drives with RAID 0
(striping). Database performance typically improves -- sometimes
significantly -- when the read and write operations are divided among
multiple "spindles" (physical drives). RAID 1 (mirroring) won't give you
any performance improvement, and RAID 5 (striping with distributed error
correction parity) should be avoided for any database application.
2. Assuming your (Remedy) application server and database server have
multiple NIC's (or a NIC with multiple ports), consider Ethernet trunking
(or "link aggregation"). Properly tuned, trunking offers the twin
advantages of a) improved performance and b) link redundancy (if one of the
Ethernet ports fails, the remaining will continue to handle the network
traffic).
3. If your server NIC's and switches support it, considering using "jumbo"
Ethernet frames. Recall that the maximum size for an Ethernet frame remains
1,518 bytes, regardless of the link speed (even gig Ethernet), so even a
modest 100Kb data transfer would take dozens of Ethernet frames to complete.
Years ago, Alteon Networks (later acquired by Nortel) demonstrated that
jumbo frames typically doubled throughput, while cutting processing time in
half. Since then, most of the NIC and network manufacturers began offering
jumbo frames as an option. I would encourage you to learn more and
determine if it makes sense in your environment.
-- Bing
Bradford Bingel ("Bing")
ITM3 California
http://www.itm3.com/
[EMAIL PROTECTED] (email)
925-260-6394 (mobile)
_____
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Thursday, January 25, 2007 2:56 PM
To: [email protected]
Subject: Re: Reg: Hardware Compactibility
**
Well, you'll need to do some research on your own, but essentially you'll
want to have some way of moving old, closed tickets out of your main ticket
form and into one that could be used for reporting, with the intent being to
keep the number of records in your main form relatively small (less than
100k, and preferably less than 10k). The old data will rarely be accessed,
but users will insist on being able to get to it anyway, and that's usually
what is done with it.
To accomplish this, you could use DSO, Remedy's new (in v7) archiving
functionality, or workflow of your own. It's not that hard to do, the hard
part is getting the users and the bosses to sign off on what you are going
to do.
Rick
On 1/25/07, Pavan Kumar Av (Consultant) <[EMAIL PROTECTED]> wrote:
**
Hi Rick,
As of now we have no archiving strategy. Let me know how can we
have one and what all it needs.
Thanks & Regards,
Pavan Kumar AV - [Remedy]
HCL - AutoDesk
Work: 408 416 0170 Extn: 5576
Mobile : +91 98409 95070
Home: +91 44 4359 0919
Mail To: [EMAIL PROTECTED]
_____
From: Action Request System discussion list(ARSList) [mailto:
[EMAIL PROTECTED] On Behalf Of Rick Cook
Sent: Friday, January 26, 2007 4:02 AM
To: [email protected] <mailto:[email protected]>
Subject: Re: Reg: Hardware Compactibility
**
That looks quite adequate to me, but at 120k tickets a year, I hope you have
an archiving strategy, or performance even on that hardware will begin to
suffer pretty soon.
--
Rick Cook
Cook Enterprises
253-278-4112
On 1/25/07, Pavan Kumar Av (Consultant) <
<mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]> wrote:
**
Hi List,
As of now my server's are of below configuration. We have gone
live for about two quarters & are working just great. Going forward my
client is expecting ticket load as given below:
Peak License usage: 100
Incident Tickets per year: 120,000
Change tickets per Year: 5,000
Please assist me if the below Hardware configuration with hold good or not.
If yes, then for how long. Also let me know what other parameters I can look
forward to tune my server to avoid any over loading. Thanks in advance to
all.
Server
Windows Version
Model
CPU
Memory
Internal Disks
Web Server
2003 Server
DELL
8 CPU, Intel Xeon 3.16 Ghz
4 GB
Disk0 - 68.24 GB, Disk1 - 136.48 GB
Application Server
2003 Server
DELL
8 CPU, Intel Xeon 3.16 Ghz
4 GB
Disk0 - 68.24 GB, Disk1 - 136.48 GB
Database Server
2003 Server
DELL
8 CPU, Intel Xeon 3.16 Ghz
4 GB
Disk0 - 68.24 GB, Disk1 - 136.48 GB
Note: No Clustering or load balancer available as of now.
Thanks & Regards,
Pavan Kumar AV - [Remedy]
HCL - AutoDesk
Work: 408 416 0170 Extn: 5576
Mobile : +91 98409 95070
Home: +91 44 4359 0919
Mail To: [EMAIL PROTECTED] <http://%20/>
__20060125_______________________This posting was submitted with HTML in
it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
