The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
You know, if customers complaints our applications "work" slow at times, we could really see, it's a network/bandwidth issue from their side. it's their own infra problem. And it's a temporary one.
But the moment the boss hears these complaints, he checks the server stats-graphs. It wouldn't have reached even 60% on the peak levels on the resources. He immediately feels code is not optimized & its' lavishly using up resources and that's slowing down the applications. & he conveys it to the teams straight, immediately.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
they should be happiest if it runs in the band 85% - 95% all the time
As a member of the Engineering team I wouldn't be that comfortable. When for any reason (maybe a successful campaign?) the server load spikes you're in for a lot of complaints and extra hours to pull up whatever crashed. A safer bound would be a constant 50-70%, which means most resources are not wasted and there's still room in case of unforeseen traffic peaks.
Not just sustained peaks either. Your hourly average load might be only 40% but if you drill down to 5 second time slices and see spikes to 90% on that scale your users are already seeing intermittent latency spikes when too many hit the server in rapid succession.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
Don't get too pleased. I walked into a client getting new software.
He bragged about buying a Huge, SUPER Fast DB Computer, and and SUPER Fast NAS using fiber...
This was 9 months after they started installing and testing "new" software designed for much smaller companies than his. But he thought he could throw hardware at it.
And I knew what he was going to say next... "So, why are we so slow?"
I asked: Did you, by chance, tell the developers what type of hardware you were installing?
Client: Yeah, of course!
Me: So, what incentive did you give them to pay attention to speed for the last 9 months?
Client: <jaw dropped=""> "No. You think they did not optimize things?"
Me: Would you waste your time doing that if the client has the biggest baddest servers ever?
Client: <turning green="">
Me: I am here for something else, but I can take a look at a future point. Make a list of the speed issues so I can see how bad they are...
Client: We'd like to add a new row in under 30 seconds on this screen. Currently 2.5 Minutes.
<he had="" a="" few="" pages="" of="" these.="" they="" literally="" paid="" someone="" with="" stop="" watch="" week="" earlier="">
This is all before going on line. the system is not even being heavily utilized, just tested.
The software company was not happy someone else was looking around...
I open up this "database". (Keep in mind they are used to much smaller companies, and the speed issues started when they tested loading real data, and then started testing)
I see NO INDEXES on the largest of tables. I see no FK (Foreign Keys anywhere: The company later brags that they are proud to have no FKs. While this is MSSQL, in Oracle a FK definition impacts the optimizer and the plan strategy in subtle, and beautiful ways)
Literally from that phone call, indexes showed up, and things started getting much better.
The moral of the story. Pay attention to efficiency. Run/test with REAL amounts of data, and on hardware LESS than your clients use. In most of our cases, we made developers run the entire stack on their machine (usually a developer laptop). That alone made the developers conscious of any slow routines they were testing. It usually annoyed them enough to fix the problem.
Finally, as we told this client. The right answer LATE is the wrong answer. Therefore, in the project specifications, and the requirements should be both GENERAL and SPECIFIC speed requirements. Also, any pages that come back (or client screens/queries) that exceed their numbers should be logging them. We like to put HTML Comments in with the TIMING information and a SPECIAL TAG that tells us if it is AT or BEYOND the acceptable response times. SO that when we run our tests, we can actually scan that HTML to validate that none of the pages took too long to come back.
Your boss isn't wrong to pay attention to resource consumption. Although he sounds clueless. If you keep doing what you are doing every week or two... WHEN would you assume YOU have a speed problem?